When the stage becomes relevant
Develop can become relevant when:
- product direction and experience evidence support creating a coherent working increment;
- an existing product requires a new capability, change, integration, repair, or modernization;
- technical exploration must become usable product behavior;
- backlog items require refinement, ordering, implementation, and acceptance;
- a product must connect to data, platforms, vendors, operational workflows, or other products;
- quality, accessibility, security, privacy, performance, reliability, or maintainability requirements must become implemented behavior;
- development evidence reveals tradeoffs that require product decisions;
- validation findings require changes to working capability;
- operational or adoption evidence triggers a product improvement;
- evolution or retirement requires technical change, migration, data handling, integration removal, or decommissioning work.
Develop can begin with a narrow increment and continue throughout the life of a product. The presence of active development does not mean that discovery, definition, design, validation, or operational responsibility has stopped.
Questions and decisionsRead section
Product intent and increments
- Which user need, product outcome, requirement, or learning objective should the next increment address?
- What makes the increment coherent and usable rather than merely technically complete?
- Which assumptions will the working capability help resolve?
- What is intentionally excluded from the increment?
- How will the organization recognize whether the increment supports the intended direction?
Backlog and priorities
- Does the backlog reflect current product priorities rather than accumulated requests?
- Which items express outcomes, needs, behavior, constraints, or acceptance conditions clearly enough for responsible implementation?
- Which dependencies, risks, evidence needs, and sequencing constraints affect ordering?
- Which decisions belong to product management, product ownership, engineering, design, quality, or another specialist?
- How should new evidence change priorities, scope, or release assumptions?
Experience and behavior
- Does the working capability preserve the supported journeys, content, states, exceptions, accessibility conditions, and support paths?
- How should the product behave when data is incomplete, a dependency fails, access is denied, or a user makes an error?
- Which design decisions require refinement as implementation becomes real?
- Are responsive behavior, keyboard use, assistive technology, performance, and content quality addressed within development?
- Does the implementation remain coherent across channels and surrounding workflows?
Technical and data responsibility
- Which architecture, platform, integration, data, security, privacy, and reliability decisions influence product outcomes or risk?
- What technical debt is being created, accepted, reduced, or deferred, and who understands the product consequence?
- Are data meaning, quality, lineage, freshness, ownership, retention, and permitted use sufficient for the intended behavior?
- How will the product be observed, supported, changed, and eventually retired?
- Which technical decisions require specialist ownership rather than a product preference?
Quality and evidence
- Which acceptance conditions and quality attributes apply to the increment?
- What evidence is being produced through review, testing, research, demonstrations, instrumentation, and operational preparation?
- Are material findings resolved, accepted with conditions, or returned for change?
- Which product assumptions can be evaluated now and which require later validation or real use?
- Does the evidence support continuing, changing, limiting, pausing, or stopping the work?
Readiness beyond development
- Are analytics, monitoring, audit, feedback, and outcome-measurement needs being implemented?
- Are operations, support, communications, learning, adoption, governance, and contingency responsibilities progressing with the product?
- Which environments, data, vendors, approvals, or organizational dependencies could prevent validation or launch?
- What must be true before the product can be validated as a coherent whole?
Activities and evidenceRead section
Development practices can vary by organization, product, technology, and delivery method. Useful work may include:
- translating product direction, experience decisions, requirements, and acceptance conditions into an ordered and understandable backlog;
- refining work with product, engineering, design, data, quality, operations, security, privacy, accessibility, and other relevant contributors;
- designing architecture and technical approaches through accountable engineering leadership;
- creating code, configuration, content, data models, integrations, infrastructure, and operational capabilities;
- producing small working increments that can be reviewed, tested, integrated, and adapted;
- implementing complete states, exceptions, permissions, errors, recovery paths, and accessibility behavior rather than only the ideal path;
- reviewing working increments with users, stakeholders, specialists, and product decision-makers;
- performing automated and manual testing appropriate to function, integration, accessibility, security, privacy, performance, resilience, data, and quality risk;
- maintaining traceability among needs, requirements, backlog decisions, implementation, findings, and accepted exceptions;
- implementing analytics, logs, monitoring, feedback, audit, and measurement capabilities;
- identifying technical debt, dependency risk, maintainability concerns, and future operating consequences;
- preparing environments, test data, deployment paths, support knowledge, operational procedures, and recovery approaches;
- recording material product and technical decisions, changes, assumptions, and unresolved questions;
- reprioritizing or returning to Define or Design when implementation evidence changes the responsible direction;
- demonstrating integrated working capability early enough for feedback to change the product.
The stage should not prescribe one delivery method. Iterative development can make evidence available sooner, reduce the cost of changing direction, and reveal integration risk, but the appropriate increment size and cadence depend on the product and context.
Typical outputsRead section
Useful Develop-stage outputs may include:
- integrated working product increments;
- an ordered and refined product backlog connected to outcomes and evidence;
- implemented experience, content, data, integration, accessibility, security, privacy, and operational behavior;
- architecture, data, interface, configuration, and operational decision records;
- automated and manual test evidence produced during development;
- updated requirements, acceptance conditions, priorities, estimates, and dependency records;
- resolved, accepted, deferred, and open findings with accountable owners;
- analytics, monitoring, logging, feedback, audit, and measurement instrumentation;
- technical-debt, maintainability, reliability, cost, and risk evidence;
- deployment, recovery, support, and operational preparation;
- demonstrations and stakeholder or user feedback on working capability;
- an integrated view of what is ready for validation, what remains incomplete, and what changed from the defined direction.
Code, configuration, or completed backlog items are not sufficient outputs by themselves. The organization also needs to understand what capability exists, what evidence supports it, which conditions remain unresolved, and how implementation decisions affect the product.
Contributing responsibilitiesRead section
Engineering and architecture
Engineering and architecture specialists own technical design and implementation decisions within their professional responsibilities. They create working capability, manage technical quality and sustainability, explain tradeoffs, and connect architecture, integration, reliability, performance, security, and maintainability evidence to product decisions.
Product ownership
Product ownership connects product direction to delivery-facing decisions. This can include backlog clarity and ordering, refinement, acceptance conditions, day-to-day tradeoffs, dependency visibility, and decisions about whether completed work supports the intended increment.
Product management
Product management maintains connection to the business problem, intended users, outcomes, product boundary, roadmap, investment, and broader product direction. It interprets delivery evidence and makes or facilitates product tradeoffs without directing specialist implementation.
Experience, research, content, and accessibility
Design and content specialists preserve experience coherence as working behavior develops. Research specialists help evaluate increments with representative users. Accessibility specialists and the wider team ensure that inclusive-use requirements become implemented and testable behavior.
Quality, security, privacy, legal, and compliance
Quality specialists guide verification, traceability, finding severity, and evidence quality. Security, privacy, legal, compliance, data-governance, and other specialists define and evaluate controls, obligations, permitted behavior, and risk. Early participation helps prevent these responsibilities from becoming final-stage approval barriers.
Data, analytics, operations, support, and adoption
Data specialists implement and govern data behavior and instrumentation. Analytics specialists help ensure that product use and outcomes can be measured. Operations and support contributors prepare monitoring, recovery, continuity, knowledge, and service ownership. Adoption and communications contributors prepare the surrounding changes that will help people use the product effectively.
The accountable product decision-maker connects these contributions. Each specialist remains accountable for judgments within that discipline.
Cross-lifecycle considerationsRead section
- Opportunity, Discover, and Define provide the business problem, evidence, intended outcomes, product direction, boundary, and requirements that development should preserve.
- Design provides the experience direction, content, states, accessibility conditions, and user evidence that working capability should implement.
- Validate uses development evidence and additional integrated evaluation to support a product decision.
- Launch readiness depends on deployment, monitoring, support, communications, governance, contingency, and organizational preparation that should begin during development.
- Adopt requires onboarding, guidance, measurement, feedback, and product behavior that development may need to enable.
- Operate depends on maintainable architecture, observability, reliability, support, data quality, controls, and accountable ownership.
- Evolve returns new priorities and evidence to the backlog without allowing the backlog to replace product direction.
- Retire may require migration, archival, access changes, integration removal, data treatment, communications support, and decommissioning capability.
Technical and product decisions made during Develop can create long-lived consequences. Cost or speed tradeoffs should make their effects on users, operations, risk, adaptability, and retirement visible.
Common mistakesRead section
Treating the backlog as the product strategy
The backlog organizes delivery-facing work. It cannot explain the complete business problem, product direction, intended outcomes, investment logic, adoption needs, or future responsibility.
Measuring progress only through completed work
Velocity, story counts, milestones, and code volume describe activity or output. Working capability, evidence, quality, and progress toward product outcomes provide more useful decision context.
Separating product, design, and engineering decisions
Sequential handoffs can hide conflicting assumptions until change becomes expensive. Maintain clear responsibilities while allowing evidence and decisions to move across disciplines.
Assigning technical implementation to product leadership
Product leaders explain needs, outcomes, priorities, constraints, and product tradeoffs. Engineering specialists remain responsible for technical architecture and implementation decisions.
Building only the ideal path
Exceptions, errors, missing data, permissions, failures, accessibility behavior, and recovery paths are part of the product. Deferring them can create misleading demonstrations and incomplete quality.
Postponing security, privacy, accessibility, and operations
Late attention can expose fundamental design or architecture problems after significant investment. These responsibilities should influence increments and acceptance conditions from the beginning.
Treating technical completion as product acceptance
An implemented feature may still fail the intended need, experience, integration, quality, data, risk, or operational conditions. Validate the combined product evidence before making the next decision.
Omitting measurement and observability
A product that cannot reveal its use, health, outcomes, failures, and risk leaves later decisions dependent on opinion or incomplete evidence.
Hiding scope changes inside delivery
Small implementation choices can materially change the product. Record and evaluate changes to boundaries, requirements, experience, outcomes, or risk rather than allowing them to become accidental direction.
Decision signals
Advance integrated capability to Validate
Advancing capability into a broader validation decision may be appropriate when:
- a coherent working increment implements the intended product behavior and supported experience direction;
- relevant requirements and acceptance conditions are traceable to implementation and evidence;
- functional, integration, data, accessibility, security, privacy, performance, resilience, and operational work has progressed sufficiently for the validation purpose;
- material findings, exceptions, technical debt, dependencies, and incomplete conditions are visible;
- analytics, monitoring, feedback, and evidence collection support later decisions;
- product, engineering, design, quality, data, operations, and other accountable contributors understand what is being evaluated;
- unresolved questions are explicit and the organization knows what evidence Validate must interpret.
Development and validation can overlap. Advancing an increment does not imply that all development has ended or that launch is approved.
Continue or change the increment
Additional development may be appropriate when supported product behavior remains incomplete or material evidence can be produced through a focused change. Reorder or narrow work when dependencies, risk, or learning value justify it.
Revisit Design, Define, or Discover
Return to Design when working capability exposes an experience issue. Return to Define when feasibility, cost, data, scope, priority, or ownership evidence changes the product direction. Return to Discover when the business problem or user need requires renewed investigation.
Limit, pause, or route
Limit the audience, capability, exposure, or release assumption when evidence supports a safer coherent increment. Pause when an unresolved dependency, material risk, ownership gap, or unavailable evidence prevents responsible progress. Route work to another product when the capability belongs within an existing product boundary.
Stop
Stopping may be appropriate when development evidence shows that the product cannot responsibly support the intended need, foreseeable cost or risk no longer justifies continued investment, or a different response has become more appropriate.
Applied-example continuation
Starting point
Design established a plain-language status experience within the authenticated account, optional notifications, visible update timing, meaningful exception states, preference management, accessible interaction, and a direct support path. Data freshness and operational ownership remain material dependencies.
Working capability
Development creates increments that connect customer identity, selected service-request records, the status model, the account experience, notification services, consent and preferences, analytics, support guidance, and operational workflows.
Early integration evidence shows that one request system updates status throughout the day while another publishes only an overnight file. Presenting both as current would undermine the product promise. Product, engineering, data, design, and operations contributors decide to sequence the first release around request types with sufficiently reliable status data. The experience explicitly communicates the last update and handles unavailable or delayed data without suggesting that a request has stopped.
The backlog changes to prioritize status-source ownership, data-quality monitoring, notification failure handling, accessible error states, support escalation, and measurement instrumentation. A separate mobile application remains outside the product boundary because the working account experience can test the underlying outcome with less duplication.
Decision
Integrated working capability supports advancement to Validate for the selected request types. The evidence package includes functional and integration results, accessibility findings, security and privacy reviews, notification and consent behavior, data-freshness monitoring, unresolved exceptions, operational procedures, and traceability to the experience acceptance conditions.
The decision does not approve launch. Validate will determine what the combined evidence says about whether the product works as intended and whether it should advance, change, be limited, be retested, pause, or stop.
Source notesRead section
- The Scrum Guide, November 2020. Supports an ordered and emergent Product Backlog, usable increments, a Definition of Done, product inspection, adaptation, and accountable product decisions. This profile does not require Scrum or transfer technical accountability to product ownership.
- U.S. Digital Services Playbook. Supports iterative delivery, automated testing, deployment preparation, security and privacy, data-driven decisions, and assigning accountable ownership.
- NIST Secure Software Development Framework, SP 800-218. Supports integrating secure software practices throughout development rather than treating security as a final review.
- Web Content Accessibility Guidelines 2.2. Provides testable accessibility criteria relevant to implemented web content and interaction.