Change Card template: the smallest spec engineers trust
PRDs are too big. Tickets are too small. Use a Change Card: intent -> AC -> surfaces -> verification -> rollout.
PRDs are too big. Tickets are too small.
The missing unit is a Change Card.
A Change Card is not "more docs". It's the smallest spec that survives code review.
Why engineers don't trust most specs
Engineers get blamed for:
- scope creep
- hidden blast radius
- broken flows
- auth/PII surprises
- "it looked right" changes
So a spec has to answer:
- what is changing?
- what does "done" mean?
- what surfaces does this touch?
- how do we verify it?
- how do we roll it out safely?
A Change Card forces that.
Bad vs good
Bad: "Improve onboarding."
Good: "Move billing after first value moment -> onboarding completion >= 55% within 14 days."
Bad: "Add CSV export."
Good: "Add CSV export with explicit limits + role check -> reduce support tickets about exports by 30% in 30 days."
Change Card template (copy/paste)
INTENT (1 sentence): WHAT changes: WHY now (evidence links): ACCEPTANCE CRITERIA (measurable): SURFACES TOUCHED: UI / API / DB / Policy / Docs RISKS: auth / PII / migration / backwards compat VERIFY: tests + runtime signal ROLLOUT: flag? staged? thresholds? OWNER:
A filled example
INTENT: Reduce onboarding drop-off after signup.
WHAT changes: Delay billing screen until after "first value" action.
WHY now: Call notes + funnel shows drop at billing step.
ACCEPTANCE CRITERIA: Onboarding completion >= 55% within 14 days.
SURFACES TOUCHED: UI -> onboarding flow API -> user state DB -> onboarding step state Policy -> billing access/permissions Docs -> onboarding help content
RISKS: Users stuck in billing limbo Payment retries Auth edge cases
VERIFY: Funnel metric + error rate + support tags
ROLLOUT: 10% -> 50% -> 100% if metrics hold
How this connects to Impact Reports
A Change Card is the plan. An Impact Report is the blast radius audit.
One without the other becomes gambling.
If you want the Impact Report template:
- https://www.contractspec.studio/blog/impact-reports-breaks-must-change-risky (or search on the blog)
Where ContractSpec Studio fits
ContractSpec Studio is built to generate Change Cards from messy evidence, then produce an Impact Report before tickets get exported.
If you want to see real examples:
- https://www.contractspec.studio/
If you want a filled example, here are sample outputs.
If you want a filled example, here are sample outputs.Related articles
The 8-step loop: feedback -> verified impact
A deterministic product loop: evidence -> Change Cards -> Impact Reports -> exports -> outcome checks.
Outcome checks: deploy isnt done (deploy + 14 days)
A simple outcome check schedule (+24h, +7d, +14d) so your roadmap stops being a story.
Impact Report template: Breaks vs Must-change vs Risky
A practical Impact Report template to make blast radius explicit before you ship.