Deliver customer outcomes fast, safely, and repeatably by combining prototype‑first discovery with lightweight Agile delivery.
The new bottleneck isn't typing – it's achieving shared understanding
Generative AI has collapsed the marginal cost of producing working code; what used to take days of careful hand‑crafting can now be scaffolded in minutes. The new bottleneck isn’t typing – it’s achieving shared understanding early enough. Traditional heavy upfront specs attempted to minimise rework by predicting correctness in advance, but they now delay learning and amplify risk: we still discover the real requirements only once users touch something real. Prototype‑Driven Development embraces this shift: invest early cycles in thin, disposable prototypes to create alignment, validate value, and surface complexity before hardening. We trade speculative specification time for rapid feedback loops, reducing total rework while accelerating trustworthy delivery.
- Prototype: Disposable slice built to validate a learning objective; correctness is secondary to speed of insight. Prototype code is explicitly disposable; when productionised, it will be rebuilt under Build standards.
- Build: First production‑grade implementation of validated scope; designed to be supportable and testable.
- Beta: Limited release to a target user cohort with observability, support, and rollback in place.
- GOOD: Problem–solution fit confirmed (target users complete core flow end‑to‑end), top risks addressed, and major unknowns reduced to bounded tasks.
- GREAT: Outcome metrics achieved (or exceeded), quality bars (reliability, performance, security, maintainability) met, and team confident to scale/general availability.
The core steps of this good‑to‑great process are:
- Identify: Frame the problem, users, desired outcomes, constraints, anti‑goals, initial risks, and provisional kill criteria.
- Prototype Loop (repeat until GOOD or killed):
- Prototype: Small slices to test learning objectives.
- Collect Feedback: Real users / internal proxies; capture qualitative + simple quantitative signals.
- Decide: Continue, Pivot, or Kill (timeboxed).
- Specify (Build Brief): Codify only what must now be right—interfaces, non‑functionals, acceptance examples, success metrics.
- Build: Implement the production‑ready slice; keep scope minimal; retain ability to delete or refactor rapidly.
- Beta: Limited release with observability and rollback.
- Feedback Loop (Beta): Measure defined metrics and qualitative insights against GOOD→GREAT progression.
- Iterate 3–6 Until GREAT: Then graduate to general availability / scale phase.
- Product develops a one-ish-page proposal defining the problem that needs to be solved, outcomes, constraints, anti-goals, risks and acceptance criteria.
- Refinement: Product and engineering refine the proposal to align the expectations of what should be built
- Rough Estimate using shirt sizes:
- S: Several small items can be done within a sprint
- M: One medium item can be done within a sprint
- L: One large item takes two-ish sprints
- XL: The item is too big and needs to be broken down into smaller chunks
- Engineering decomposes the proposal into backlog artefacts.
- Product orders the backlog, taking into account dependencies
- Engineering takes items from the top of the backlog into the current sprint
- At the end of the sprint, Engineering demos completed prototypes or builds to Product
- Product collects feedback from selected users which feeds changes to the prototype or the build
Quarterly (or longer) targets can be informed by observed engineering throughput (cycle time, completed slices, variability) rather than assumed upfront. We forecast from evidence; we don’t force scope to fit a date.
How do we handle bugs and maintenance while balancing customer requests?
- Bugs: Treat defects as standard problem proposals using the bug template.
- Minor Health Work: Routine tasks (small refactors, dependency updates, test coverage for changed areas, CI/CD hygiene) are pulled continuously. Engineering signals when these are due; Product responisbly sequences them with feature work. Rigid sprint percentages are avoided (e.g. 70/20/10); instead, use risk indicators (rising lead time, review latency, flaky test count) to trigger increased attention.
- Major Health Work (Legacy Replacement / Large Refactor): Treated as a proposal, only coming from Engineering.
- Authority & Collaboration: Product and Engineering jointly prioritise, but Engineering retains authority to execute mandatory system health work when objective risk thresholds are exceeded.