An opportunity is a customer problem and not a feature in disguise
💎CORE ARGUMENT
Half the opportunities on any roadmap I have written were features in disguise. Customers need a dashboard for carrier performance is not a customer problem. It is a dashboard, and the word need has been attached to it.
The disguise matters because of what it closes off. A problem leaves the solution open, and a feature has already chosen it. Once the opportunity is written as they need X, every conversation that follows is about how to build X, and nobody asks whether X is the best answer or one of several. The decision has been made by grammar.
My test is short. Could three genuinely different solutions answer this? If yes, it is an opportunity. If the only thing that satisfies the sentence is the feature named in it, it is a solution.
- Dispatchers need an e-mail digest. One solution. Fails.
- A dispatcher cannot tell, before nine, which five of 214 exceptions will cost money today. A digest would answer it. So would better ranking, or a rule that closes the harmless ones. Passes.
The second sentence is longer and names a person, a moment and a consequence. That is usually how I can tell.
I drew my first real opportunity tree this autumn, for the scorecards work, and the first draft had four branches that were all the same feature seen from different angles. Redrawing it took three days longer than planned, and the extra days were the useful part.
Where it breaks down: some things are just features. A customer who asks for an export to a spreadsheet wants an export to a spreadsheet, and recasting it as an unmet need is a way of wasting her afternoon. The test is for the top of the tree. This note sits in 05. 📦 Product & Operations, next to 💎 An exception is information about the process and not a nuisance in it: both refuse to take the first description of a problem at its word.
🧱BUILT FROM
🌍WHY IT MATTERS
Roadmap items now get written as a person, a moment and a cost. If I catch needs a followed by a noun we could build, I rewrite the line before it goes to planning. With Sam I ask the three-solutions question out loud. He finds it more annoying than I intended.
The test: could three different solutions answer it?
☑️NEXT STEPS
- Rewrite the roadmap items for scorecards as a person, a moment and a cost
- Ask the three-solutions question with Sam on each new item
- Finish the opportunity tree before any solution is costed
📖 Torres on opportunity trees: outcome at the top, then opportunities, then solutions, then experiments, and the discipline of keeping the middle two layers apart.
💎 Discovery is cheaper than delivery so do more of it: discovery aimed at a disguised feature only confirms it. 💎 An exception is information about the process and not a nuisance in it: an exception also arrives looking like a nuisance to be removed, and is really a statement about the process.
A problem statement leaves the solution space open and a feature request closes it. Written as they need X, the choice of X has been made without evidence and nobody notices. Asking for three different answers forces the sentence back up a level, to the thing the customer is actually stuck on.
Sales would say, fairly, that a customer who names the feature and will sign for it has done my discovery for me. Sometimes the fastest route to the real problem is to build the thing asked for and watch what they do with it.
Argued in public in 📝 Issue 46 - Opportunities are not features. Applied, slowly, in 📌 Draw the opportunity tree for scorecards.