Designing How a Company Builds Products, From Scratch

01 Status

02 Summary

What started as a scoping confusion between two interns surfaced a structural gap in how Optifeed built products. The CTO expanded the question to the company level: how does Optifeed actually build products, and can that be written down clearly enough to operate from?

The existing flow was Feedback → PRD → Build. It was not a bad process. For a 10-person team moving quickly, it made sense. The problem was what the PRD was being asked to do: both articulate what the user needs and serve as the direction for what engineering builds. These are different jobs. The first requires understanding. The second requires validation. Running them together means you skip the step where you find out whether your understanding is right.

I designed a model that separates those two jobs. Problem definition stays in the PRD. Solution validation moves into an explicit prototype-and-feedback stage before engineering commits to scope.

03 Problem

Feedback → PRD → Build is a rational process. The team had it. It worked until you needed to know whether you were building the right thing.

The PRD was treated as sufficient to begin building. It was not. A PRD reflects what someone thinks the user needs, based on signals and assumptions collected at a specific point in time. Writing a clear PRD does not tell you whether the solution the team imagines actually solves the problem the user has. That question can only be answered by showing the user something. There was nothing in the flow that required this.

When the assumptions embedded in the PRD were wrong, the team found out during development. The cost of being wrong was paid at full engineering capacity.

Three structural issues compounded this:

• CTO as the routing point for product decisions
  Most decisions passed through the CTO personally. This looked like an authority issue. It was actually an artifact issue. There was no clear stage where product thinking transferred to engineering, so the CTO stayed in the loop on everything because he held the context that had no other place to live.
• No concrete scope reference
  Without a working version of the idea, there was no reference point for what done looked like. Everyone had a different version of the product in their head, and scope expanded toward whichever version was most recently discussed.
• No learning loop
  Each cycle ended with release, not with review. The same structural assumptions could produce the same mistakes across every subsequent cycle.

04 The Model

The new flow adds one stage between PRD and build: a working prototype, tested with real people, before engineering commits to scope. Everything else in the model follows from this single addition.

• Signal and Problem → PRD
  Marketing and AI collect signals and draft a lean PRD. The document has nine fields; the most critical is the Key User Action. This field matters disproportionately because it forces the team to define exactly what the user must be able to do inside the product, not the product vision, not the feature list, but one specific action. If this field is vague, the prototype will be vague, and feedback collected against a vague prototype cannot tell you whether the solution is right.
• Product Engineer research and UX reasoning
  Before execution begins, the Product Engineer re-reads the PRD, checks missing assumptions, and narrows scope to the smallest testable version. This stage exists because receiving a PRD and starting to build are different things. The reasoning that happens between them, checking assumptions, considering comparable flows, defining what the prototype needs to demonstrate, is where scope gets bounded before it becomes expensive.
• Prototype direction and UX notes
  A short document capturing the interpreted problem, user flow, UX decisions, what is in scope, and the execution spec. This document is what gets passed to a coding agent. What the agent produces is directly tied to how clearly this was written. A vague spec produces a vague prototype.
• Rapid prototype and internal feedback
  Structured feedback collected by category: UI, UX, copy, flow, scope, technical risk, business concerns. Applied directly to the product, not to a document. The prototype is the medium for the feedback, not a topic of discussion about it.
• Solution Spec and engineering handoff
  What was decided, why, and within what boundaries. At this point the original PRD is secondary. The validated product, shaped by real feedback from real people, carries more weight than the assumptions the PRD was built on.
• Shape Planning
  Once the Solution Spec exists, the CTO and developers run a scoping session before any line of production code is written. The session starts with one constraint: appetite. Time is fixed at one week. This is not a starting point for negotiation. Scope must fit the time, not the other way around.
  
  The Core Flow / Scope Cut identifies the smallest version that delivers real user value. The question is not "what can we build?" but "what is the most important part of this?" Edge cases, flexibility options, extra features, and secondary use cases come out. No-Gos are named explicitly: what the team is deliberately not building in this cycle and why. The session ends with a commit decision. If scope still does not fit the appetite, it gets reduced and the question gets asked again. Once committed, execution begins.
• Implementation Brief
  The document passed to the coding agent for development. It references the prototype and the Solution Spec as visual context, not as documents to summarize, but as the working reference the agent builds against. The Implementation Brief translates the Shape Planning decisions into a bounded spec: what is being built, what done looks like, and what is out of scope.
• Development and Release
  Engineering builds from the Implementation Brief with the prototype as the visual reference throughout. The build follows the same phased structure used in the rapid prototype: core flow first, edge cases after.
• Monitor and Learn
  Post-release review closes the cycle. What did users do? What did the team learn? The answers feed back into the next Signal to Problem stage.

05 Key Decisions

• Separate problem definition from solution validation
  The PRD defines what the problem is. It does not validate whether the proposed solution solves it. These were running together, which meant the team was always validating in production. The prototype stage exists specifically to move that validation earlier, while the cost of being wrong is still low.
• Thinking before execution
  The UX reasoning stage sits between receiving the PRD and starting to build. It is easy to skip. The pressure at an early-stage startup is usually toward speed, but removing it does not make execution faster. It makes execution more likely to produce the wrong thing quickly. Judgment about what to build cannot be replaced by building faster.
• AI as execution layer, not judgment layer
  AI organizes signals, drafts PRDs, structures specs, and executes prototypes. It does not decide what the Key User Action is, make UX tradeoffs, or determine whether the solution is right. Those decisions require the context that only comes from understanding the user problem, context that cannot be inferred from a prompt. Spec quality determines output quality. The spec is where judgment lives.
• Fix the artifact to clarify ownership
  The coordination problems at Optifeed surfaced first as role ambiguity. Who owns this decision? Why is this going through the CTO? The real source was that there was no defined artifact at the boundary between product thinking and engineering. When you define what artifact belongs at each stage and who owns it, the coordination question answers itself. The model resolved a people-coordination problem by solving a process-artifact problem.

07 What This Proves

The problems that look like coordination problems are usually artifact problems. At Optifeed, product decisions routing through the CTO looked like a people issue. No concrete scope reference looked like a communication issue. Both of them were the same underlying thing: no defined artifact at the stage boundary where product thinking should transfer to engineering.

Designing the model also clarified what it means to use AI in a product process without replacing the part that requires judgment. AI accelerates execution. It does not replace the reasoning that determines what to execute. The spec is the control mechanism. If the spec is vague, the output will be. That constraint does not go away by moving faster.

Optivideo was built inside this model: from PRD to prototype direction to internal feedback to Solution Spec. The model was not just designed. It was run.