Product Foundations: what to agree on before you set a direction
A team is asked for a product strategy, OKRs or product outcomes to steer discovery. The discussion takes detours and people fumble. An hour later nobody is wiser, and they disagree about priorities.
When I have seen that meeting in teams I coach, the team was vague about what its product is, which specific problems it solves and who has those problems. They talked about what the product could do in theory, or what they wished it did, and about users only in general terms.
Every forward-looking deliverable describes a change from where the team stands today. If the team can’t say where it stands, there is nothing to describe a change from. Each person fills the gap with their own version, so every proposal makes sense to someone.
When it’s hard to agree on a clear direction, the foundations might be what’s missing.
Not every team has this problem. I have met it where experience of product work is low, and in companies moving from a feature factory to a product operating model.
Check what you have, then where you are
Imagine being dropped by a river bank in the Amazon. The objective is clear: get back to civilisation. Before you take a step, you check what you have with you. If you have a boat but no shoes, you take the river. If you have shoes but no boat, you walk. Then you work out, as precisely as you can, where you are. Only then can you choose a first step that, as far as you know, leads the right way.
A product team needs the same two inputs. Where you are is your baseline numbers. What you have is the product: what it is, what problem it solves and for whom. The teams I describe above tend to just assume they already agree on what the product is and what problem it solves, even though none of them can answer those questions with ease.
I have found one exercise helpful to solve this, and I call it Product Foundations. It used to be only an exercise, a discussion for alignment, but with agentic development it has also become an important artifact. More on that later.
Together, eleven questions give a very clear description of what a product is today. A team that can answer them will find it easy to do strategy, OKRs and outcomes. A team that can’t answer them gets a very good starting point for where to discuss and research to answer what’s missing.
What the eleven questions ask, and why
| Question | What the answer holds | Why it is there |
|---|---|---|
| 1. Name | The product’s name, as the team uses it. | So everyone means the same thing. |
| 2. Description | What the product is, in 1 to 2 plain sentences, true today. No marketing language, no ambition written as fact. | The answer a new colleague or stakeholder reads first. If the room can’t agree on it, the wording is rarely the obstacle. |
| 3. Core functionality | A short list of what makes the description true. | Shows whether the description holds, and at what level the product exists. |
| 4. User groups | The groups you build different functionality for, by role and situation, not organisation. | Each group needs functionality the others don’t. A group named because it is wanted, rather than served, sends the build after people who aren’t there. |
| 5. Problem | A problem one person has that the product solves. | In B2B an organisation has no problems; the people in it do. A problem you can talk to a person about is one you can test. |
| 6. Use cases | The known use cases where your product is used to solve the user’s problem, one per line. | The same problem comes up in different situations: a valuer may need a forest valuation for a sale, an insurance claim or a loan. Build from the use cases you know of and who has them, rather than from market segments. |
| 7. What customers use today | How they solve it without you. | The evidence that the problem exists, and what you compete with. If nobody does anything about it today, the problem may not hurt enough. |
| 8. Why you, and the cost of switching | Why they would switch, and why those who have it stay. | Switching costs something. If the gain isn’t clear to the person with the problem, they stay where they are. |
| 9. Acquisition | How customers find and buy it, and whether the buyer is the user. | A product nobody finds without a salesperson in the room grows with sales capacity, not with demand. |
| 10. Monetization | How you charge. | The pricing model shapes how the product is built, and is shaped by who buys. |
| 11. Ideal customer profile | Traits of the buyer that let you say yes or no to a prospect. A list, not a persona. | Decides what gets built next, which requests get priority and where sales spends its time. |
Product Foundations is what you have. Your baseline numbers are where you are. The free benchmark.scilla.studio tool shows how they compare: it charts retention, activation and unit economics against B2B and consumer ranges.
One more use: agentic development
Articulating the foundations has gained one more use. In spec-driven development, AI agents write the code from a spec. An agent that has the foundations and the product outcome as context can flag new development with no clear impact before anyone builds it. Later, it can help measure the impact the work had. What I am testing is in spec-driven AI development doesn’t have to reinforce the feature factory.
Frequently asked questions
See where your numbers actually land
Plot your retention, CAC payback, LTV:CAC and K-factor against the B2B and Consumer bands, and find out whether a good-looking number is real or sitting on a leaky retention curve.
Run the growth diagnostic →