Twenty-three features
A dashboard for a fictional venture. Where is it stuck? Read the numbers and the notes, pick the stage it's really stuck at, then see our read and why.
Fictional Every name and number here is made up for the puzzle.
The venture
A staff scheduling app for independent restaurants: rotas, shift swaps, hours and holiday.
What the founders thinkCustomers keep asking for things. We need more engineers to keep up.
Features shipped, per month
6 from 5
Open feature requests
112 from 40
Accounts using any feature from the last three months
5% from 9%
Paying restaurants
44 from 38
Also on the desk
- The last ten deals were signed by three kinds of buyer: owners, general managers and head chefs, each wanting something different.
- The roadmap is the request list, sorted by who asked loudest.
- Nobody on the team can say what the product will never do.
Stuck at Define.
The team builds well. Nobody has decided who it's for or what it isn't.
What the dashboard shows
- The team ships every month, so the build works. What it builds is barely used: each month, fewer accounts touch anything new.
- Requests nearly tripled while paying restaurants barely moved. Every request answered brings more requests, not more customers.
- Three kinds of buyer, each pulling a different way, and a roadmap sorted by volume. That is a product without a decision behind it.
Why not Build?
It looks like a Build problem because the backlog is growing faster than the team. But more engineers would ship more unused features, faster. The backlog is a symptom of a missing decision, not a missing team.
What we'd do next
Pick one buyer, write down what the product will not do for the other two, and put the request list through the Scope Cut: build first, later, cut, or don't build. Most of the list goes. What survives is the product.
The method: The Scope Cut and Decide · Design · Ship. The stage, in the Journal: Define stage: what we build and what we cut.