Case 05 / Product Governance
Prioritising when every request is legitimate
Short-term customer opportunities, strategic product development, technical stability and limited capacity — made steerable at the same time.
- Role
- Head of Product Retail
- Context
- B2B software vendor, retail technology
- Reading time
- 3 minutes
Photo to followPhoto for this case
Executive Summary
01 / 07A governance approach that makes prioritisation decisions traceable and translates strategic themes into decidable roadmap packages, instead of assigning priority by volume.
The situation
02 / 07Every request justified. Not every request feasible.
Several realities met at the roadmap: strategic market positions, technical necessities, available engineering capacity, MVP scope, budget, timing, UX, testing and rollout. Alongside it ran formats that had to bring together sales pipeline, concrete project demand, story readiness, engineering questions and hardware requirements.
None of these inputs was illegitimate. That is exactly what makes the situation hard — there is no proposal you can simply reject.
- Market positions
- Technical necessities
- Development capacity
- MVP scope
- Budget
- Timing
- UX
- Testing
- Rollout
= none unjustified, none easy to turn down
The real problem & My mandate
03 / 07Weeks, quarters, years – all competing for the same capacity.
The organisation had to steer different time horizons simultaneously. A customer opportunity counts in weeks, strategic product development in quarters, technical stability in years. All three compete for the same capacity, and all three are right.
Without shared governance three things reliably follow: priorities emerge by volume rather than by impact, accountability stays unclear, and the roadmap promises more than can realistically be delivered. The third is the most dangerous, because it only shows up late — and then appears as a loss of trust rather than a planning error.
Customer opportunity
Weeks
Product development
Quarters
Technical stability
Years
My mandate
As Head of Product Retail, at the interface between the outside view and internal delivery: formulate strategic requirements, structure roadmap demand, and prepare decisions with product, engineering, sales and management stakeholders.
Prepare is the operative word. The decision itself had to be made where the consequences are owned — not in the product function, which otherwise absorbs it quietly.
Approach
04 / 07From volume to explicit criteria
- A
Clarify roles at the roadmap
Strategic market positions and technical necessities were treated as different but equally valid inputs. Where technical work counts as leftover, it gets deferred until it returns as a crisis.
Equal inputs
- Strategic market positions
- Technical necessities
- B
Make decision criteria explicit
Demand, resources, MVP scope, timing, dependencies and rollout impact were considered together rather than in sequence. Criteria that are not spoken still operate — only uncontrolled.
Considered together, not in turn - Need
- Resources
- MVP scope
- Timing
- Dependencies
- Rollout impact
- C
Move from themes to decidable packages
Large initiatives had to be translated into understandable scopes, MVPs and prioritisable steps. You can like a theme. You can only decide on a scope.
- 01Initiative
- 02Scope
- 03MVP
- 04Prioritisable step
- D
Establish a stakeholder rhythm
Regular alignment was meant to bring pipeline, project demand, story readiness and technical risk together early. Governance works through frequency, not through documents.
- Pipeline
- Project demand
- Story maturity
- Technical risks
Stakeholder rhythm
The trade-offs
05 / 07Four tensions at the roadmap
- Customer commitmentproduct strategy
Individual requirements can secure revenue but must not turn the product into a collection of special cases. The cost of that conversion appears in no deal calculation.
- Innovationstability
New capabilities compete with quality work and technical necessities for the same people. Stability has no advocate in sales.
- Scopespeed
A cleanly cut MVP delivers value faster but demands disciplined refusal of well-meant additions.
- Transparencynegotiating room
Clear criteria increase traceability but make uncomfortable capacity limits visible. Whoever creates transparency loses the option of deferring conflict.
Outcome
06 / 07- 01
A clearer shared picture of roadmap accountability emerged, along with better connectivity between strategic themes and technical delivery.
- 02
The decision logic considers business value, effort, timing and risk together rather than in isolation. The gain lies less in better individual decisions than in the fact that conflicts get structured early — instead of escalating late in delivery.
What I took from it
07 / 07Governance works when conflicts are structured early, rather than escalating late in delivery.
The uncomfortable part is not the method but its consequence: visible criteria take away everyone's ability to treat undecided things as decided. That initially produces more friction, not less.
Competences shown
- Product Governance
- Roadmap Leadership
- Resource Allocation