Product Development Processes and Operating Models

Introduction and context

Product development is not only the work of designing features. It is the coordinated process through which an organisation identifies a customer or societal problem, creates a solution, verifies that the solution is desirable and feasible, delivers it, and learns from its use. An operating model is the pattern of roles, decision rights, work sequences, governance mechanisms, funding arrangements, and performance measures used to manage that process.

The choice of operating model matters because products differ substantially. A mobile application can often be changed daily at relatively low cost. A medical device may require controlled design documentation, clinical evidence, supplier qualification, and regulatory approval before release. A new banking service may combine software with legal controls, operational procedures, cybersecurity requirements, and customer-support capabilities. No single process is universally superior.

This chapter compares stage-gate, lean startup, agile, Scrum, Kanban, dual-track discovery, and hybrid approaches. It also develops a practical method for selecting an operating model according to uncertainty, regulation, physical complexity, service characteristics, and digital delivery conditions.

Learning objectives

By the end of this chapter, you should be able to:

1. Explain the purpose and structure of major product-development processes.
2. Distinguish agile as a set of values and principles from Scrum and Kanban as operating frameworks.
3. Compare processes according to uncertainty, reversibility, risk, interdependence, and regulatory burden.
4. Explain how discovery and delivery can be connected through a dual-track model.
5. Select and design a suitable operating model for digital products, hardware, regulated products, and services.
6. Identify common implementation failures and propose appropriate governance, metrics, and improvement practices.

1. Product development as a learning and delivery system

A development process performs four connected functions:

• Opportunity identification: understanding customers, users, markets, technologies, and unmet needs.
• Solution development: designing and building a product or service.
• Risk reduction: testing assumptions about desirability, feasibility, viability, safety, security, and compliance.
• Value delivery and learning: releasing the product, observing outcomes, and adapting future work.

These functions are often shown as a sequence, but real product development is iterative. A usability test may reveal that the original problem was misunderstood. A prototype may expose a manufacturing constraint. A compliance review may require a change to the business model. Effective operating models therefore create controlled feedback loops rather than treating the initial business case as permanently correct.

Two dimensions are especially useful when comparing models:

1. Uncertainty: how much is unknown about customer needs, solution performance, technology, market demand, or economics.
2. Cost and consequence of change: how expensive, slow, or dangerous it is to alter a decision after work has progressed.

When uncertainty is high and change is inexpensive, short experiments and frequent learning are valuable. When change is expensive or consequences are severe, early analysis, formal verification, traceability, and staged approval become more important. Many products have both characteristics: a regulated physical product may require formal engineering controls while its user interface can be developed iteratively.

2. Stage-gate process

2.1 Concept and structure

Stage-gate is a governance model in which development is divided into stages separated by decision points called gates. Each stage has defined activities and expected deliverables. At a gate, decision-makers review evidence and choose whether to continue, redirect, defer, or stop the initiative.

A typical sequence is:

1. Discovery and opportunity identification
2. Concept definition
3. Feasibility and business-case development
4. Detailed development and testing
5. Validation, launch preparation, and approval
6. Post-launch review

The stages need not be strictly identical across organisations. A gate is not simply a calendar meeting; it is a decision mechanism. A credible gate asks whether the evidence justifies further investment and whether known risks are within tolerance.

2.2 Strengths

Stage-gate is useful when:

• development requires substantial capital;
• safety, quality, or regulatory evidence is mandatory;
• work depends on external suppliers or manufacturing capacity;
• changes become costly after design freeze;
• senior leaders must allocate scarce resources across a portfolio;
• documentation and accountability are important.

It provides visibility, comparability, and resource discipline. It can prevent an attractive idea from consuming resources merely because a team has already invested heavily in it.

2.3 Limitations

Traditional stage-gate can become bureaucratic. Teams may optimise documents rather than outcomes, delay customer contact until late in development, or interpret approval as a promise that the original plan will succeed. A gate can also create a false sense of certainty when evidence is weak.

A modern version should therefore use evidence-based gates. For example, the feasibility gate might require evidence about a critical technical risk, while the launch gate might require evidence about reliability, support readiness, regulatory status, and customer value. Not every activity must be completed before every decision; the required evidence should match the risk being managed.

3. Lean startup

Lean startup is an approach for developing products under high uncertainty. Its central logic is to turn assumptions into hypotheses, test them with appropriately small experiments, and learn whether to persevere, modify the concept, or pivot.

The commonly used cycle is build–measure–learn:

• Build: create the smallest credible experiment or minimum viable product (MVP).
• Measure: collect behavioural, qualitative, technical, or economic evidence.
• Learn: compare the evidence with the hypothesis and decide what to do next.

An MVP is not necessarily a crude or incomplete version of the final product. It is the smallest offering or experiment capable of testing a specific important assumption. A concierge service, clickable prototype, landing page, simulated workflow, or limited pilot may be more appropriate than production software.

3.1 Assumption-based planning

A product concept usually contains several assumptions:

• customers experience the problem;
• the proposed solution addresses it;
• users can and will adopt it;
• the organisation can deliver it reliably;
• revenue or another form of value will justify the cost;
• legal, ethical, security, and operational conditions can be satisfied.

The product manager should rank assumptions by importance and uncertainty. High-importance, high-uncertainty assumptions deserve early testing. Testing only easy assumptions creates activity without reducing meaningful risk.

3.2 Strengths and limitations

Lean startup reduces waste and can expose weak ideas before large investments are made. It is particularly useful for new markets, novel digital products, and business-model innovation.

However, it can be misapplied. A cheap experiment may not represent real usage, a growth metric may reward low-quality acquisition, and a pivot may be used to avoid making a difficult strategic choice. In safety-critical or regulated settings, an MVP cannot justify bypassing required controls. Experiments must be designed within ethical, legal, privacy, and safety boundaries.

4. Agile product development

Agile is best understood as a family of values and principles rather than one prescribed process. Agile emphasises:

• early and continuous delivery of valuable outcomes;
• responsiveness to change;
• close collaboration among business, technical, and other specialists;
• working product increments as evidence of progress;
• frequent reflection and improvement.

Agile does not mean “no planning,” “no documentation,” or “change everything at any time.” It means planning at an appropriate level of detail, documenting what is necessary, and treating learning as a normal part of development. A responsible agile team still needs architecture, quality assurance, risk management, accessibility, security, financial control, and regulatory evidence.

Agile is an umbrella concept. Scrum and Kanban are different ways of organising work that can support agile principles.

5. Scrum

Scrum is a lightweight framework for complex product development. It organises work through a prioritised product backlog, a product goal, timeboxed sprints, a usable increment, and regular inspection and adaptation.

Core accountabilities include:

• Product Owner: maximises product value by managing and ordering the product backlog.
• Scrum Master: helps the team understand and improve Scrum and removes impediments.
• Developers: create the usable increment and are collectively responsible for the work.

The framework includes sprint planning, daily Scrum, sprint review, and sprint retrospective. These events have different purposes: planning the sprint, coordinating current work, inspecting the product with stakeholders, and improving the way the team works.

A sprint should produce an increment that meets the team’s Definition of Done. The Definition of Done is a shared quality standard; it may include coding, testing, security checks, documentation, accessibility, and deployment readiness.

5.1 Appropriate use of Scrum

Scrum is useful when a stable, cross-functional team is solving a complex problem and can produce increments at a regular cadence. It supports transparency and frequent stakeholder feedback.

Scrum is less suitable when work arrives unpredictably, urgent operational tasks dominate, or the team cannot produce meaningful increments within the chosen sprint length. It can also fail when the product owner lacks decision authority or when several teams share an unmanaged dependency structure.

Scrum ceremonies should not become theatre. A daily meeting that merely reports status to a manager, or a sprint review that demonstrates unfinished work without stakeholder inspection, misses the framework’s purpose.

6. Kanban

Kanban is a method for managing and improving the flow of work. It visualises work, limits work in progress (WIP), makes policies explicit, manages flow, and uses feedback loops to improve the system.

A simple Kanban board might contain columns such as:

Options → Discovery → Ready → In progress → Review/test → Done

The exact columns should reflect the actual workflow. WIP limits constrain the number of items in a stage. If a team has too many items in progress, finishing work becomes slower, context switching increases, and problems remain hidden.

A useful flow relationship is Little’s Law:

Here, L is the average number of work items in the system, λ is the average throughput in items per unit of time, and W is the average time an item spends in the system. The relationship assumes a stable system over the period measured, with consistent definitions of work entering and leaving. For example, if a team completes an average of 4 items per week and has an average of 12 items in progress, the average cycle time is W = L ÷ λ = 12 ÷ 4 = 3 weeks.

Kanban does not require iterations, fixed roles, or a particular estimation technique. It is therefore effective for service teams, maintenance, platform work, support, operations, and environments with variable arrival patterns. It can also support product discovery and delivery.

Kanban does not automatically create prioritisation or strategy. A visually attractive board can still represent a poorly selected portfolio. Policies for priority, replenishment, quality, blocked work, and expedited items must be explicit.

7. Dual-track discovery and delivery

Dual-track development separates but connects two continuous activities:

• Discovery: investigate customer problems, test concepts, explore feasibility, and define what should be built.
• Delivery: engineer, test, release, operate, and improve the selected solution.

The tracks are not two independent departments. Discovery should inform delivery, and delivery evidence should influence discovery. A discovery activity may produce a tested prototype, a clarified requirement, a technical spike, or a decision not to proceed. Delivery should not begin merely because a feature has been written down; it should begin when the team has sufficient evidence and clarity for the risk involved.

Dual-track models are particularly valuable when product teams must continuously balance learning with execution. They reduce the risk of filling an engineering backlog with untested ideas. Nevertheless, discovery must not become a permanent queue in which researchers and designers produce artefacts that developers never use. Shared outcomes, regular collaboration, and joint accountability are essential.

8. Hybrid operating models

A hybrid model combines elements of different approaches to fit a product’s context. Examples include:

• stage-gate governance with agile development inside each stage;
• lean experiments during concept discovery followed by Scrum delivery;
• Kanban for operational work and Scrum for planned product increments;
• dual-track discovery and delivery under formal regulatory gates;
• agile software development integrated with a hardware verification plan.

Hybrid does not mean selecting fashionable practices without a coherent design. The organisation should specify:

1. what decisions are made and by whom;
2. what evidence is required at each decision point;
3. how work is prioritised and visualised;
4. how quality, safety, security, and compliance are assured;
5. how funding and capacity are allocated;
6. how customer and operational feedback changes priorities.

A hybrid model is strongest when each element has a clear purpose. For example, a formal gate may control regulatory release, while Scrum governs software construction and lean experiments test market assumptions before major investment.

9. Selecting an operating model

The selection should begin with context, not preference. The following criteria are useful.

A practical decision sequence is:

First, identify the dominant risks. If the greatest risk is whether anyone wants the product, begin with discovery and lean experiments. If it is structural safety, begin with engineering analysis and controlled verification. If it is flow and reliability of incoming work, use Kanban practices.

Second, assess reversibility. Reversible decisions can be tested and changed rapidly. Irreversible or expensive decisions require stronger evidence before commitment.

Third, separate governance from execution. A product may need formal investment or regulatory approvals without requiring every development task to follow a sequential process.

Fourth, choose the smallest sufficient process. Excess controls slow learning; insufficient controls create rework, unsafe releases, or unmanageable operational risk.

Finally, define measures that reveal outcomes rather than ceremony. Useful measures include customer adoption, task success, defect escape, cycle time, lead time, reliability, cost to serve, learning velocity, and achievement of product outcomes.

10. Application to different product contexts

10.1 Digital products

Digital products often have low marginal cost of release and high uncertainty about user behaviour. A suitable model may combine dual-track discovery, Scrum or Kanban delivery, automated testing, continuous integration, feature flags, and evidence-based product reviews. The ability to release frequently does not remove the need for accessibility, privacy, cybersecurity, data governance, and incident management.

10.2 Hardware products

Hardware involves tooling, materials, manufacturing tolerances, supplier lead times, physical testing, and often high change costs. A stage-gate structure can control investment and design maturity, while agile practices can be used for subassemblies, software, prototyping, and test planning. Concurrent engineering brings manufacturing, service, quality, and supply-chain specialists into earlier decisions.

10.3 Regulated products

Medical, financial, aviation, energy, and other regulated products require a clear distinction between experimentation and approval. Teams may use lean or agile methods to explore solutions, but experiments must be authorised, documented, and conducted within applicable law and organisational controls. Traceability should connect requirements to design decisions, tests, identified risks, and release evidence.

10.4 Services

Services are produced and experienced through interactions among customers, employees, systems, partners, and physical environments. Their development should consider the whole service journey, not only a software interface. Pilots, service blueprints, operational simulations, staff training, and feedback from frontline employees are often more informative than a feature demonstration. Kanban is useful for continuous service improvement, while stage reviews may be useful for major changes to capacity, policy, or risk exposure.

11. Detailed applied case: a digital lending service

The following is a fictional illustrative case.

Background

A regional bank proposes a mobile service that allows small businesses to apply for a short-term loan and receive a decision within one day. The opportunity is attractive, but the bank faces uncertainty about customer demand, fraud risk, credit-model performance, data privacy, operational capacity, and regulatory expectations.

Problem

A purely sequential project would spend months specifying the complete service before observing applicants. A purely experimental approach could create unacceptable risks if it handled personal data without sufficient controls or deployed an unvalidated credit decision model.

Analysis

The product has different risk types:

• Market risk: whether small businesses value rapid decisions.
• Usability risk: whether applicants understand the information required.
• Technical risk: whether systems can integrate with existing banking platforms.
• Model risk: whether automated decisions are accurate, fair, explainable, and monitored.
• Compliance risk: whether the process satisfies lending, privacy, and record-keeping obligations.
• Operational risk: whether staff can manage exceptions and complaints.

No single method handles all these risks equally well.

Approach and solution

The bank adopts a hybrid model. A steering group establishes formal investment and compliance gates. A cross-functional product team uses dual-track discovery and Kanban delivery.

During discovery, researchers interview business owners, test a prototype application form, and run a limited simulation using synthetic or appropriately controlled data. Compliance specialists review the proposed data use. The team measures completion rates, comprehension, time to submit, and the types of help applicants request.

During delivery, work is visualised on a Kanban board. WIP limits prevent the team from starting too many integrations simultaneously. Technical work includes audit logging, access controls, monitoring, and manual review pathways. A release gate requires evidence that security testing, model validation, customer communications, staff procedures, and complaint handling are ready.

The first live release is deliberately limited to a small customer segment and includes human review for borderline cases. Product and risk teams inspect outcomes weekly. If evidence shows that applicants misunderstand a question, discovery tests a revised interaction while delivery prepares a controlled change.

Outcome

The pilot reveals strong demand but also shows that many applicants abandon the process when asked for financial information they do not have immediately available. The team simplifies the sequence, explains why information is needed, and adds a save-and-return capability. The bank avoids a full-scale launch of a process that would have generated abandonment and support costs.

Learning points

1. Different risks require different forms of evidence.
2. Compliance is integrated into design rather than added at the end.
3. A pilot can reduce uncertainty without exposing the whole customer base.
4. Formal gates and iterative delivery are compatible when their purposes are clear.
5. Operational readiness is part of product development for a service.

12. Governance, metrics, and responsible practice

12.1 Governance

Governance should establish decision rights, escalation routes, risk ownership, and evidence standards. It should not require senior approval for every local design choice. Teams need autonomy within clear boundaries, while decisions with material financial, legal, safety, ethical, or reputational consequences require appropriate review.

12.2 Metrics

Metrics should be interpreted as signals, not targets detached from context. Useful categories include:

• Outcome: adoption, retention, customer success, revenue, cost reduction, or social impact.
• Flow: lead time, cycle time, throughput, WIP, blocked time, and predictability.
• Quality: escaped defects, reliability, rework, incident frequency, and support contacts.
• Learning: validated or invalidated assumptions, experiment completion, and decision speed.
• Risk: unresolved critical risks, control effectiveness, audit findings, and model performance.

Optimising one metric can damage the system. For example, maximising throughput may increase defects; reducing cycle time by removing validation may increase operational risk. A balanced set of measures is preferable.

12.3 Ethics and inclusion

Product processes influence who is heard, who benefits, and who bears risk. Teams should consider accessibility, discrimination, privacy, informed consent, explainability, worker impact, environmental consequences, and the possibility of misuse. AI-enabled features require particular attention to data provenance, bias, security, human oversight, monitoring, and appeal mechanisms. “Agile” delivery does not justify releasing a harmful system quickly.

13. Common failure modes and improvement practices

Process imitation: copying Scrum, Kanban, or stage-gate without understanding the problem. Improvement: design the operating model from risks, dependencies, and decision needs.

Output obsession: measuring features, documents, or velocity instead of customer and business outcomes. Improvement: connect work to explicit product outcomes and review evidence.

Late discovery: waiting until development is complete to test desirability or usability. Improvement: use prototypes, interviews, and experiments early and continuously.

Uncontrolled change: interpreting agility as permission to change priorities without capacity or decision discipline. Improvement: make prioritisation and trade-offs transparent.

Ceremony without collaboration: holding meetings while teams remain functionally divided. Improvement: create cross-functional teams with shared goals and decision authority.

Compliance by inspection: involving risk or legal specialists only at launch. Improvement: integrate controls, traceability, and review criteria from the beginning.

Excessive WIP: starting more work than the team can finish. Improvement: limit WIP, swarm on blocked work, and make queues visible.

False precision: treating estimates as commitments when uncertainty is high. Improvement: use ranges, assumptions, evidence, and regular reforecasting.

Chapter Summary

Product development operating models coordinate learning, design, delivery, risk management, and governance. Stage-gate provides structured investment and approval decisions and is valuable where change is expensive or evidence is formally required. Lean startup helps teams test important assumptions under uncertainty through focused experiments. Agile provides values and principles for responsive, collaborative development. Scrum offers a timeboxed framework for complex work by a stable cross-functional team, whereas Kanban manages flow through visualisation, WIP limits, explicit policies, and continuous improvement. Dual-track discovery and delivery connect problem exploration with engineering execution. Hybrid models combine these approaches when products contain different risk and delivery conditions.

The appropriate model depends on uncertainty, reversibility, regulation, physical dependencies, service complexity, work-arrival patterns, and organisational capability. Effective organisations distinguish governance from day-to-day execution, use evidence-based decisions, integrate quality and compliance, and measure outcomes as well as flow. The central professional skill is not choosing a fashionable method; it is designing a coherent system that learns quickly where learning is safe, controls risk where control is necessary, and delivers valuable outcomes reliably.

Key Terms

Operating model: The roles, processes, decision rights, governance, funding, and measures used to develop and operate a product.

Stage-gate: A development model that divides work into stages separated by evidence-based approval decisions.

Gate: A decision point at which an initiative may continue, change, pause, or stop.

Lean startup: An approach that tests important business and product assumptions through rapid learning cycles.

Build–measure–learn: A cycle of creating an experiment, collecting evidence, and adapting the product or strategy.

Minimum viable product: The smallest offering or experiment capable of testing a significant assumption.

Agile: A family of values and principles emphasising collaboration, incremental value, feedback, and responsiveness to change.

Scrum: A framework for developing complex products through a prioritised backlog, sprints, inspection, and adaptation.

Product Owner: The Scrum accountability responsible for maximising product value and ordering the backlog.

Sprint: A fixed-length period during which a Scrum team creates a usable increment.

Definition of Done: A shared quality standard that an increment must satisfy.

Kanban: A method for managing and improving the flow of work.

Work in progress: Work that has started but has not yet been completed.

Cycle time: The time from the start of work on an item until its completion.

Dual-track development: A model that continuously connects product discovery with product delivery.

Discovery: Activities that investigate problems, users, solutions, and assumptions.

Delivery: Activities that engineer, release, operate, and improve a product or service.

Hybrid model: An operating model that deliberately combines practices from multiple approaches.

Traceability: The ability to connect requirements, decisions, risks, tests, and release evidence.

Product outcome: A measurable change in customer, organisational, or societal conditions resulting from product activity.

Review Questions

Short Answer Questions

1. What is the purpose of a gate in a stage-gate process?
2. How does an MVP differ from a simply incomplete product?
3. State two differences between Scrum and Kanban.
4. What are the two connected activities in dual-track development?
5. Why should regulatory and ethical controls be integrated early in development?

Long Answer Questions

1. Compare the strengths and limitations of stage-gate and lean startup for a new product in an uncertain market.
2. Explain how Scrum supports inspection and adaptation, and identify conditions under which it may be unsuitable.
3. Describe how a hybrid model can combine formal governance with iterative delivery.
4. Discuss how hardware development differs from digital product development in terms of reversibility, dependencies, and evidence.
5. Explain why product teams should balance outcome, flow, quality, learning, and risk metrics.

Analytical / Application Questions

1. A team receives unpredictable customer-support, maintenance, and small enhancement requests. Which operating model or combination would you recommend, and why?
2. Design an operating model for a regulated medical device that includes discovery, engineering, verification, governance, and post-launch learning.
3. A digital product team has 20 items in progress and completes 5 items per week. Using Little’s Law, estimate the average time an item spends in the system, state the assumption required, and recommend two improvement actions.

Multiple Choice Questions with Answers

Question 1

Which characteristic most strongly supports the use of stage-gate governance?

A. High uncertainty with inexpensive changes

B. High regulatory burden and expensive late changes

C. Unpredictable daily support requests

D. A need to avoid all documentation

Correct Answer: B. High regulatory burden and expensive late changes

Question 2

What is the primary purpose of a minimum viable product?

A. To deliver every planned feature at low quality

B. To test an important assumption with the smallest credible offering

C. To replace regulatory approval

D. To guarantee product-market fit

Correct Answer: B. To test an important assumption with the smallest credible offering

Question 3

Which statement best describes agile?

A. A fixed sequence of mandatory phases

B. A project estimation technique only

C. A family of values and principles for adaptive product development

D. A synonym for Kanban boards

Correct Answer: C. A family of values and principles for adaptive product development

Question 4

Which Scrum accountability is responsible for maximising product value and ordering the backlog?

A. Scrum Master

B. Product Owner

C. Developers

D. Release auditor

Correct Answer: B. Product Owner

Question 5

Which practice is central to Kanban?

A. Mandatory fixed-length sprints

B. Limiting work in progress to improve flow

C. Deferring all customer feedback until launch

D. Requiring a separate department for every workflow stage

Correct Answer: B. Limiting work in progress to improve flow

Question 6

In dual-track development, discovery primarily investigates:

A. Only payroll and budgeting

B. Problems, users, solutions, and assumptions

C. Only completed production code

D. Only post-launch complaints

Correct Answer: B. Problems, users, solutions, and assumptions

Question 7

A team completes 4 work items per week and averages 12 items in progress. Under stable-flow assumptions, what is the average cycle time?

A. 0.33 weeks

B. 3 weeks

C. 8 weeks

D. 48 weeks

Correct Answer: B. 3 weeks

Question 8

Which factor is most important when selecting an operating model?

A. Whether the method is currently fashionable

B. The product’s risks, uncertainty, dependencies, and cost of change

C. Whether every team uses identical ceremonies

D. The number of meetings created

Correct Answer: B. The product’s risks, uncertainty, dependencies, and cost of change

Question 9

Why might a hardware product use a hybrid model?

A. Hardware never requires planning

B. Physical dependencies and high change costs may require gates while software work remains iterative

C. Agile methods cannot be used for any hardware-related work

D. Stage-gate eliminates the need for testing

Correct Answer: B. Physical dependencies and high change costs may require gates while software work remains iterative

Question 10

Which is an example of a balanced product-development measurement practice?

A. Maximising velocity regardless of defects

B. Measuring only the number of features completed

C. Combining outcome, flow, quality, learning, and risk indicators

D. Avoiding measures because innovation cannot be assessed

Correct Answer: C. Combining outcome, flow, quality, learning, and risk indicators