Meikel Ratz is a product engineer at PostHog, where he leads the messaging team. In this episode, we unpack the product thinking behind that role and what it takes to become a product-minded engineer: understanding customers, making product decisions, thinking about revenue, and deciding what to build instead of simply working through tickets.

In this conversation, we explore what happens to software engineering when writing code is no longer the scarce skill. Meikel shares how product engineers work at PostHog, why “snacking work” can consume your day without moving the needle, how engineers can develop business sense, and why data, customer context, and sometimes gut feeling should drive what you build.

Listen on YouTube, Spotify or Apple Podcasts

In our conversation, we discuss:

1. Why solving problems, not writing code, has always been the real job of software engineers
2. “Snacking work”: the small, satisfying tasks that consume time without creating much impact
3. How PostHog gives engineers ownership over customers, product decisions, reliability, and revenue
4. How engineers can develop product and business sense, even if they’ve spent their career being handed tickets
5. Why data should drive product decisions, when gut feeling is still useful, and how AI changes the economics of experimentation

Where to find Meikel Ratz:

• LinkedIn: https://www.linkedin.com/in/meikelratz/

Lessons Learned

  • Optimize for outcomes, not output. Finishing tickets or writing more code is not the goal. Ask what actually improves the product, customer experience, or business.
  • Eliminate “snacking work.” Small bugs, cleanup tasks, and tightly scoped chores feel productive because they give quick dopamine hits. Automate or delegate as much of that as possible so you can spend time on harder problems.
  • Start with the customer. Before building something, ask: Does the user care? Even deeply technical work should connect back to performance, reliability, cost, or another user benefit.
  • Get closer to product decisions. Join customer interviews, read support tickets, study usage data, and understand why features are being built instead of only how to implement them.
  • Learn the business behind your product. Understand revenue, pricing, costs, free-tier limits, competitors, and which customers create the most value. Product judgment gets much better once engineering decisions have business context.
  • Use data to challenge assumptions. Instrument what you ship. Look at usage, adoption, churn, revenue, and failure points instead of relying purely on opinions.
  • Don’t wait for perfect evidence. When experiments are cheap, intuition is enough to test an idea. Ship behind a feature flag, measure what happens, and kill it quickly if nobody cares.
  • Build something yourself to develop product sense. A small side product forces you to choose what to build, talk to users, process feedback, prioritize, and think about value instead of implementation alone.
  • Own reliability as part of product quality. New features are not automatically higher-impact work. Bugs, outages, poor performance, and scalability problems directly affect whether customers stay.
  • Reduce attachment to your code. The useful question is not “Was my implementation preserved?” It is “Did the product get better?”
  • Seek context instead of waiting for it. If your company keeps engineers away from customers or business data, ask for access and demonstrate what better decisions you can make with it.
  • Choose environments that reward ownership. Product-minded engineering is difficult in organizations built around rigid ownership, handoffs, and layers of approval. Culture can either amplify these skills or suffocate them with quarterly planning documents.