Product Innovation: find and shape a product worth building
We put the offer in front of the buyers who would pay for it, then shape the smallest product that proves the revenue case.
In brief
Product Innovation finds and shapes a new product or revenue line worth building. A capability often fits the roadmap without a buyer who will pay for it, so we test the offer with real buyers before any build, then define the smallest first release that proves the revenue case and the evidence that would make you stop.
- Who it suits
- A product leader, founder or business-unit head who must decide whether to commit build money to a new offer.
- What you provide
- Introductions to buyers, and the willingness to hear a no.
- What you get
- An opportunity brief, a record of what buyers said and did, a first-release scope and a paper that says build, change or stop.
- Where it ends
- At the decision. Building is a separate scope.
On this page
Why does a sound capability so rarely become a product that sells?
Ideas that start from a capability start from what the company can build. The buyer is imagined, not interviewed. The build absorbs the budget before any buyer has shown intent, and the first release grows large because every stakeholder adds the feature they care about.
At launch the product meets the buyer's real alternative, usually a spreadsheet, a service they already use or a competitor, and loses on a point nobody tested. The revenue case turns out to have rested on assumptions that were never put to a buyer. The loss is the build budget plus the months in which a better-aimed idea could have been tried.
What do buyers say, what do they do, and how much does each count?
We write the weighting down before the first conversation, so nobody can promote a compliment into a signal afterward.
| Signal | What it looks like | How we weigh it |
|---|---|---|
| Praise for the idea | "This is interesting." "We should talk again." | Recorded, and given no weight |
| A second meeting that the buyer asks for | The buyer returns with a question about how it would work | Some weight. It costs the buyer an hour |
| An introduction | The buyer brings in a colleague who would use it, or the person who holds the budget | Real weight. It spends the buyer's standing |
| Their own data or process | The buyer shares the spreadsheet, the report or the workaround they use today | Strong weight. It shows the problem exists in practice |
| A question about terms | Security review, contract form, who signs, when it could start | Strong weight. The buyer is picturing buying it |
| A commitment | A paid pilot, a signed letter of intent, a named internal sponsor | The standard we aim for before any build |
What happens in a buyer conversation?
The person with the problem and the person with the budget are often different, so we ask for both. We begin with the last time the buyer dealt with the problem: what they used, who was involved and what it cost them in time. Only then do we show a concrete one-page description of the offer, and we ask what they would do with it on Monday. We write down their words and their actions in separate columns.
Buyers reach us from more than one place. Your sales and account teams can introduce people who already know you, and we help reach buyers you do not yet serve, because customers who like you are the easiest to please and the least informative. An offer cannot be tested on the people who proposed it.
How do we decide what the first release leaves out?
Every stakeholder has a feature that matters to them, and the first release grows until it holds them all. We start from the one job the buyer would pay to have done and ask of each proposed feature whether the buyer would notice its absence in the first month of use.
Features that fail the question go on an omissions list, with the name of whoever asked and the evidence that would bring the feature back. The list is read at the decision meeting. Leaving something out becomes a choice made with open eyes, not a gap discovered at launch.
The cheapest product decision is the one that ends before a build is commissioned.
A pattern we are called into
A scheduling tool that other hotel groups keep asking about
A hospitality group built a staff-scheduling tool for its own properties. Peers hear about it and ask whether they can use it. The product team has drawn a roadmap of integrations, a mobile app and a reporting suite, and wants build funding.
- Frame. We write the claims as things a buyer could prove wrong: who the buyer is, what they use today, and why they would switch from it. The first claim to fall is that the buyer is another group's operations director. The person who feels the problem is the property's front-office manager.
- Test. Conversations with managers at peer properties, and with the people who approve their software spending. They already run a spreadsheet and a messaging group, and they describe in detail what it fails to do.
- Shape. The first release is one job done well enough to be paid for: shift swaps that respect each property's rules. The mobile app, the reporting suite and every integration beyond the one the first buyers need go on the omissions list, with a reason beside each.
- Decide. Before the first conversation the group agreed what would make it build, change the offer or stop. The paper compares what buyers did with that standard.
Where it endsThe group builds a release far smaller than the roadmap, or it stops. Either way the revenue case rests on what buyers did, and nobody argues afterward about what counted as evidence.
What is on the table when leadership decides?
- An opportunity brief naming the buyer, the job to be done and the alternative in use today
- A record of the conversations that keeps what buyers said apart from what they did
- An offer description and positioning, tested against the alternative the buyer really has
- A first-release scope with the omissions listed and the reasons beside them
- A build, change or stop paper in which the stop rule was written before the evidence arrived
Is the offer worth testing before you build, or should you start elsewhere?
It fits when
- You hold a capability or a repeated customer request and have not yet committed build money
- Buyers are reachable, through you or through us
- Leadership would act on a no
- Product ideas in your company start from what you can build
Look elsewhere when
- You have decided to build and need the product defined, which is Product Strategy and Discovery
- You want the size of a market, which is commissioned research and a separate job
- You want the product built, which is Product Development
- The decision is already made and the work would only be asked to confirm it
You give up the feeling of progress that a started build provides. A build looks like momentum, and weeks of conversations do not. What you gain is a build budget that follows evidence.
What can this work not tell you?
It cannot tell you that buyers will come in numbers, only whether the ones we reach act like buyers. A stop is a valid result, and we say so before we begin. We do not promise demand or revenue.
We agree what counts as evidence in the scope, ahead of the conversations. If you cannot open the door to real buyers and we cannot reach them, we tell you before we start instead of testing on the wrong people.
Can you try the method on your own idea first?
The discovery canvas frames an opportunity on one page, and the assessment scores one. The field note on pilots explains why a working demonstration says little about the product that follows.
What do product leaders ask first?
How is this different from product strategy and discovery?
Product Innovation starts from a company with a capability or an opening and asks whether a new revenue line is worth building. Product Strategy and Discovery, under Products, decides what to build once a product is going ahead.
Do you need to talk to our customers?
Yes, or to buyers like them. We can work through introductions from your sales and account teams, and we can reach buyers you do not yet serve, who often tell you more than the customers who already like you.
What happens if buyers say no?
Then you have learned it before the build budget was spent. The paper records what buyers said and did, which parts of the offer failed, and whether a changed offer deserves another round or the idea should stop.
Can you also build the product?
Yes, as a separate scope under Product Development. Keeping them apart means the build decision rests on the evidence, not on the fact that we are available to do it.
Related
Is there a product in your capability that buyers would pay for?
Describe what you are weighing in a few lines. A senior practitioner replies with a suggested first conversation.