Product BuilderOS

Why this matters

How to do it, with Claude Code

1. 1

   Set up your prototyping environment in one afternoon

   Install Claude Code (npm install -g @anthropic-ai/claude-code). Create a project folder. Wire one-command deploy with `npx vercel`. Add your ANTHROPIC_API_KEY to a .env.local. Test the whole loop with a hello-world page. Total setup time: under three hours. If yours took longer, your stack needs simplifying.

2. 2

   Build the pipeline first, the UI second

   The biggest mistake is starting with the UI. Start with the pipeline — the thing that actually does the work. Ask Claude Code to build the backend logic first: input processing, AI reasoning with a specific system prompt, output formatting, action/integration. No UI yet. Make the pipeline work end-to-end with test inputs. THEN wrap it in a minimal web UI.

3. 3

   Ship to one real user in under four hours

   Deploy immediately. The goal is a URL you can share. Ask Claude Code to make it deployable with basic auth, mobile-responsive layout, error handling, and a simple feedback mechanism. Deploy with `npx vercel`. Share the URL with one named customer. Watch them use it. The feedback you get from a working prototype in four hours is worth more than four weeks of spec reviews.

Why this matters

How to do it, with Claude Code

1. 1

   Schedule weekly customer exposure, non-negotiable

   Block four customer-facing hours every week. Two sales calls (one new logo, one renewal), one support shadow, one onboarding shadow. Take notes in a single doc tagged by date. After 90 days, you'll have a pattern map no dashboard reveals. Ask Claude Code: 'Read these 12 weekly notes. Cluster recurring friction by surface and severity. Flag the three signals that show up in 50%+ of weeks.'

2. 2

   Build a continuous-listening pipeline

   Pipe every customer signal into one searchable corpus: support tickets, sales-call transcripts, Slack-Connect threads, churn-survey responses, in-app feedback, NPS comments. Use Claude Code to build a daily digest agent: 'Pull yesterday's signals from each source. Tag by product surface and emotion. Surface anything that crossed a threshold (>3 mentions, or strong negative emotion, or a paying customer). Slack me a one-page digest at 8 a.m.'

3. 3

   Run the 'one customer' sprint

   Each sprint, pick ONE customer who triggered a signal worth solving. Ship to them specifically. Watch them use it within 48 hours. Iterate. The shipped surface generalizes later, but the first cut must solve THIS customer's pain, named and dated. Generic personas average pain into nothing. Specific customers create the constraint that produces clarity.

Why this matters

How to do it, with Claude Code

1. 1

   Know your AI primitive menu cold

   Memorize the five primary primitives and when each one wins: rules (deterministic, cheap, brittle), a single model call (one-shot reasoning, predictable cost), RAG (grounded answers, sub-second latency, freshness-sensitive), an agent with tools (multi-step actions, fuzzy outcome, harder to test), and fine-tuning (only when prompt engineering caps out AND you have stable labeled data). For each, know the cost shape, latency shape, and most common failure mode.

2. 2

   Run the 'decide and defend' test on every AI scoping call

   Before engineering starts, write three lines: (1) the AI primitive you're recommending, (2) the cost and latency you expect at scale, (3) the single biggest failure mode and what monitoring will catch it. If you can't write all three, you don't have a scope yet. Use Claude Code to pressure-test: 'I'm proposing [primitive] for [use case]. Argue against this choice. What primitive would you recommend instead and why?' Iterate until you can defend in a 5-minute exec review.

3. 3

   Map workflows before features

   Before scoping any AI feature, map the workflow it lives inside. Where's the trigger? Where's the human checkpoint? Where's the automation boundary? Ask Claude Code: 'Map the complete workflow for [process]. For each step: who does it, what input they need, what decision they make, what output they produce. Then: can AI handle this step with >90% reliability? Mark each step AUTOMATE / HUMAN_REVIEW / HYBRID.' The workflow map is what makes your primitive choice defensible.

Why this matters

How to do it, with Claude Code

1. 1

   Define the outcome before the feature

   Before any scoping doc, write one sentence: 'This feature will cause [specific customer] to do [specific behavior] [N% more / N% faster / by date X].' If you can't write that sentence with concrete numbers and a named customer, you're not ready to build. Use Claude Code: 'Pressure-test this outcome statement. Is it specific enough to disprove? What evidence would I need to declare success or failure? What's the cheapest experiment that tests it?'

2. 2

   Write the eval before the feature

   For AI features specifically: the eval is your outcome contract. Define what 'good' means in measurable terms before code is written. Build a rubric (Correctness / Completeness / Tone / Safety, 1-5 each). Generate 20 test cases covering happy path, edges, and adversarial inputs. Wire it into CI so every change runs against the rubric. The eval becomes the spec — engineering can't ship a regression without you knowing.

3. 3

   Instrument the production signal that proves outcome shipped

   After launch, the dashboard answers ONE question: did the outcome change? Not 'did users click the button?' Did the behavior shift? Build a daily-running script: 'For the cohort that touched [feature] in the last 7 days, compute [outcome metric]. Compare to the matched cohort that didn't touch it. Compare to baseline before launch. Alert if the gap is below the threshold I committed to in the scoping doc.' If the dashboard can't answer that question, your outcome statement was vague.

Why this matters

How to do it, with Claude Code

1. 1

   Write the launch tweet before you write the spec

   Before any feature is built, write the one-tweet announcement (280 chars max). Force yourself to name the customer pain in plain English, the change the feature creates, and one concrete number. If you can't write the tweet, you can't write the spec — the work isn't crisp enough yet. Use Claude Code: 'Here's the feature I'm scoping. Draft five candidate launch tweets at different angles (problem-first, contrarian, customer-quote, before/after, big-number). Which one would you bet on?' Iterate until one lands.

2. 2

   Build the demo before the doc

   Marketing pages, sales decks, onboarding tooltips — all downstream of the demo. The demo is the single artifact that has to land in 90 seconds. Record a Loom in two takes. No edits. Watch yourself back. If you wouldn't reshare it, the feature isn't shippable yet. Replace any product copy with the demo whenever possible. Demos travel; docs don't.

3. 3

   Run distribution yourself for the first 100 customers

   Don't hand distribution to GTM until you've personally placed the feature in front of the first 100 customers and watched what works. Pick three channels (LinkedIn post, one-to-one DM, customer Slack-Connect ping). Run each daily for a week. Track who replied and what landed. The channel patterns you discover become the brief for whoever picks up GTM long-term. The Product Builder who skips this step ships features no one finds.

Why this matters

How to do it, with Claude Code

1. 1

   Map your full arc explicitly, then hold all six skills in one head

   Once a quarter, write the full-arc map for your current product: customer signal → prototype → ship → launch → gross-margin trajectory → next-iteration hypothesis. Each arrow names the specific evidence that lets you move to the next stage. Use Claude Code to pressure-test: 'Here's my full-arc map for [product]. Where's the weakest link? Which arrow is wishful thinking instead of evidence-backed?' The map is the contract you hold yourself to.

2. 2

   Own pricing and gross margin alongside the feature

   Pricing is not a finance problem. For AI products especially, the cost-per-request determines whether the feature is even viable. Compute the unit economics before the engineering investment is locked in. Defend the pricing model in the same review as the launch plan. If you don't, someone else does it badly, and the feature is in market with the wrong number on it.

3. 3

   Hand off intentionally — don't fragment ownership by default

   Some work scales by handing it off; some breaks. Distribution scales (eventually) to GTM. Customer proximity stays yours forever. Pricing migration partners with finance, but you keep the customer narrative. Evals stay yours until the next PM takes over the surface. The skill is knowing which handoffs to make when. The default handoff (everything goes to someone else after launch) creates the fragmented-ownership disease that defined PM in 2018. Resist.