Product Thinking · Published June 5, 2026
Prioritisation: The Loudest Voice Is Not the Most Important
Priority should follow reach and criticality, not the seniority of whoever asks.
The most familiar scene in a project is the loudest person in the meeting getting their feature scheduled first. After launch it turns out only they use it, while a quiet department's real pain was never addressed.
Three dimensions to judge
Reach: a feature used by one person and one used by a hundred are not comparable.
Blocking level: can the business continue without it? If there is a workaround, it can wait.
Substitution cost: if a spreadsheet solves it today, do not build software first.
Make priority visible
Publish the requirement list and ranking on a shared board so everyone can see where their item sits and why.
Review the ranking every two weeks. It can change with the business, but the reason must be stated rather than applied through pressure.
The hard part of prioritisation is not the method, it is helping requesters accept the outcome. Transparency is the best explanation.
← Previous post
Making Code Review Work in a Small Team
Next post →
Retrospective: A Third Party Changed a Field Silently
Want to apply these ideas to your project?
We are happy to go deeper into implementation details, or to discuss the specific questions you are facing.
Start a conversation →