Process vs. Model

Marty Cagan argues that the simple conceptual model of continuous discovery and delivery running in parallel is useful precisely because it is process-agnostic, and warns against elaborating it into a rigid process flowchart. He notes the model goes by many names and that people keep trying to add detail to it. The key points are that discovery and delivery are ongoing rather than phased, that discovery tackles value, usability, feasibility and viability risks, and that one product team owns both tracks and is measured by business results rather than shipped features. He concludes that the real challenge is culture and skills, not a prescribed process, echoing Jeff Bezos's warning that process can become the goal itself.

01Key takeaways

• Treat the dual-track model as a principle, not a step-by-step process you must follow exactly.
• Run discovery and delivery continuously in parallel rather than as sequential phases.
• Use discovery to tackle value, usability, feasibility and viability risks before committing to build.
• Have product management, design and engineering solve problems together rather than handing off work.
• Measure the team on business results and customer outcomes, not on how many features shipped.
• Invest in culture and technique training, and watch for process becoming an end in itself.

02Key sections

Models are useful but can be misread

Cagan frames conceptual models as imperfect but powerful explanatory tools, and warns that people often read them too literally as prescriptive processes.

Many names for the same model

The parallel discovery-and-delivery model has been called dual track agile, build the right product versus build the product right, and similar labels, which he sees as evidence of its underlying truth.

Why not add more detail

Suggested additions such as vision work, delivery specification, Scrum versus Kanban, and feedback loops would turn a simple model into a detailed process, a slippery slope he resists.

The higher-order principles

Discovery and delivery run in parallel, discovery attacks big risks collaboratively, and one product team owns both tracks and is measured on business outcomes.

Culture over process

There is no single discovery or delivery process; what matters is building the right culture and training teams in key techniques, guarded against process becoming the goal.

03From the post

“A partnership dedicated to teaching best practices to product teams and product leaders”

04Frameworks mentioned

Summary and takeaways written by PM Atlas; quotes are short excerpts. © the original author.