PostHog’s Product Engineer Handbook describes the role as someone who “cares more about outcomes and impact than the exact implementation.” In a small startup without a dedicated PM, that translates directly: you are the person deciding what to build, validating it with users, and owning the product decisions that make the code meaningful.
If you’re working in a team of 5 to 10 people, with a CTO and no dedicated PM, moving fast without a structured loop doesn’t accelerate the product. It accelerates the wrong version of it.
This is the workflow I use before writing a single line of production code. It’s designed for a specific context: an early-stage startup, a small team, a CTO who owns the technical decisions. If you’re working solo on a side project, or inside a larger organization with a dedicated PM function, some of this will apply, but the loop will look different.
Step 1: Define the Problem, Not the Feature Before anything else, I try to understand the actual problem. Not the proposed solution, not the feature request. The problem.
For this, I use a structured PRD format with nine fields. Each field serves a specific function:
Problem: One sentence. The core issue the user faces, with no solution language.
Specific enough to be testable:
“[User], in [context], experiences [problem].”
User: Who has this problem. Role-based. At most one primary and one secondary segment.
Context: When does the problem occur? What triggers it?
Current Behavior: How does the user deal with this today? Workarounds, manual steps, alternative tools. This field is often more revealing than the problem statement itself, because it shows what people are already willing to tolerate.
Pain: Why does this matter? Time loss, performance cost, decision quality degradation. Specific, not general.
Desired Outcome: What should the user be able to do once the problem is solved? Result-oriented, not feature-oriented.
Key User Action: The most critical field in the entire PRD. It defines exactly what the user must be able to do inside the product. This single field determines what gets prototyped. Everything else in the format supports it.
User Flow (Mini): The 3 to 5 steps the user takes to complete the key action. Screen-level thinking, not system-level.
Success Signal: How will you know the problem is actually solved? Behavior-based and measurable: Is the user completing the action? Is time spent decreasing? Is usage increasing?
The format forces a specific discipline. Write the problem without reaching for the solution. That constraint is the point. Most feature requests arrive pre-packaged with a proposed implementation. This format strips that away and asks what is actually broken, for whom, and when.
Step 2: Visualize the User Flow Once I have a clear problem and a key user action, a flow starts forming in my head. Before building anything, I put that flow on a canvas, using Miro or anything similar.
Notes I took while creating a landing page widget. Discovery boards tend to be messy. That’s expected. The early stages look like scattered notes, competitor references, and half-formed ideas. What matters is the output: a core user flow that shows which steps the user passes through and what the product does at each point.
This artifact serves as the shared reference for everything that follows. When a team member or stakeholder asks “what are we building?”, the core user flow is the answer.
Step 3: Run the Discovery Loop With the core user flow defined, I build a frontend-only prototype. A coding agent handles this in a day or two.
This prototype is not a one-time deliverable. It’s the active vehicle for everything that follows. Customer interviews happen through it. Stakeholder communication happens through it. The CTO feasibility conversation references it. Every iteration during discovery lands back in it.
One thing I make explicit whenever I share the prototype: this is not the final product. It’s the first draft of the idea, and it will change. Setting that expectation upfront changes how people engage with it. They give directional feedback instead of fixating on visual details.
The discovery loop runs through three channels:
Customer interviews. People in interviews tend to say everything they want. They’ll describe their ideal product, list every feature they’ve ever wished for, and frame it all as essential. The raw notes are noisy by design. The real work happens after the interviews, during consolidation: look for the friction points that multiple people named, the workarounds everyone already has, the actions people described differently but were actually the same underlying need. That’s where the signal is. CTO technical feasibility. This conversation covers budget, infrastructure cost, team capacity, and technical constraints. Some part of the final product vision almost always gets pruned. That’s the point. Better to scope down in a conversation than to discover a hard constraint halfway through development. Prototype iteration. As interviews and the feasibility conversation shape the thinking, the prototype evolves to reflect the updated understanding. By the end of the loop, you have 2 aligned artifacts: the notes describing what the product needs to do (feedbacks from interviews), and a working prototype showing how it looks and flows. Step 4. Create the Product Knowledge Document When the prototype is complete, I run a single prompt that reads the codebase and the discovery notes together.
The output is the product knowledge document.
This document is not a summary of what was discussed. It reflects what was actually built and decided. The notes capture what the team learned throughout discovery. The prototype codebase captures how those decisions took shape in practice. Together they produce the final picture of what this product is.
You are a product architect. Read the codebase in this directory, thoroughly source files, types, API routes, state management, data structures config files, and any existing documentation. Also read the discovery notes provided below. Then produce a single, comprehensive Product Knowledge Document in Markdown. The document must be written as if for a new team member or an AI agent that will work on this product. It must reflect only what actually exists in the code and what was confirmed during discovery. Do not invent features, do not speculate about future plans. Required sections:
- Goal: one sentence — what does this product do and for whom?
- Core Questions: 3 to 6 questions the product answers for its user
- Product Definition: 2 to 3 paragraphs. What it is, what it is not.
- Current Problem / Target Experience: side-by-side comparison
- End-to-End Product Workflow: ASCII block diagram of the full flow
- Key Decision Logic: branching and routing logic as ASCII decision trees
- Data Model: core TypeScript interfaces with field-level explanations
- State Management: how state flows through the product
- Scoring or Classification Logic: criteria and weights as a table, if applicable
- Invalid / Weak Signals: what the product explicitly ignores and why
- Output / Export: what the product produces for the user
- V1 Scope: In Scope / Out of Scope as two lists
- Open Questions: unresolved decisions visible in the code
- Known Limitations: gaps, edge cases, honest weaknesses
- Success Criteria: how you would know the product is working For every major decision in the product, add a line: "Design principle: [why this choice was made]." Discovery notes: [PASTE NOTES HERE / Or tell the coding agent which md files to read] This document becomes the source of truth.
Everything the team knows about the product lives in one place.
When a question comes up during development, the answer should be here.
The second step is extracting V1 from that picture.
V1 is not the full product. It is the smallest version that delivers the core user flow and demonstrates the core value proposition. The prompt that defines V1 is different from a standard build instruction. It does not ask the AI to decide what V1 should be. It takes the specific inputs that shaped the V1 decision and makes them explicit: what the CTO said about scope and constraints, what the discovery loop confirmed as non-negotiable requirements, and what the team has agreed must ship in the first version. The AI uses these as given and produces the V1 picture from them.
You have the product knowledge document below. Your task is to define V1. V1 must deliver the core user flow and the core value proposition. Nothing more. Use the following inputs to scope V1: CTO decisions and constraints: [PASTE CTO DECISIONS] Core requirements from the discovery loop: [PASTE DISCOVERY REQUIREMENTS] Must-haves for V1: [PASTE MUST-HAVES] Using the knowledge document and the inputs above, produce:
- Core User Flow: the path from entry to core value, step by step
- V1 Scope: what is in, what is out, as two lists
- No-Gos: what is deliberately excluded from V1
- Success Signal: how you will know V1 is working [PASTE KNOWLEDGE DOCUMENT / Or tell the coding agent which md files to read] Step 5: Build V1 or Hand Off With the source of truth in hand, there are 2 paths forward depending on the team structure.
Path 1: Spec-driven development. If you’re building V1 yourself, the source of truth becomes the input for a phased build. Vibe coding and one-shot prompting both have legitimate uses. I’ve written about this in more detail in Vibe Coding vs. Spec-Driven Development. For fast exploration or a standalone prototype, they work well. But for building V1 of a product with a defined scope, known user flows, and a team that will maintain and extend it, they’re the wrong tool.
The problem with one-shot prompting is that the coding agent receives the entire product vision at once and fills in everything it doesn’t know with assumptions. The product that comes out reflects the model’s interpretation of your intent, not your actual specification.
Instead, break V1 into phases. Each phase implements a defined slice of the V1 picture and gets its own bounded spec. The phases vary by codebase. What stays fixed is the approach: one or more spec per phase, a clear definition of done for each, and a coding agent that works from a specific document rather than the full product vision.
Path 2. Engineering handoff. If V1 development moves to an engineering team, the knowledge document and the V1 picture are what you hand over. They carry everything the team needs to build without requiring a synchronous briefing, what the product is, why every decision was made, what’s in scope, and what success looks like.
This is slower than one-shot prompting at the start. It’s what produces a V1 you can understand, extend, and hand off.
The instinct to build fast is right. The part that’s easy to miss is that speed-to-code and speed-to-learning are different things. A prototype validated with five customers in two days tells you more than two weeks of building the real thing without one.