How We Build
This playbook turns the Mantra into an end-to-end product development process. It is a working agreement: teams should improve it as they learn while preserving clear ownership and quality gates.
Begin with a system target
State the user outcome, primary measure, expected scale, economic or operational constraint, and required quality together. A feature target alone allows cost, support, implementation, and reliability to become someone else's later problem.
Map the end-to-end flow and identify its current constraint. Include the product, Builder configuration, implementation, data migration, security, support, and customer operation where relevant.
1. Discover
Product and Research clarify the user, work, pain, and desired outcome with input from Sales, Design, and Engineering. Research customers, the domain, market patterns, and credible alternatives before converging on a solution.
Name the observable rate or condition the work should improve and the evidence that would show the team is solving the wrong problem.
2. Explore
Generate and compare concepts. Question assumptions, invite cross-functional perspectives, and use low-fidelity journeys or diagrams to make the experience and its consequences understandable.
Create a requirement record for consequential constraints. Question their source and protected outcome, then delete unnecessary steps, fields, variants, interfaces, approvals, and configuration before optimizing what remains.
3. Test feasibility
Engineering leads an early RFC with Product, Design, and relevant commercial or domain contributors. Identify system constraints, reuse opportunities, dependencies, risk, and a technically scalable path before investing in full detail.
Use the RFC to assign one directly responsible owner, required reviewers, decision rights, verification method, and escalation conditions. Ask what breaks at ten times the expected users, data, configuration variants, transactions, or support volume—but do not add speculative flexibility without a credible demand or constraint.
4. Design and refine
Design develops the interaction and visual system in the approved design workspace. Product documents the user stories and acceptance criteria. The team reviews edge cases, Builder configuration, data behavior, and operational impact until the work meets the Definition of Ready.
Bring implementation, support, security, and other delivery experts into the design before interfaces harden. Design for the complete customer lifecycle, not only the initial product interaction.
5. Implement and integrate
For ticket-level work, follow Execute the plan: split the ready plan into phases, then code and publish from the current phase.
Engineering builds the smallest reusable solution that meets the intended outcome. Product and Design remain available to answer questions and refine details as evidence emerges. Important implementation decisions and new operational knowledge are documented as part of the work.
Instrument success, failure, and important transitions from the beginning. Build staged rollout, rollback, recovery, and traceability in proportion to the delivery risk tier.
Use an experiment brief whenever the team must retire a material uncertainty:
Uncertainty:
Expected outcome:
Smallest valid test:
Success and failure signals:
Risk tier and blast radius:
Rollback or recovery path:
Owner:
Independent reviewer, if required:
Where the learning will be recorded:
6. Verify
Engineering performs appropriate automated and manual testing, including edge cases, performance, security, and visual quality. Product and Design perform user acceptance testing across the complete experience and its Builder options. On a technical ticket, that is published-branch testing followed by human acceptance.
Move fastest in contained, reversible tests. Increase the evidence threshold as reversibility falls or potential harm grows. Verify the end-to-end outcome, not only the local component, and confirm that observability can distinguish likely failure causes.
7. Release and learn
Product owns the go-live decision with the required technical and business input. Release through the approved process, observe the result, respond to issues, and capture learning. Ticket-level release checkpoints are in Release the work. Work is complete when it meets the Definition of Done, not merely when implementation stops.
Write the learning back into requirements, tests, documentation, monitoring, design rules, or reusable platform capability. A solved incident or completed retrospective that changes no part of the system is likely to recur.
The five checks
At every stage, ask:
- Are we giving the right problem our full attention?
- Are we removing effort and uncertainty?
- Do the people affected feel understood and retain choice?
- Is the system learning and carrying more of the burden?
- Is the result meaningfully better, dependable, and safe to use?
Guidance type: Working agreement
Owner: Product, Design, and Engineering leadership