From idea to product.
Projects often begin with an idea for a solution: a customer portal, an internal platform or a new app. To turn it into a viable product, it must be clear whose problem it solves. This clarity prevents later debates about features nobody really needs.
Understand the current workflow
Start by looking at the situation without the new product. How do people complete the task today? Where do they wait, copy data manually or switch tools? Discussing specific situations often reveals more than a general wish list.
For a customer portal, the key difficulty might be documents scattered across emails and uncertainty about progress. The initial focus is then reliable documents and clear status information. A complex dashboard could simply distract from the real problem.
Turn wishes into testable assumptions
Describe the change the product should bring. ‘Customers should be able to find information themselves’ becomes more concrete when you name the questions they should be able to answer without contacting anyone. It should also be clear who will use the product and in what situation.
Separate established facts from assumptions. A simple list may be enough: what do we believe about the need? What information is missing? How can we obtain it with reasonable effort? This reveals which decision needs testing first.
Test the workflow first
A clickable prototype can show whether users understand a workflow. The database need not be complete, nor every API working. What matters is a realistic test task and participants acting as independently as possible.
Watch behaviour, not just approval. Can people find the information they need? Do they understand what happens after a click? Where do they need help? A prototype answers these questions, but does not yet prove that the final application can operate reliably or economically.
Keep the initial scope focused
The first usable version should cover one important workflow completely. For a portal, that could mean signing in securely, viewing personal documents and checking current progress. Additional reports can wait; basic access permissions and clear error messages cannot.
Working in small, testable steps makes early feedback easier. DORA also describes small batches as a capability associated with strong software delivery performance. The practical lesson for product planning is to scope changes so their value can be assessed promptly.
Further reading: DORA: Working in small batches ↗
Plan for operations and ongoing development
A product is not finished at its first release. It needs someone responsible for feedback, a process for fixing errors and visibility into usage and operations. Data migration, training and support are also part of the launch.
Schedule a review after launch. Which tasks are people actually completing? Where do they drop out? Which questions remain? The next development cycle should be based on these observations, not just another long feature list.
- Document a specific user problem and a clear objective.
- Test the most important assumptions before full implementation.
- Build a small but fully usable workflow.
- Assign responsibility for rollout, operations and evaluation.
A good digital product grows from understood problems and tested decisions — one step at a time.
Your next idea.
Have a specific use case in mind? Let’s explore your challenge together.
Discuss your project ↗