Product Playbooks
Decisions that shape the product itself — what to build next, when to say no, and how founders used real feedback to steer the roadmap without losing focus.
277 tactics · page 10 of 10
“pick one workflow productize it and if you can build the requiring layer on top don't try to build a platform pick the most common most painful workflow and turn it into repeatable stepbystep product for us it was a state doicile change we didn't try to solve all of the international taxation we solved one thing really well”
Productize one painful workflow — refuse to build a platform
Resist the "platform for X" instinct on day one. Identify the single most frequent, most painful workflow inside your category and turn it into a tightly scripted step-by-step product with a recurring subscription on top. Savvy Nomad picked state-domicile-change, not all of international taxation. The narrower the wedge the easier it is to dominate, price, and expand from later.
“I actually started with a building public community... after four months I shut it down... maybe I can do a challenge... maybe I can try teaching so if a community for building in public didn't work maybe I should really just break things down and walk people through how to actually do it but I didn't jump into course creation I did a challenge first... I went into uh live teaching so a cohort-based course... and only recently I was thinking maybe it's time to switch”
Iterate your product format toward what fits the creator, not what's popular
Kevon's sequence: pure community ($5/month, killed at month 4) → 30-day challenge → live cohort course → interactive video lessons → video+challenge hybrid. Each iteration kept what worked and replaced what didn't. Don't commit to a single product format because it's the "right" creator-economy answer. Audit every 4-6 months: what feels like a slog for you (kill), what energizes you (double down), what do students consistently get stuck on (replace).
“I did that for like almost two years and only recently I was thinking maybe it's time to switch because me showing up and do the teaching four times a year in the same format I don't think that's a good use of my time so I switched to using a very interactive way to do video lessons”
Stop repeating cohorts — they're for discovery, not delivery
After 2 years and 8+ cohorts of the same material, Kevon switched to interactive video. The pattern: cohorts are great for discovering what your students need (questions, confusion, gaps) but they're a bad long-term delivery model — you're paid hourly while teaching the same curriculum repeatedly. Use 2-3 cohorts to surface the canonical content, then codify into self-serve video, then layer interactivity (Loom comments, community posts, embedded challenges) on top.
“micro communities on the other hand are often harder to access with membership either being invite only or requiring a purchase the themes and topics discussed Within These communities are typically focused on successful outcomes and unlike General communities which often serve as a place for people to hang out... micro communities are more results oriented and the monetized ones especially focus on helping members achieve specific goals”
Define your community as results-oriented and gated — that's what makes it "micro"
Distinguish a micro-community from a general community by three things: gated access (invite or paid), narrow scope, and explicit outcome focus. "Help indie founders ship their first SaaS" is a micro-community thesis; "hang out and talk about tech" is a general one. The gating filters in members willing to do the work; the outcome focus turns chats into measurable progress. Both choices are what make the community monetizable.
“you need to think of the design of the app as part of your distribution so you need to design the app in a way that's innately viral for social media and when that does happen you can just start testing viral formats on social media once you find a winning strategy you can just double down and scale”
Design the app to be innately viral on social before you ship it
Treat distribution as a design constraint, not a post-launch tactic. Before shipping a consumer app, ask: which scans, results, or outcome screens are share-worthy on a 9:16 TikTok? Build those moments in deliberately (before/afters, color analysis cards, swipe results, scan reveals). If the screen recording isn't inherently compelling, no UGC creator system downstream will rescue it. Distribution-by-design beats distribution-by-marketing.
“everybody has say problems retention which is the turn is very high um and defensibility like you make something and immediately you have a lot of clones because everybody's working with the same stuff everybody's using gp4 uh for Tech stuff almost or llama... within I would say if you're smart within three months with if you're less smart maybe six months to a year so it's very difficult to make a startup AI startup now”
AI startups have structural moat problems — assume profit margins collapse
All AI startups share the same underlying tech (GPT, Llama, Stable Diffusion), so clones arrive within 3-6 months and price competition pushes margins toward zero. Model the AI business as a high-revenue, low-margin, short-window play — not a long-term moat. Pieter explicitly tracks AI startup profit margin separately and accepts it will keep falling; the strategy is harvest then sell, not compound.
“the cost of fine tuning was $3 and then when they saw my tweets where I was sharing my Revenue uh that I was making so much money with this they said sorry we need to increase the price to $20 per training... so you have to go one level higher so you have to get your own uh virtual private server with gpus you know but then you need to learn the code”
Suppliers raise prices when they see your public revenue — abstract dependencies from day one
When you publicly share revenue and your supplier sees the numbers, the price you pay almost always goes up. Pieter's fine-tuning costs jumped 7x once his Avatar AI revenue tweets went viral. Build with an abstraction layer (config-swappable provider) from day one so when a supplier raises prices you can migrate within a week instead of being trapped. Also: weigh the cost of being publicly transparent against the price discovery you're giving suppliers.