Cycle 1: Initial Development

Cycle 1 takes a product from requirements intake through business acceptance while establishing the technical and product knowledge that later changes can reuse. UX direction, technical foundation preparation, and specification generation proceed in parallel before and during early implementation as needed. The Product Engineer coordinates iteration, and two architect reviews of the implementation help maintain technical quality before and after substantive stakeholder feedback.

Lead: Product Engineer. Participants: Business stakeholders, domain experts; architect or UX designer when needed.

Begin with the actual problem. Identify stakeholders, intended users, workflows, current pain points, desired outcomes, organizational constraints, and what is outside the initial scope. Avoid confusing a suggested feature with the business goal behind it. Capture objectives and unresolved questions, and identify decisions that require a business owner.

Outcome: A shared understanding of the problem and an initial description of product objectives, boundaries, and major workflows. Discovery may continue as new questions arise.

Leads: Product Engineer, architect, and UX designer, with responsibility assigned by subject.

UX direction. Establish the main journeys, interaction principles, accessibility constraints, and suitable existing design patterns without exhaustive screen designs.

Technical foundation. Identify approved stacks and reusable assets, initial architectural boundaries, coherent discoverable instructions, and technically enforced execution permissions. Preparation reflects complexity, novelty, and risk. No separate mandatory Architecture Readiness Review or ready-to-code sign-off is added.

Specification generation and intent capture. The Product Engineer works with stakeholders and conversational AI to clarify desired outcomes and begin persistent product context. Agents may draft and maintain that material during implementation; a separate stakeholder sign-off on specification prose is not a mandatory prerequisite. Consequential unresolved decisions are escalated to their owners.

The three activities proceed in parallel and inform each other. A prototype may expose a missing workflow rule; a technical constraint may reshape UX. Outcome: sufficient shared direction and approved capabilities for meaningful authorized implementation, with open decisions visible.

Lead: Product Engineer. Implementer: coding agent.

The coding agent implements functional increments within approved instructions and capabilities. The Product Engineer runs the application, inspects workflows, explains shortcomings and corrections, and repeats the cycle. The agent maintains intended product behavior as the human agrees changes to outcomes. Implementation, specification upkeep, and feedback may overlap. No universal specification-document approval gate is introduced.

Outcome: demonstrable working behavior and accurate maintained intent, with limitations disclosed for the initial architect review.

Incremental implementation is the default: agree a bounded capability, inspect the working result, and adjust before expanding. Define creative/UX, structural, functional, and content latitude explicitly, including what stays outside scope. Broad experiments and reversible prototypes can justify wider latitude when deliberately agreed. Read Defining Agentic Latitude.

Lead: Architect / Senior Engineer. Collaborator: Product Engineer.

Review the implementation's structure, use of approved components and services, security posture, separation of concerns, maintainability, integration choices, and other risks relevant to the product. Identify material issues early enough that feedback iterations do not build upon unsound foundations. The Product Engineer directs correction, and the architect confirms resolution of critical findings.

Outcome: A technically credible foundation ready for substantive stakeholder feedback.

Lead: Product Engineer. Participants: business stakeholders, UX specialist where useful, coding agent.

Stakeholders inspect functioning workflows and explain missing or incorrect outcomes. Distinguish defects, usability concerns, and new intent; resolve consequential business rules with accountable owners. The agent updates implementation and persistent intent to support the agreed behavior. Repeat product inspection until outcomes are satisfactory. Stakeholders do not have to reapprove a specification document for every iteration.

Outcome: a working product and maintained context reflecting the agreed outcomes, ready for independent verification.

A separate verification agent or context uses maintained intended behavior to generate and execute checks against running software, APIs, or interfaces where practical. Playwright is one possible browser tool, not a mandatory SHAPE dependency. The verifier records passes, failures, blockers, and ambiguities. Expected results must not be inferred solely from implemented code. Passing tests generated from inaccurate intent cannot prove fitness for stakeholder needs; product inspection and UAT remain essential.

Lead: Architect / Senior Engineer.

Review the final technical state in light of earlier findings, stakeholder changes, verification results, and any architectural or security consequences of the iteration. Confirm that significant findings are resolved or explicitly handled under applicable policy. Technical sign-off addresses engineering readiness; it is not the stakeholder's business acceptance decision.

Outcome: Technical review completed for UAT entry under enterprise policy.

Owner: Enterprise UAT/business acceptance process. Coordinator: Product Engineer.

Hand the product, requirements context, known limitations, and relevant verification evidence into the organization's existing UAT process. Authorized business stakeholders confirm whether the product meets intended needs and decide acceptance in accordance with established practice. If UAT produces changes, reconcile them with the specifications, implement corrections, and repeat the necessary checks.

Outcome: A documented business acceptance decision, or a clear list of issues to resolve. The SHAPE-defined development cycle ends here.

Stages describe responsibility and important checks, not eight isolated departments or an instruction to freeze understanding prematurely. Teams can revisit earlier material. What matters is that accepted behavioral changes update specifications, agent work stays within approved boundaries, and independent technical and business reviews remain meaningful.