Discovery works. The handoff is where it breaks.
If you arrived looking for product discovery, dual-track delivery or a product operating model, this is the honest map — what I teach about it, what I do not, and which engagement answers which problem.
Discovery rarely fails because a team cannot interview customers. It fails because what discovery produces — bets, opportunities, a prioritised set of problems — arrives at engineering as work it cannot cost, and at data as an outcome it cannot measure.
Where product-led ways of working actually stall
Bets meet commitments
Discovery is designed to stay uncertain for as long as possible. Delivery is judged on dates. The moment an opportunity becomes a commitment it crosses a boundary where the vocabulary changes, and almost nobody trains the crossing.
Value and risk are priced differently
Product prices value; engineering prices risk. Both are right, and neither can read the other's number. This is the estimate conversation, and it is where trust between the two functions is usually lost.
Nobody agrees what worked means
Outcomes over outputs is a good instinct that dies on contact with two dashboards that disagree. Without a shared definition owned by data, an outcome target becomes another opinion.
Two different things are called product-led
Product-led growth is a go-to-market motion — free trials, self-serve funnels, pricing and activation loops. I do not teach that, and if it is what you need you want a growth consultancy, not a training academy.
Product-led ways of working — continuous discovery, dual-track, outcome ownership, the product operating model — is a question about how product, engineering and data decide together. That is the whole subject of this academy.
The distinction matters because the two get the same name and need opposite help. If you are not sure which you have, that is a reasonable thing to work out on a call.
The Product track runs requirements, discovery, prioritisation, metrics, technical product management and strategy. The Bridge track covers the decisions the functions make together — expectations across the boundary, the operating contract, and the three-way version where data is in the room.
Which engagement answers which problem
| What is actually going wrong | Where to start |
|---|---|
| Discovery is healthy, but nothing reaches customers on the dates we agreed. | The Bridge |
| Product and engineering estimate the same work differently, and each thinks the other is wrong. | The Bridge |
| We ship the outcome and then argue about whether it worked. | The Three-Way Bridge |
| We are moving to a product operating model and the managers need to change how they work, not just what they say. | Team programmes |
| The leadership team needs one shared read before it sets a direction. | Executive briefing |
| I own this transition personally and need someone who has done it. | Mentoring or a coaching sprint |
| One specific decision is stuck and I want a written answer quickly. | The Diagnostic |
- A certification. No CSPO, no CSM, no badge of any kind — none are offered, deliberately.
- Generic Agile or Scrum training. This is not a framework rollout, and it does not become one.
- Facilitation practice for individual contributors. This is management training: it teaches the decisions around discovery, not how to run the interviews yourself.
- Product-led growth as a funnel problem. Pricing, activation and self-serve conversion are a different discipline.
- A recorded course. Everything is live and on demand.
Not sure which of these you have?
That is what the scoping call is for. Thirty minutes, no deck, and a straight answer about whether this is the right thing for your team.