Start with the outcome, not an inventory of ideas
A feature list without an objective favours visible solutions that are easy to imagine. First define the desired behaviour or outcome: a customer compares options correctly, a team processes a request without duplication, or a user returns to finish a task. Ideas can then be evaluated by their contribution to that outcome rather than their popularity.
Separate the need from the shape of the solution
“Push notifications” is a solution. The need may be for a person not to miss a time-sensitive step. Email, a summary inside the product or a process change may address the same need with different effort and consequences. Keeping the need next to each idea allows simplification without losing the purpose.
- Who benefits from the feature, and how often does the situation occur?
- What evidence shows that the problem exists and matters?
- Which outcome should this solution change?
- Is there a manual or simpler version through which we can learn?
- What operating and maintenance cost appears after launch?
Assess value, effort and confidence separately
A single score can create an impression of precision that does not exist. It is more useful to discuss possible value, approximate effort and confidence in the assumptions separately. An idea with high value but weak evidence may first receive an experiment. A change with moderate value and very low cost may go in immediately. Estimates are conversation tools, not mathematical verdicts.
Find the smallest complete version
“Minimum” should not mean incomplete or careless. A small version must let someone finish a real journey, including error states, clear content and a way to get help. You can reduce the number of cases, automations or personalisation, while keeping the core promise. A collection of screens without a complete flow does not validate the product.
Do not confuse foundations with invisible features
Some work is not attractive on a roadmap but supports every delivery: the data model, permissions, baseline accessibility, monitoring or shared components. Explain it through the risk it reduces and the features it unlocks. At the same time, “foundation” should not become a reason for months of construction without a usable journey.
A healthy roadmap orders outcomes and questions, not promises about every screen imagined at the start.
Make the cost of every “yes” visible
Adding a feature means design, implementation, testing, documentation, support and future changes. It also means something else ships later. When the decision includes this opportunity cost, the conversation becomes more realistic. The person proposing an idea should also help define the conditions under which it can be postponed or removed.
Prioritisation continues after launch
A released version creates new information: what is used, where errors happen, what reaches support and which behaviour has not changed. Review the order using these signals. Keeping the roadmap unchanged only because it was approved turns the plan into an obligation even when reality contradicts the original assumptions.
- Choose one outcome for the next phase.
- Group ideas by the need they address.
- Mark the evidence, risks and dependencies of each idea.
- Define the smallest journey that delivers value end to end.
- Decide which signal will guide the next investment.