When you start planning a software product, the list grows quickly. A dashboard. User accounts. Notifications. Reporting. Integrations. An AI assistant. An admin panel. Maybe a mobile app.
Each feature sounds reasonable on its own. The problem is that a collection of reasonable features does not necessarily add up to a useful product. A feature list is not a product strategy.
My starting point is a different question: what does someone need to get done, and what is stopping them from doing it today?
That moves the conversation from what the product could contain to what its first version needs to accomplish.
Start with a complete journey
Imagine a business that manages customer requests through email and spreadsheets.
It would be easy to propose a dashboard, a customer portal, a reporting engine and an automated follow-up system. But the essential workflow might be simpler:
- A customer submits a request.
- Someone reviews it.
- The request gets assigned.
- The customer receives an update.
- The team records the outcome.
Before adding more features, I would want to know whether that journey works from beginning to end.
Can someone tell what needs attention? Is ownership clear? Can the customer understand what happens next? What happens when information is missing? Watching people do the work today, in discovery calls and walk-throughs, is how I find out.
A product can have very few features and still solve that workflow well. It can also have dozens of features and leave the underlying problem untouched.
Cut breadth before you break the journey
My preferred way to reduce scope is to support fewer scenarios well rather than every scenario halfway.
An early release might support one request type, one team and one approval path. That can be a deliberate boundary.
What I would avoid is removing the confirmation message, the error handling or the status visibility that make the core journey understandable.
Clear feedback is not decorative polish. W3C's accessibility guidance calls for telling users whether a submission succeeded, explaining errors and helping people correct them.
The distinction matters. Optional breadth can wait. The pieces that let someone finish the task need attention now.
Give every proposed feature a job
For each feature, I would ask:
- Which step in the workflow does this improve?
- What problem does it solve?
- What happens if we leave it out?
- Is it needed to deliver value, or does it depend on value we have not demonstrated yet?
- Could a manual step answer the same question during an early test?
These questions are not about making the product less ambitious. They are about making the first investment more intentional.
An advanced reporting system may eventually be essential. But if nobody can reliably complete the underlying transaction, reporting is not the first problem to solve.
Define the first release as an outcome
"We are launching twelve features" tells me what the team plans to produce.
"A customer can submit a request and get a clear decision without an email chain" tells me what the product is supposed to change.
That is a much better foundation for design, development and evaluation. It is also the kind of statement that becomes acceptance criteria when the spec comes before the code.
The first release does not need to represent the full future of the business. It needs to complete a meaningful job well enough that you can learn what deserves to come next.
If your v1 plan is a long feature list, take the two-minute v1 check, or email me and we can find the workflow underneath it.