The Product Portfolio Function
Intake, discovery, prioritisation and roadmap — and the feasibility gate that is almost always missing from all four.
The portfolio function is where a product exists only as a decision. Nothing has been modelled, and nothing downstream can execute against any of it. Its inputs are unstructured; its output has to be defensible enough for the next function to start work and for finance to hold the business case.
Intake: four sources, four different failure modes
Ideas arrive from four places and not in the same condition. Treating them as one undifferentiated queue is the first way the function loses information.
The Four Intake Sources
| Source | Typical form | Arrives with | Usually missing |
|---|---|---|---|
| Market insight | Competitor launch, analyst view, pricing movement in the segment | A rationale, often with a deadline framed as competitive necessity | Any statement of what the operator can actually deliver against it |
| Customer feedback | B2C: research, churn drivers, support themes. B2B: a named account asking for something specific | Real demand signal; in B2B, a contract or a renewal behind it | The distinction between one loud account and a repeatable market |
| Internal ideas | Sales, product and operations raising what they keep hitting | Operational knowledge of where the current portfolio fails | A business case, and any owner once the raiser moves on |
| Regulatory / strategic | A legal obligation, a group mandate, a technology retirement | A non-negotiable date | Discretion — it is being prioritised whatever the value score says |
A B2B request carries a lever the other sources do not have, and it is legitimate input. But a portfolio built by answering the loudest accounts becomes a set of near-bespoke products that share no decomposition and cannot be sold twice.
Discovery and prioritisation
From Raw Idea to Prioritised Backlog
Capture and assess
Record the idea with its source and its evidence, and make an early call on whether it is in scope for the portfolio at all.
Define problem and opportunity
State the customer problem separately from the proposed product. Several ideas frequently turn out to be one problem with competing solutions.
Analysis
Size the opportunity, identify the target segment, and establish what would have to be true commercially and technically for it to work.
Prioritise on value, effort and fit
Score against commercial value, delivery effort and strategic fit. Fit is what stops a high-value, low-effort idea that pulls the portfolio somewhere it has decided not to go.
Create the backlog
Maintain an ordered, re-scorable list — not a set of approved commitments. Ordering changes as evidence and capacity change.
A value-versus-complexity matrix is the usual instrument, and it is only as good as its complexity score. Two things in that axis are consistently under-weighted: technical debt — a change to a system nobody will touch, or one whose current implementation was itself a workaround — and local regulation, where the same product is straightforward in one market and in another carries data residency or lawful intercept obligations that turn a shared specification into a per-market variant. The score is where the function is structurally weakest: the people producing it are least equipped to see the estate that would have to deliver it.
When it becomes an anti-pattern
Why organisations choose it. The portfolio team is the only group in the room, and prioritisation cannot conclude without a number. Waiting for service architecture to assess a whole backlog is not a realistic ask, so the number that gets used is the one someone in the room can produce. It is not dishonest; it is the best available answer to a question the room could not otherwise close.
What must hold for it to work. That the effort figure reflects three things the portfolio team cannot see: whether a resource-facing service already exists for what is being promised, whether the network footprint covers the target segment rather than the addressable market in general, and whether an activation path exists that does not end in a person doing something manually. Where all three hold — a variant of an existing product, in a served footprint, on an established activation route — the shortcut costs nothing.
How it fails. The date is committed before the service has been decomposed, and neither the portfolio function nor catalog governance catches it — an offering can be modelled above a decomposition nobody has confirmed. It surfaces in implementation, when someone goes looking for the RFS and there is not one, by which point the date is public and the business case is booked. The fix that ships is a manual workaround presented as temporary; it survives, because the only thing that would remove it is the modelling work the date did not allow. The cost is not the delay, it is the permanent operational load carried by every instance of that product.
The roadmap
The roadmap is the backlog viewed against time and capacity. It typically runs 12 to 16 months and is horizon-based rather than date-based: the near horizon carries committed items with dates, the middle carries intent with quarters, the far carries direction with neither. Sequencing follows value and delivery capacity, and it is capacity that binds — a roadmap that ignores it is a list of things the organisation would like to be true.
The horizon structure is what lets the roadmap demonstrate alignment upward: executives track macro objectives — segment growth, portfolio simplification, exit from a legacy technology — without granular delivery updates. Maintained instead as a delivery plan with per-item status, executive review becomes delivery review, and the far horizon disappears because nothing in it has a status to report.
Tooling is an enabler, not the process
Intake, scoring, backlog and roadmap are commonly implemented in a dedicated discovery tool — Jira Product Discovery, Aha! and Productboard among them. None of them is the function. The function is the decision discipline: what evidence is required at capture, who scores, what a score means, and what must be true before an item is committed — and it outlives the tool.
Why organisations choose it. Nobody chooses it; it accretes. The tool holds the definition earlier than the catalog does, so it is where anyone needing product copy before launch goes. Pointing at it is faster than asking the catalog function, and the first few times it is right.
What must hold for it to work. That nothing downstream reads it as authoritative — that it stays an input to the concept handoff and never becomes a reference for anyone producing customer-facing material or configuration. That holds only while every consumer knows the catalog exists and knows they are meant to use it instead.
How it fails. The two definitions drift silently, because the discovery record is not updated when catalog governance changes something during modelling — a characteristic constrained, a variant dropped, an eligibility rule added. The failure appears at the customer boundary: sales quotes the definition that was never modelled, and the order either fails validation or, worse, passes it and delivers something other than what was sold.
Where the feasibility gate belongs
Both anti-patterns are symptoms of the same missing control. It has to sit somewhere, and there are two defensible places to put it — chosen, usually, by default rather than deliberately.
Two Operating Models for the Feasibility Gate
| Model | Where feasibility is answered | What it demands | What it costs |
|---|---|---|---|
| Feasibility inside the portfolio function | Before prioritisation — the complexity score is produced with technical input | Service architecture embedded in portfolio governance, present at scoring rather than consulted afterwards | Scarce architecture capacity spent on items that will never be built, and a slower intake funnel |
| Fast round-trip to catalog governance | After a provisional ranking — the concept goes to the catalog function and comes back with a feasibility answer | A governance cadence fast enough that the round trip does not stall the roadmap | Rework when the answer changes the ranking, and a hard dependency on cadence discipline |
The first model suits a portfolio small enough that the assessment cost is bounded, or an estate heterogeneous enough that feasibility is genuinely unpredictable. The second fails in one specific way: if the round trip takes longer than the roadmap cycle, answers arrive after the roadmap has been socialised, the portfolio function stops waiting for them, and the organisation is back in the first anti-pattern with a governance process on top of it. The model is not wrong; the cadence was never funded to match the intake rate.
Both models require the answer to be written down and to travel with the concept. A feasibility assessment held in an architect's head does not survive the handoff, and the next function inherits a ranked concept with no record of what was assumed about delivering it.
Section 2.2 Key Takeaways
- The portfolio function decides what to build and in what order; it models nothing, and its deliverable is an approved product concept, not a specification
- The four intake sources carry different evidence and different pressure — B2B requests arrive with contractual weight, and a portfolio built by answering the loudest accounts produces near-bespoke products that cannot be sold twice
- Evidence is attached before estimation; once an idea carries a number, the number becomes the argument and the evidence is retrofitted to it
- The value-versus-complexity matrix is only as good as its complexity score, and technical debt and per-market regulatory requirements are consistently under-weighted in it
- Effort estimated without feasibility commits a launch date before the service is decomposed; the gap surfaces in the implementation function and is closed by a manual workaround that becomes permanent operational cost
- A discovery tool holding the product definition becomes a second source-of-record by accretion — the two definitions drift, and sales quotes the one that was never modelled
- The feasibility gate goes either inside portfolio governance, which costs architecture capacity, or in a fast round-trip to catalog governance, which fails the moment the cadence is slower than the intake rate