Ideas can come from anywhere. Data analytics surfaces an unexpected usage pattern. A customer support ticket reveals a widespread pain. A competitor ships something that makes your product look weak. A founder has a vision.
As a PM, your job is to build an idea acquisition process that keeps you on top of all opportunities — and then to systematically narrow them from messy possibility to shipped product.
The pipeline: from idea to roadmap
Ideas flow into a backlog — the running collection of requirements, ideas, and candidate features. "Backlog" is the technical term for what many companies call the opportunity pipeline. Everything that might get built lives here.
Not everything in the backlog gets built. The PM's job is to prepare a roadmap from the backlog — a prioritized plan of what will be built and when, designed to meet business goals over a defined time horizon. Roadmaps have many formats (we cover these separately), but the purpose is the same: translate the infinite space of possible work into a finite, sequenced plan.
Where ideas come from
| Source | Characteristics |
|---|---|
| Customer-driven | Specific requests from existing clients. Often customized to a single situation. Usually not scalable without adaptation. |
| Market-driven | Opportunities spotted in a market segment. Repeatable solutions that work across multiple customers. Examples: iPhone, Zoho's enterprise suite. |
| Technology-driven | Breakthroughs that create new possibilities. Google's search algorithm. Hololens. AI. The technology comes first; the product use case follows. |
| Internal | Input from sales, support, and operations teams who interact with customers daily. Often the richest source of specific, actionable insights. |
From roadmap to ship
Once a feature makes it to the roadmap:
-
Product definition: The PM writes detailed specifications based on user research, data analysis, and business goals. This is the PRD (Product Requirements Document) — the contract between product and engineering.
-
Design: The design team takes the PRD and produces mockups and UI specifications.
-
Development: Engineers use the designs to build and test the product.
-
Launch: The feature ships to users.
-
Measurement: The PM monitors the key metrics defined in the PRD. Did the feature change the metric it was supposed to change? Did users adopt it? If not, what changed and what's next?
The Stage-Gate system
For larger product initiatives, the Stage-Gate framework provides a structured way to manage risk across the development process.
The core idea: divide the development journey into stages (phases of work) separated by gates (go/kill decision points). Before moving from one stage to the next, the team must complete specific activities and pass a management review.
Stage 0 — Discovery: Generate and refine ideas. Identify opportunities.
Stage 1 — Scoping: Quick, inexpensive assessment of technical feasibility and market potential. Should take days or weeks, not months.
Stage 2 — Business Case: The critical homework stage. Technical, marketing, and business feasibility are assessed. Outputs: product definition, project justification, and project plan. This is the stage that makes or breaks the project — if you cannot justify it here, you should kill it.
Stage 3 — Development: Plans become deliverables. The product is designed and built. Launch and test plans are defined.
Stage 4 — Testing and Validation: Validate the product itself, the production process, and customer acceptance. Verify the economics.
Stage 5 — Launch: Full commercialization.
Each stage costs more than the preceding one. This is deliberate — risk is managed by increasing spend only as uncertainty decreases.
Gates: where bad projects die
Gates are the go/kill and prioritization decision points between stages. They serve three purposes:
- Quality of execution: Did the team complete the required activities in the last stage?
- Business rationale: Does the business case still hold?
- Quality of the action plan: Is the path forward clear and credible?
Gates should produce three outputs: a decision (go/kill/hold/recycle), a path forward, and a date/deliverables for the next gate.
Think about the last feature you worked on (or are working on now).
- Where did the idea come from — customer, market, technology, or internal?
- Does your organization have a formal gate between idea and development? What is it?
- After launch, what metrics did you measure? Were they defined before development started?
Most teams discover they have a vague version of this process but skip the gate discipline. The consequence is building things that should have been killed at Stage 2.
The continuous loop
The product lifecycle is circular. Measurement at launch feeds back into the backlog. User feedback generates new ideas. Market changes create new opportunities. Technology advances open new possibilities.
The PM's job is not to manage projects. It is to manage this loop — ensuring the product continuously creates value for users and the business, stage by stage, iteration by iteration.