What Maven Clinic Learned About Writing Specs After Prototyping
TRIGGER
Product requirements documents written before prototyping miss micro-interactions and edge cases that only surface when you can click through the experience—leading to specification gaps discovered late in development.
APPROACH
Maven Clinic reversed their typical workflow: instead of writing a PRD first and then designing, they generated a Figma Make prototype first, then wrote the requirements document based on what was working and what was lacking in the interactive artifact. This helped them 'pinpoint the micro-interactions that you don't notice until you start building.'
PATTERN
“Specification gaps discovered late in dev because PRDs were written from imagination. Writing requirements after prototyping captures micro-interactions that abstract thinking misses. Document observed behavior, not guessed behavior.”
✓ WORKS WHEN
- Feature is interaction-heavy with multiple user flows and states
- Team has access to rapid prototyping tools that produce near-production fidelity in hours
- Requirements tend to be underspecified, causing rework during development
- Stakeholders can review and approve interactive prototypes
- Feature scope is bounded enough that a prototype can cover the core experience
✗ FAILS WHEN
- Feature is primarily data or API-driven with minimal UI surface
- Regulatory or compliance requirements must be defined upfront before any artifact creation
- Prototype fidelity misleads stakeholders into thinking the feature is already built
- Team lacks the skills or tools to rapidly iterate on prototypes
- Feature spans multiple systems where end-to-end prototyping isn't feasible