Make the horse drink

Lean product management was supposed to help us learn faster. Somewhere along the way, many teams turned it into another delivery process.

The question I keep coming back to is simpler: what is the quickest way to learn?

Not the quickest way to build. Not the quickest way to get something onto a roadmap. Not the quickest route through refinement, estimation and sprint planning. The quickest way to reduce the uncertainty that actually matters.

Lean is a learning system, not a ceremony

Problem interviews, experiments, hypotheses, MVPs and analytics are useful only because they can change what we believe. Once they become required artefacts, they lose most of their value.

A hypothesis nobody is willing to disprove is just a requirement written in scientific language. An MVP that takes nine months is just a smaller first release. An experiment whose result cannot change the roadmap is theatre.

The point of lean is not to make delivery cheaper. It is to make being wrong cheaper.

Start with the uncertainty, not the solution

Product teams are naturally pulled toward solution detail because solutions feel tangible. They can be designed, estimated and tracked. Uncertainty is messier.

But the highest-leverage product question is usually not “what should we build?” It is “what would have to be true for this idea to work?”

• Do people actually experience the problem?
• Is it painful enough to change behaviour?
• Can we reach the users who have it?
• Can we create the outcome technically?
• Will the economics work?
• Will people come back after the first use?

Each of those questions suggests a different experiment. Most of them do not require production software.

Release early is not the same as learn early

Product teams often congratulate themselves for shipping an MVP quickly when the expensive part of the idea had already been assumed months earlier. The interface was released early. The learning was late.

Sometimes the fastest experiment is a conversation. Sometimes it is a prototype, a manual service, an email, a fake-door test, a spreadsheet or a person doing behind the scenes what software may eventually automate. The form matters less than whether the evidence is good enough to influence the next decision.

Retention is where optimism goes to die

Acquisition can tell you that somebody was curious. Activation can tell you that they got through the front door. Retention starts telling you whether the product has earned a place in their life or work.

This is why retention is such a useful antidote to product theatre. Teams can manufacture launches, sign-ups and feature adoption. It is much harder to manufacture repeated value.

When users do not return, the question is not immediately “which engagement feature should we add?” It is often more uncomfortable: was the problem important enough, and did we solve it well enough?

Analytics should answer a decision

Dashboards are another place where learning gets replaced by activity. A metric is useful when you know what decision it informs. Otherwise you have reporting, not insight.

Before instrumenting everything, ask what you need to know. Which behaviour would increase confidence that the product is working? Which behaviour would make you change direction? What would surprise you?

Scaling lean without killing it

As organisations grow, they understandably add governance. The danger is that governance starts protecting the plan from evidence.

The best scaling mechanism is not more templates. It is a shared expectation that teams can explain the problem, the uncertainty, the evidence and the decision. That standard can survive growth without prescribing exactly how every team has to learn.

Lean thinking should make an organisation more intellectually honest. We believed this. We tested it. Here is what happened. Here is what we changed.

The question worth keeping

Frameworks age. Terminology changes. Product fashions come and go. The useful question remains:

What is the quickest way to learn something that could change what we do next?

If the team cannot answer that, it probably does not need another process. It needs a better question.