The Product Portfolio Function
Last updated 12 Oct 2026
At a glance
The product portfolio function decides what to build and in what order. It assesses ideas against value, effort and strategic fit, keeps a prioritised backlog and a roadmap, and models nothing. Its output is an approved product concept, handed to catalog governance.
The picture
1 · Intake
Market insight
Usually missing: What the operator can deliver
Customer feedback
Usually missing: One loud account vs a market
Internal ideas
Usually missing: A business case and an owner
Regulatory / strategic
Usually missing: A choice: it often must happen
2 · Discover and prioritise
Evidence attached before any estimate
Value × effort × strategic fit
Feasibility gate
Can the service be delivered at all? Answered here, or by a fast round-trip to catalog governance.
3 · Backlog and roadmap
4 · Hand-off
Approved product concept
with its evidence and feasibility answer
→ Catalog governance models it
Nothing here is modelled yet: the portfolio function decides what to build and in what order.
How it works
Intake: four sources, four gaps
| Source | Arrives with | Usually missing |
|---|---|---|
| Market insight | A rationale, often a competitive deadline | Any statement of what the operator can deliver |
| Customer feedback | Real demand; in B2B, a contract or renewal behind it | Whether it is one loud account or a repeatable market |
| Internal ideas | Knowledge of where the current portfolio fails | A business case, and an owner once the raiser moves on |
| Regulatory / strategic | A non-negotiable date | Discretion: it happens whatever the value score says |
A portfolio built by answering the loudest accounts becomes a set of near-bespoke products that share no decomposition and cannot be sold twice. The B2B request is legitimate input; it is not the whole portfolio.
Evidence before estimates
Evidence has to be attached to an idea before anyone estimates it. Once an idea carries a number (an effort figure, a revenue projection, a date), the number becomes the argument and evidence is retrofitted to it.
Prioritising
A value-versus-complexity matrix is the usual instrument, and it is only as good as its complexity score. Two things are consistently under-weighted in that score: technical debt (a change to a system nobody will touch) and per-market regulation. And effort is not feasibility: effort asks how much work; feasibility asks whether there is a path at all. That question is answered at the feasibility gate.
Backlog and roadmap
The roadmap is the backlog against time and capacity, typically 12 to 16 months and horizon-based: committed items with dates near, intent by quarter in the middle, themes without dates further out. That lets it show alignment to executives without promising dates it cannot keep.
Who owns what
| Entity | System of Record | System of Engagement | System of Reference | Notes |
|---|---|---|---|---|
| Idea and its evidence | Product portfolio (discovery tool) | — | — | Input only; not a product definition |
| Prioritised backlog and roadmap | Product portfolio | — | Catalog governance, delivery | — |
| Feasibility answer | Service architecture, recorded on the concept | — | Product portfolio, catalog governance | Must travel with the concept, not live in an architect’s head |
| Approved product concept | Product portfolio | — | Catalog governance | The hand-off to modelling |
| Product offering and specification | Product catalog (catalog governance) | — | — | Never the discovery tool |
In practice
Intake, scoring, backlog and roadmap usually live in a discovery tool such as Jira Product Discovery, Aha! or Productboard. The tool is not the function: the function is the discipline of what evidence is required, who scores, and who can approve.
Two things go wrong in practice. A launch date is committed on an effort estimate before anyone confirms the service can be delivered, and the gap surfaces in implementation as a manual workaround that becomes permanent. And the discovery tool, which holds the product description earlier than the catalog does, starts being read as the product definition; the two drift, and sales quotes the version that was never modelled.
The trade-off
What it solves
A single, evidenced queue of what to build next, with a roadmap the business can plan against and a concept that catalog governance can model.
What it does not solve
- It does not establish that a service can be delivered; only the feasibility gate does.
- It does not define the product: the definition belongs in the catalog.
What it adds
- Architecture capacity spent assessing ideas that will never be built.
- A second, informal product description in the discovery tool that has to be kept from becoming authoritative.
Architecture decision
Where does the feasibility gate sit?
Inside the portfolio function, before ranking
Choose when The portfolio is small enough to assess every item, or the estate is so varied that feasibility is genuinely unpredictable
A fast round-trip to catalog governance, after a provisional ranking
Choose when Governance runs on a cadence faster than the intake rate, and the team accepts rework when an answer changes the ranking
Breaks if The round trip is slower than intake, so ranked items pile up unassessed, or the feasibility answer is not written down and lost at hand-off.
Takeaways
Key Takeaways
- The portfolio function decides what to build and when; it models nothing.
- The four intake sources carry different evidence and different pressure; the loudest account is not the market.
- Attach evidence before estimating; effort is not feasibility.
- The feasibility answer must be written down and travel with the concept to catalog governance.
- The discovery tool is an input, never the product source of record.
Check yourself
A large enterprise customer asks for a bespoke variant with a contract renewal attached. How should the portfolio function treat it?Show answerHide
As legitimate input with real weight, scored like any other idea. If every such request is answered directly, the portfolio fills with near-bespoke products that share no decomposition.
Sales is quoting a product description that differs from what the catalog holds. What has happened?Show answerHide
The discovery tool has become a second product source of record. The catalog definition changed during modelling and the tool was never updated; only the catalog should be read as authoritative.