Shaping a product: from a problem to a first release
Before a feature list, a first product needs one decision: how it should solve the problem as a whole. What shaping connects, and what it does not promise.
Product2 min read
A first conversation about software often starts with a list of features. Log in, add a client, send a reminder, show a report. The list is useful, but it skips a step.
Shaping is that step. It works out how the product should solve the problem as a whole, before anyone decides what goes on which screen.
Three things it connects
- The problem you have agreed to solve, stated plainly enough that you and the team would describe it the same way.
- The people who use the product and the workflows they go through, from signing up to finishing the job they came to do.
- The features, and which of them belong in the first release rather than a later one.
When those three line up, most feature arguments settle themselves. A feature either helps someone get through a workflow that matters in the first release, or it waits.
What it looks like in practice
De-Posit's founder wanted tenants to move in without a cash deposit, while landlords stayed protected. The product decision was to swap the cash deposit for a secure pre-authorisation, with the landlord's protection visible throughout.
A feature list would not have made that decision. It came from asking what each person in the rental chain needed before they would trust something new.
Have a concept that needs shaping?
A short call is enough to see whether Planning is the right next step.
Book an introductory callWhat shaping is not
It does not promise every possible feature, independent proof of demand, or commercial success. You know your market and you make the business decisions. Shaping makes sure the first release is a sensible one to put in front of that market.
Where it happens
Shaping is the core of Planning. It ends in a clickable prototype of the main workflows and a clear scope for the first version.