CDT504 Chap.3 Product Planning and Portfolio Choices
Product Planning and Portfolio Choices
Plan before committing the full team
Product planning selects projects from a broader portfolio and aligns them with strategy, market segments, platforms, technology timing and finite capacity. The portfolio may include new platforms, derivatives, incremental improvements and fundamentally new products.
These categories serve different purposes and should not be flattened into one comparison without first deciding the strategic allocation across them.
Mission and roadmap
The process identifies opportunities, prioritises projects, allocates resources and timing, completes pre-project planning and reflects. A mission statement records the benefit, market, goals, assumptions and stakeholders.
A roadmap exposes whether enabling technology will be ready before a promised launch.
What this chapter covers
- 01
Portfolio categories
- 02
Competitive strategy
- 03
Market segmentation
- 04
Technology roadmaps
- 05
Resource allocation
- 06
Mission statements
Worked example · free
Choose a strategy-aligned portfolio
- 2Connect evidence to strategy.
- 2Compare project roles.
- 2State capacity and monitoring conditions.
Key terms
- Product Planning
- The periodic process that selects and times development projects before full commitment.
- Product Platform
- A shared foundation from which a family of related products can be developed.
- Derivative Project
- A project extending an existing platform for a familiar or adjacent market.
- Technology Roadmap
- A time-based view linking technology availability to future product use.
- Mission Statement
- A pre-project document stating benefit, market, goals, assumptions and stakeholders.
Product Planning and Portfolio Choices FAQ
Why are all project types not ranked together?
Incremental support, platforms and breakthrough work serve different strategic purposes and carry different uncertainty. Allocate resources across categories first, then compare projects that genuinely compete for the same purpose and capacity.
What does a technology roadmap prove?
It does not predict the future precisely. It reveals dependencies and timing mismatches, such as a promised launch that relies on a subsystem expected to mature later.
Why should capacity remain below full utilisation?
Uncertainty creates rework, repeated tests and urgent support needs. A plan that commits every specialist and facility leaves no room to respond when an assumption fails.
What belongs in a resource-aware product plan?
Include specialist effort, prototype and testing facilities, supplier dependencies and timing rather than budget alone. Show when projects compete for the same constrained resource, which commitment moves and what strategic outcome is delayed. This turns an attractive portfolio into a sequence the organisation can execute.
How should assumptions appear in a mission statement?
Name them as propositions still requiring evidence, assign an owner and state the decision they can change. A service partner, technology date or adoption claim should not be written as fact simply because the project has been authorised. Visible assumptions allow revision before concept work becomes expensive.
Why should a portfolio show opportunity cost?
Selecting one project consumes people, facilities and timing that cannot support another. Naming the displaced work prevents a recommendation from implying that every attractive initiative can proceed. It also gives managers a concrete trade-off to revisit when customer evidence, technology readiness or available capacity changes.
Assessment move
Create a four-column portfolio using the project categories from the lesson and write the strategic purpose of each column. Add one dependency to a technology roadmap and identify the latest decision point for an alternative. Finish by drafting a mission statement that names a benefit and target market without embedding a favourite feature. Build the portfolio in two stages.
First allocate attention across new platforms, derivatives, incremental improvements and fundamentally new products according to strategy. Then compare candidates within each category. This prevents a low-risk maintenance project from defeating every exploratory project merely because its return estimate is more certain.
Add a capacity row for specialist effort, prototype facilities and test windows, because budget alone does not create those resources. Place each project on a simple timeline and mark dependencies. Where a launch relies on an immature technology, write the fallback, decision trigger and latest change date.
Practise explaining why a roadmap is useful without claiming it predicts exact availability: it exposes commitments whose timing is inconsistent. Draft a mission statement with product description, benefit proposition, target market, business goals, stakeholders, assumptions and constraints. Read it again and remove any feature that belongs in concept generation.
Mark every assumption that could invalidate the project and assign an evidence action. Now stress-test the plan. Introduce a customer complaint, a delayed subsystem and the loss of one specialist. Decide which project changes and show the opportunity cost. A good planning answer acknowledges displaced work rather than implying every attractive initiative can proceed.
End with a monitoring rule that states when the portfolio will be reconsidered and what evidence will trigger reprioritisation. For quiz revision, be able to distinguish the four project types and the five planning moves. For project work, use the mission statement as a boundary document: it should guide local choices but remain open to alternative concepts that deliver the stated benefit.
