Product
Feature lifecycle
Propose → spec → build → ship → measure — how features move through E-FACTS
Feature lifecycle
Every meaningful change should be able to point to where it is in this lifecycle.
Stages
flowchart LR
A[Propose] --> B[Spec]
B --> C[Build]
C --> D[Ship]
D --> E[Measure]
E -->|iterate or kill| A1. Propose
- Name the persona + job (Users).
- State the surface owner (Surfaces).
- Sketch success metric or kill criterion (Metrics).
- Check priority band (P0–P4) in Principles.
2. Spec
Minimum viable spec:
| Section | Required |
|---|---|
| Problem / job | Yes |
| User flow (happy + failure) | Yes |
| Data / API needs | Yes for anything past pure copy |
| Privacy / auth notes | Yes if identity or receipts involved |
| Design language references | Yes for UI |
| Out of scope | Yes |
Link Engineering tickets only after the job and surface are clear.
3. Build
- Follow Engineering conventions for the owning repo.
- Design tokens from Design language /
docs/Design.md. - Prefer vertical slices (API + client) over long-lived UI-only stubs that lie about data.
4. Ship
- Preview / TestFlight / staging before production.
- Feature flags when blast radius is high (auth, bind, payments-adjacent).
- Update docs when behavior becomes company-canonical (IA, principles, metrics).
5. Measure
- Compare against the metric named in Propose.
- If it does not move the needle in an agreed window, revise or kill — do not silently keep zombie features.
Working priority examples
| Priority | Examples |
|---|---|
| P0 | Google auth, wallet bind path, rate limits |
| P1 | Refresh tokens, categories, core Bills |
| P2 | Return windows, recalls |
| P3 | Offers |
| P4 | Warranties / notifications polish |
Anti-patterns
- Specs that only list screens with no data contract
- Shipping eco badges without a real signal
- Putting consumer features on the marketing site “because it’s faster”
- Skipping Measure because “we already know it’s good”