Product thinking / DIJION
How should you prioritize the next product decision?
Evaluate bugs, friction and feature ideas through impact, evidence, uncertainty and effort without losing their differences.
When ideas, bug reports and small improvements share one list, the most discussed item can rise to the top. Attention is not the same as user impact. A useful prioritization method makes the reasoning visible before producing a score. These examples are not the roadmap or revenue results of a real Dijion product.
Separate necessary repairs from experiments
A broken critical task, lost data or an access barrier should not compete directly with the possible benefit of a new feature. Address verified reliability problems first, then consider friction, improvements and uncertain ideas.
Different questions require different work. A small prototype may be enough for an uncertain feature. A reproducible defect needs a fix and regression checks. Choosing the right kind of task matters as much as its rank.
Write a short decision card
Scroll the table horizontally to see all columns.
| Field | Question |
|---|---|
| Person and task | Whose task is affected? |
| Observation | What happened and how do we know? |
| Impact | Is the task blocked, harder or made more valuable? |
| Uncertainty | Which assumption remains unverified? |
| Effort and dependency | Which content, access or technical change is needed? |
| Smallest next step | Repair, measurement, conversation or prototype? |
| Decision condition | What would make us continue, change or stop? |
Replace “Users want this” with its source: one message, a recurring support topic or an observed task. Do not claim prevalence when it is unknown. Weak evidence does not automatically make an idea worthless; it can make learning the appropriate next investment.
Compare impact alongside evidence
High, medium and low can be useful labels when their reasons are stated. “High: prevents completion of a submission” explains more than an isolated score. Estimate effort relatively within the same team and scope.
Scroll the table horizontally to see all columns.
| Task | Impact | Evidence | Next step |
|---|---|---|---|
| Input lost after submission | High | Reproduced in a controlled scenario | Fix and test adjacent flows |
| Confusing menu label | Medium | Hesitation in one observation | Revisit the label with the task |
| New badge system | Unknown | An idea was proposed | Test its contribution with a small prototype |
This table illustrates a method, not research findings. An impact-to-effort ratio can favor easy work and repeatedly defer a necessary accessibility repair. Keep a separate decision gate for essential quality work.
Record dependencies and the cost of reversal
A layout may be easy to build while its missing content leaves an empty page. A measurement experiment depends on events being collected correctly. Calling work complete before its dependency is resolved creates misleading inputs for later decisions.
An easily reversible layout experiment and a data-model change need different preparation. State the cost of reversal and the fallback if the idea fails. Match preparation to the risk rather than adding the same ceremony to every change.
Define a trigger for reviewing the decision
Replace “Later” with a condition: access becomes available, the prototype question is answered or the error is reproduced. A review date can help, but reaching the date does not turn insufficient evidence into a firm conclusion.
- Complete: The defined output exists and relevant checks passed.
- Learned: An assumption was examined; the solution may change.
- Waiting: A specific fact or dependency is missing.
- Deferred: Contribution to the current goal is lower, with a review condition recorded.
Five questions for a weekly review
- Which verified problem is the biggest obstacle this week?
- What is the smallest learning step that could change the next decision?
- Do we have evidence for the work marked complete?
- Which task is waiting for content or access?
- Has new information changed an earlier priority?
The list can change while the reasons remain traceable. This helps a team move through useful, testable and maintainable decisions rather than simply adding features.