Arnon Cavaeiro is a product leader who argues that engineers need enough business context to judge the problems they work on. In this episode, we explore how to build that judgement: understand where revenue comes from, what drives costs, and which customer problems matter enough to act on.

The conversation moves from discovery to delivery, with practical questions engineers can bring to their next project. Why can a feature go unused even when a customer requested it? What is the smallest experiment that would test your riskiest assumption? Arnon shares how to use early signals before revenue catches up, make the business case for technical debt, and navigate the growing overlap between engineering and product management.

Listen on YouTube, Spotify or Apple Podcasts

In our conversation, we discuss:

  1. Why understanding revenue and costs changes what engineers choose to build
  2. How to judge customer problems by reach, pain and relative priority
  3. Why customer requests need small experiments and clear product positioning
  4. How leading metrics help you change direction before revenue catches up
  5. How to connect technical debt and engineering decisions to business outcomes

Where to find Arnon Cavaeiro:

Lessons Learned

  • Start with how the business works. Arnon recommends learning the basics of profit and loss: where revenue comes from and what creates costs. This gives engineers a starting point for evaluating ideas and explaining their choices. If distribution depends on customers inviting others, for example, understanding that model can help an engineer spot useful product opportunities.
  • Assess a problem on three dimensions. Ask how many people experience it, how painful it is, and how it ranks against their other problems. A widespread frustration can still sit well below the work customers urgently need to get done. Treat reach, pain and priority as separate questions when deciding whether a problem deserves investment.
  • Ask customers to compare their problems. Enthusiasm for your product does not necessarily mean someone will pay for it or make time to use it. Arnon asks people to rank the problem alongside the other difficulties they face. Learning what comes first helps explain why a seemingly useful solution may struggle to earn attention.
  • Use a short PRD to clarify your reasoning. Arnon still sees value in a product requirements document as a way to organise thoughts and make assumptions explicit. That reasoning also gives an AI coding agent useful context. The document should help the team understand what it is trying to learn before committing to the next step.
  • Design the smallest experiment around the biggest risk. The first uncertainty might concern pricing, usability or a legal constraint. A product that charges an upfront subscription faces a different pricing question from one that takes a share of the revenue it creates. Choose an experiment that addresses the relevant uncertainty instead of automatically building a smaller version of the entire product.
  • Treat a customer request as something to investigate. Peppe describes shipping a feature to companies that had reported the problem, only to find it unused a month later. Arnon's first question is how much the experiment costs. A small, cheap change may be worth trying; a change that affects other parts of the product deserves deeper discovery and a clearer connection to strategy.
  • Check requests against your positioning. When competitors can implement similar features with similar tools, a growing feature list may offer little distinction. Arnon warns that responding to every request can produce a sprawling product. Understanding why a customer should choose your product gives the team a basis for deciding which requests fit and which ones pull it away from its purpose.
  • Build prototypes to sharpen your thinking. Arnon describes building as a way to make ideas tangible. A prototype exposes questions that can remain hidden in a document and gives people something concrete to respond to. He distinguishes that useful product management practice from the responsibility of shipping and maintaining a product at scale.
  • Keep track of what experiments teach you. Arnon argues that cheaper implementation makes it possible to try more approaches to the same problem. He also points to capturing the reasoning behind those decisions. Each attempt should help the team decide what to try next, rather than leave behind another feature with no clear account of what happened.
  • Use leading metrics, then investigate what they mean. Revenue may arrive too late to guide a decision you need to make now. Activity, retention and workflow completion can offer earlier signals, but interpreting them requires customer context. Someone leaving a workflow may have encountered friction, or may already have solved their problem; the number alone cannot tell you which.
  • Connect technical debt to the product's promise. A request for two weeks of cleanup is easier to assess when it explains what users or the business will gain. Arnon connects this to positioning: speed, reliability or scalability may be central to why customers choose the product. Explain that relationship and the trade-off against other priorities instead of assuming the technical issue makes its own case.
  • Make ownership explicit as roles overlap. Arnon expects the distribution of product work to vary with the company and its domain. Engineers building a product they use themselves may have context that is harder to acquire in a specialist industry. Strategy, customer understanding and accountability still need an owner, even when job titles change. AI can help connect a technical proposal to business concerns, but people remain responsible for the decisions.