In one line: Deciding which projects the organization will fund, in what order and with what resources. It is where strategy becomes a portfolio of real development work.
Core idea
No organization can pursue every good idea. Product planning is the periodic process that chooses the portfolio of projects, sets their timing, and hands each chosen project a clear charter. Its outputs are a product plan (often drawn as a roadmap of products over time) and a mission statement for each project. Some of these choices are big bets, commit-or-decommit decisions that set the tone for how a company invests for years.
How it works
In Ulrich and Eppinger’s framing [1], planning proceeds in five steps:
- Identify opportunities from many sources (see Opportunity Identification).
- Evaluate and prioritize them using four lenses:
- competitive strategy: technology leadership, cost leadership, customer focus, or imitation;
- market segmentation: which customers, with which needs;
- technological trajectories: which technologies are maturing, and when to switch;
- product platform planning: which shared assets future products can build on.
- Allocate resources and plan timing, balancing capacity across projects and sequencing launches along the roadmap.
- Complete pre-project planning: write the mission statement, assumptions and constraints, and staff the core team (see Product Mission Statement).
- Reflect on the results and the process.
Planning horizons are long. A course example traces a waterfront district over seventy years, through decades of infrastructure projects and into flood-risk planning for 2050. Good planning asks what the world will look like when the product (or the bridge, or the seawall) has to perform.
In practice
Two questions make product planning concrete inside an engineering company. First, can you get a copy of the product roadmap, current or historical, and see where your work fits? Second, how are products actually approved, and by whom? The gap between the official process and the real one usually explains which projects survive. When describing any project to decision-makers, the most useful test is the blunt one: so what, and who cares? A related reading argues that every project team should begin by answering why the project exists, in problem-focused terms, before planning what it will do [2].
Questions to ask yourself
- Which competitive strategy does my organization’s product plan reflect, and is that deliberate?
- Where does my project sit on the roadmap, and what would happen if it slipped a year?
- Can our team state, in one sentence, why this project exists?
Connections
- Inputs: Opportunity Identification. Outputs: Product Mission Statement.
- Wider frames: Business Strategy, Product Development Funnel. Financial test: Product Development Economics.
- Capabilities exercised: Vision, Decision Making, Realizing the Vision.
Sources
- Ulrich and Eppinger - Product Design and Development [1]
- Brown, Hyer and Ettenson (2013) The Question Every Project Team Should Answer [2]