CDT504 Chap.1 Product Development from Opportunity to Launch
Product Development from Opportunity to Launch
Why the process is integrated
Product development begins with an opportunity and ends with production, sale and delivery. The generic process moves from planning into concept work, system architecture and detailed definition before verification, refinement and production ramp-up. Marketing, design and manufacturing contribute different evidence, so a late defect often traces to an assumption made earlier.
The practical skill is to locate the phase where a concern appears and the earlier decision that should have controlled it.
The front end
Customer needs, competitive evidence, target specifications, concept alternatives, selection, testing and final specifications interact before the remaining project plan is committed.
Process variants change timing and overlap, but they do not remove the need for explicit evidence and outputs.
What this chapter covers
- 01
Six generic development phases
- 02
Cross-functional integration
- 03
Front-end activities
- 04
Process variants
- 05
Iteration and reflection
- 06
Phase outputs
Worked example · free
Trace a cleanability failure
- 2Name the visible phase and earlier missed decision.
- 2State the evidence and metric needed.
- 2Propose the next iteration.
Key terms
- Development Process
- The coordinated sequence used to conceive, design and commercialise a product.
- Concept Development
- The front-end phase in which needs, specifications, concepts and tests are integrated.
- System-Level Design
- The phase that establishes product architecture and subsystem relationships.
- Detail Design
- The phase that completes geometry, materials and production specifications.
- Ramp-Up
- The transition in which production capability and product delivery are established.
Product Development from Opportunity to Launch FAQ
Why is product development not only a design task?
Commercial success depends on customer evidence, product form and function, and the ability to manufacture and deliver reliably at acceptable cost. Treating one function as the whole process hides decisions that another function must later repair.
Does the generic process have to be linear?
No. The phases provide a shared map, but testing, supplier evidence or customer feedback can send a team backward. The important discipline is to record the changed assumption, affected output and reason for iteration.
What should a phase-based answer include?
Name the phase, identify its expected output and explain how that output constrains the next decision. If a defect appears during testing, also trace it to the earlier need, concept, architecture or detail decision that admitted it.
How do process variants preserve discipline?
They may overlap phases, shorten release cycles or add specialised reviews, but they still frame an opportunity, establish needs, compare alternatives, test performance and learn from results. The variant changes timing and evidence depth according to risk; it does not remove the obligation to state what decision each activity supports.
What makes iteration different from rework?
Iteration responds to new evidence by changing a named assumption, output or decision. Rework repeats an activity because ownership, criteria or information were unclear. A strong explanation identifies the evidence that triggered the loop, the earlier artefact revised and the downstream decisions that must be checked again.
How can a team audit the handoff between phases?
Check that the receiving phase can identify the decision, evidence, owner and unresolved risk in the prior output. A handoff is weak when it transfers a polished document without the assumptions that shaped it. Review one downstream failure and ask which missing fact would have changed the earlier choice.
Record the answer beside the responsible owner, the next evidence action and the decision date so the handoff can be reviewed later.
Assessment move
Draw the six phases and put one output beneath each. Take a familiar product and trace one defect backward from use to the earlier decision that should have prevented it. Then compare a generic process with a digital or high-risk variant, naming what overlaps and what evidence remains invariant. Practise separating the phase where a problem is discovered from the phase that owns the corrective decision.
Build a phase ledger with four columns: input, decision, output and downstream risk. For planning, identify the opportunity and constraints that authorise concept work. For concept development, link needs to target specifications, alternatives and test evidence. For system-level design, show how functions become chunks and interfaces.
For detail design, name the drawings, materials and production information that remove ambiguity. For testing, distinguish verification against specifications from learning that invalidates an earlier assumption. For ramp-up, identify the evidence that production and delivery can perform consistently. Work a failure case in both directions.
Starting at a late symptom, move backward until you find a decision that could have been changed. Starting at that decision, move forward and list every output it affects. This reveals why cross-functional communication matters without reducing integration to meetings. Create one comparison between a market-pull product and a quick-build digital service.
The digital service may overlap test and ramp-up, release to a small group and revise frequently, yet it still needs a defined user outcome, measure and decision rule. Finish by explaining when iteration is disciplined. A loop is justified when new evidence changes an assumption or output; repeating work without naming what changed is rework, not learning.
In a quiz response, lead with the phase and expected output, then state how the missing or weak output causes the observed problem. In project review, ask one representative from marketing, design and operations to challenge the assumption most likely to fail in their domain. Record the challenge and owner rather than relying on memory.
