Cutting Idea-to-Release From a Month to a Week
Idea to release went from over a month to a week, across a 10-person team.
Problem
Optifeed built with Feedback → PRD → Build. For a 10-person team moving fast, it made sense.
An idea took over a month to reach users. It was built in a closed box, out of their sight, then released.
But the PRD did two jobs at once:
- Say what the user needs. That needs understanding.
- Direct what engineering builds. That needs validation.
The PRD was treated as enough to start building. It was not. When its assumptions were wrong, the team found out in development, at full engineering cost.
It began as a scoping mix-up between two interns. The CTO widened it: how does Optifeed build products, and can it be written down? I designed the answer.
Three structural issues made it worse:
- The CTO routed most decisions. It looked like authority. It was missing artifacts: the context had nowhere else to live.
- No concrete scope reference. Scope drifted toward the latest version discussed.
- No learning loop. Cycles ended at release, so the same mistakes repeated.
Four decisions
Test the solution before building it.
The PRD said what the problem was. Nothing checked the fix, so the team validated in production. A prototype now checks it early, while being wrong is cheap.
Think before building.
Early-stage pressure pushes toward speed, so this step is easy to skip. Skipping it does not make execution faster. It makes the wrong thing faster.
AI builds. People decide.
AI drafts PRDs and specs and builds prototypes. The key user action and the UX tradeoffs stay human. The spec is where judgment lives.
How I use AI →Fix the handoff, not the people.
It looked like a role problem: why does everything go through the CTO? The real gap was no defined handoff between product and engineering. Define what each stage hands over, and who owns it, and ownership follows.
The model
One stage added between PRD and build: a working prototype, tested with real people, before engineering commits to scope.
- Signal → PRD. Lean, nine fields. The Key User Action matters most.
- Product Engineer reasoning. Check assumptions. Cut to the smallest testable version.
- Prototype direction. Problem, flow, UX decisions, scope. Handed to a coding agent.
- Rapid prototype + feedback. Feedback by category, applied to the product, not a document.
- Solution Spec + handoff. What was decided, why, within what bounds.
- Shape Planning. The CTO and developers fix one week. Scope must fit.
- Implementation Brief. A bounded spec, with the prototype as the working reference.
- Development and release. Core flow first, edge cases after.
- Monitor and learn. Review feeds the next cycle.
Result
- Timeline
- ~4 weeks
- How
- Spec → wait for engineering → build → discover the problem
- What engineering receives
- A document
- Risk
- Build the wrong thing at full engineering cost
- Timeline
- ~1 week
- How
- Signal → prototype with AI agents → validate → spec → shape → build
- What engineering receives
- A working prototype, a solution spec, and a scoped Implementation Brief
- Risk
- Discover the problem before engineering touches it
It was run, not just designed: Optivideo went from PRD to prototype to feedback to Solution Spec inside it.
The full model
We collect customer feedback, identify recurring patterns, and turn them into a clear problem definition.
We clarify the problem enough to turn the idea into a prototype.
We make the idea testable before production development begins.
Stakeholder Review: feedback is collected through the prototype.
The solution matures through feedback, and the PRD is rewritten with stronger validation.
Owner: Product EngineerStakeholder Review
Time constraint
Choose the smallest flow that delivers user value. 'What is the most important part of this?'
What we deliberately leave out.
The bounded development spec produced from Shape Planning: what is being built, what done looks like, and what is out of scope, using the prototype and Solution Spec as working references.