Product shouldn’t own the “what”

If you work in software development, you’ve probably heard someone say “product owns the what; engineering owns the how,” a phrase meant to clarify accountability in a cross-functional, collaborative environment where the role of product management is often quite ambiguous.

As a model for what product shouldn’t own, it’s a good start. Product definitely shouldn’t own how it’s built, how it works, or how it looks. While a product manager can absolutely help shape the solution, these are areas where they should trust and encourage the expertise of their counterparts in engineering and design. If a product manager spends appreciable amounts of time and energy on the “how,” it’s a sign that they’re overstepping their bounds, uncomfortable with strategic-level product work, and/or trying to compensate for a gap within the wider team. In any case, this almost always comes at the expense of what a PM is uniquely suited to own.

As a model for what product should own, it’s less helpful. To be sure, product managers have an important role to play in shaping the “what”—especially in startups, where specialists are often stretched thin (if not entirely absent from the org chart). Imagine a strong product team that emphasizes continuous discovery and prototyping over heavy documentation. Within such a team, a product manager might test potential solutions by creating wireframes and simple prototypes, refine the UI by writing/editing product copy, and/or prep launch materials such as customer-facing documentation. These activities speak to the fact that more than any other role in the product trio, product managers are accountable for building the right thing. For better and for worse, a high-ownership PM does what’s needed to ensure that technology investments achieve their desired outcomes.

The risk in this high-ownership mindset is that the product manager can conflate accountability for outcomes with responsibility for execution. When this happens, outcomes and outputs both suffer:

• The solution won’t benefit from the full potential of engineering and design—not only their creative capacity (they’re often the best sources of innovation) but also the long-term buy-in that comes from helping decide what gets built. There are certainly engineers and designers who prefer to be given marching orders, but they’re not good startup hires, and good startup hires don’t want to be treated this way.
• The team’s focus shifts from collaboratively working towards a customer outcome to delivering predetermined output, which over-emphasizes upfront planning and extends costly assumptions into the development process. It might get something built faster, but it’s unlikely to deliver the outcome the team’s looking for.

Instead of owning the “what,” product should be expected to own the “why” and “why now,” co-owning the “what” with engineering and design. From the perspective of the product manager, here’s what this looks like in practice:

• Collaborate across the org to define/refine the product vision and thematic roadmap
• Interact with customers and the broader market to understand their needs
• Clarify customer problems and the surrounding context for design and engineering
• Involve engineering and design in focused exploration and concept generation (“how might we…”) so that everyone on the team can leverage their skills/know-how towards solutions
• Work with research and design to test assumptions and address project risks as early as possible
• Liaise between stakeholders and customers/prospects/users to ensure that the emerging solution is aligned with business priorities
• Continually negotiate scope as needed (this is almost always cutting scope rather than adding to it)
• Pinch-hit on any functional gaps in the product lifecycle
• Ensure that the team learns from whatever it launches rather than immediately moving on to something else

When product co-owns the “what” with engineering and design, the team will devise solutions far better than what a PM would’ve come up with on their own, they’ll be far more incentivized to build and maintain them, and the product manager will have more time to focus on delivering outcomes for customers (and by extension, the business). While product managers absolutely have a role to play in defining what gets built, their creative contribution is ultimately more about synthesizing and thoughtfully shaping rather than generating ideas.