Navigation, Not Planning

There is something reassuring about following a marked trail.

You know where you want to go and have markers along the way. But you rarely know exactly what lies ahead. You see enough of the terrain to keep moving, and adjust as you go.

In organizations, we seem much less comfortable with that uncertainty.

We plan. We estimate. We create roadmaps, business cases and increasingly precise forecasts. All for understandable reasons: Finance needs predictability, leadership needs commitments, and the business needs to know where its money and people are going.

The problem starts when we mistake that need for orientation with a need for certainty.

To secure funding, a team names a solution. To coordinate with others, it puts that solution on a roadmap. To justify the investment, it estimates the return. By the time the work begins, several decisions may depend on an answer nobody has actually tested.

We might still call what follows discovery. But there is not much left to discover when the expected answer has already been planned, funded and committed.¹

You cannot govern uncertainty out of product development. You can only build an organization that navigates it well.

This, to me, is at the heart of the product operating model.

Continuous discovery and delivery only work if learning is allowed to change what happens next. Discovery needs room to change our understanding of the problem and the solutions worth pursuing. Delivery needs to get small, useful changes into customers’ hands so we can learn from what actually happens.²

Teams therefore need more than a different process. They need continuity, access to customers and enough authority to change the solution as they learn. And they need to remain accountable for the outcome, rather than simply delivering what was written down months earlier.³

None of this makes planning or accountability optional. It changes what we plan and what we hold teams accountable for.

Give teams a direction. Give them constraints, an investment horizon and outcomes worth pursuing. Make assumptions and dependencies visible. Ask for evidence. Review whether the investment is still justified. Change course – or stop – when the evidence tells you to.⁴

But don’t ask for certainty where none exists.

This is also why I don’t think a product operating model means giving teams autonomy without governance. Finance still needs forecasts. Leadership still needs to make investment decisions. The business still needs influence over where the organization is going.

The difference is how these needs interact with the teams doing the work.

McKinsey describes organizations that changed their structures while leaving the surrounding governance largely untouched. In one bank, funding was still based on large projects approved by steering committees, with significant time spent on business cases, approvals and backward-looking tracking. The response was not to remove governance, but to change it: more flexible funding around outcomes and an integrated governance rhythm that brings functions such as Finance and Strategy into the same decisions.⁵

That distinction matters.

A team should have enough room to change its solution when the evidence changes, but that freedom comes with responsibility. What did we learn? What evidence supports it? What decision does it change?

If those questions cannot be answered, calling something discovery does not make it responsible.

Equally, meeting the original delivery date does not establish that the solution was worth building.

A modern product organization should be able to act on new evidence without treating every change of course as a failure to execute. That is a harder form of accountability than simply measuring deviation from a plan – but also a much more useful one.

The marker on the tree does not tell you exactly what lies ahead. It gives you enough orientation to keep moving while paying attention to the terrain.

The question is not whether your product teams have a plan. It is whether your organization still knows how to move when the plan stops matching the terrain.

Teresa Torres, “3 Best Practices for Adopting Continuous Product Discovery”, Product Talk, 12 July 2017. Torres distinguishes doing discovery activities from actually allowing them to inform product decisions, noting the failure mode of using research to validate decisions already made.
Marty Cagan, “Product Model Concepts”, Silicon Valley Product Group, 17 January 2024. Cagan frames the product model around outcomes rather than output, with empowered teams responsible for discovering and delivering solutions that achieve those outcomes.
Aditi Chawla, Martin Harrysson, Hannah Mayer and Megha Sinha, “The bottom-line benefit of the product operating model”, McKinsey & Company, 19 December 2023. Based on more than 400 public companies, McKinsey reports strong correlations between product-and-platform operating-model maturity and business outcomes, and identifies product-management practices, funding and interaction between product, engineering and operations among important differentiating capabilities. The reported relationships are correlations, not evidence of causation.
Tarun Sharma and Max Linkoff, “From project to product: The next frontier of value creation”, Deloitte. Deloitte argues that moving from projects to products requires changes in funding, governance and accountability, while retaining disciplined portfolio management, measurable outcomes and resource allocation.
Ákos Légrádi, Deepak Mahadevan, Olli Salo and Tom Welchman, “How to get your operating model transformation back on track”, McKinsey & Company, 7 August 2025. In one transformation case, McKinsey identifies continued project-based funding, steering-committee approvals, business-case templates, emphasis on control and certainty, and discussions centered on deliverables and roadmaps as obstacles. The response included fixed-envelope funding and an integrated governance cycle involving Finance, Strategy and other control functions.