How do we make it repeatable?
The Build stage is about creating repeatability through codification and standardization. Turn expertise into artifacts. Decide what gets standardized (70%) and what stays configurable (30%). The art of productization is finding the line between over-standardizing (agencies cannot use it) and over-customizing (you are running a development shop with product theater).
Stage Objectives
- Identify and prioritize tacit expertise that must be codified
- Create decision trees, templates, and training materials
- Apply the 70/30 principle to every product feature
- Define what is standardized core vs. configurable surface
- Establish configuration vs. customization boundaries
Key Activities
Expertise Codification
Identify the tacit knowledge and delivery expertise that must be codified to make your product repeatable. Use interviews and observation to capture expert judgment.
Standardization Decisions
Apply the 70/30 principle: 70% standardized core (security, compliance, core functionality, infrastructure) and 30% configurable surface (workflows, reporting, integrations, UI).
Configuration Design
Design configuration capabilities that let customers adjust without code changes: workflow parameters, reporting options, UI preferences, business rules.
Custom Scope Boundaries
Define what falls outside the product and requires professional services. Custom work gets separate scope, timeline, and CLIN structure.
Run Build as an engagement
The framework is published in full, so you can run Build yourself. If you would rather have it done with you, the Build Pilot is the engagement that covers it. A working MVP, a product requirements document you own, a founding-member offer you can use to close the first paying customers, and outreach support toward three signed letters of intent by day 90. The three letters are the target the engagement is aimed at, not a guarantee.