diff --git a/CLAUDE.md b/CLAUDE.md index 10c2127e5..98a311de0 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -86,6 +86,7 @@ Follow official methodology from `/knowledge/`: - LinkedIn pipeline: `docs/workflows/linkedin-post-pipeline.md` (Paul Keen voice rules, AI score rubric, save-location convention) - LinkedIn campaign: `docs/workflows/linkedin-icp-validation-plan.md` - Cover images: `docs/workflows/cover-images.md` (canonical spec remains `.stitch/design.md`) +- Visual scroll gate (rendered-output QA): `docs/workflows/visual-scroll-gate.md` - **Content plan (active)**: `docs/projects/2510-seo-content-strategy/20-29-strategy/20.07-content-plan-icp-e-q2-2026.md` - Commands & hooks overview: `docs/workflows/commands.md` - Agent strategy: `docs/workflows/agents.md` @@ -175,6 +176,7 @@ Repo voice guides and workflow docs override generic writing, SEO, or humanizer - Any "NO" or "MIXED" on criteria 3 or 4 = ROLLBACK or REDESIGN before commit. Don't ship visuals that fail user-perspective scoring just because they're technically rendering. - Verify the visual's POSITION on first-fold: at the typical laptop viewport (1280×800), does the new visual appear ABOVE the fold? If it doesn't, it cannot win the 3-second hook — relocate or accept it as a mid-page visual break (different acceptance criteria). - For Mermaid diagrams specifically: measure rendered height. If > 2× viewport height, the diagram is too tall — reader perceives it as a wall, not a hook. Caught 2026-05-19: my Hero Roadmap rendered at 1551px on mobile (2× viewport) and the cursive font's dash-strikethrough effect on phase labels degraded legibility further. +- **Visual SCROLL gate (BLOCKING for any new/edited content page, not just new media)**: walk the FULL page section-by-section in chrome-devtools at 1280×800 AND 390×844, screenshot each scroll view, and actually inspect each screenshot before handback. Canonical protocol + per-view defect checklist + numeric probes: `docs/workflows/visual-scroll-gate.md`. Text validators cannot see rendered output — the 2026-07-10 Module 3 pass caught mermaid node clipping, SVG text crossing artwork borders, a stale cover badge on a freshly wired og:image, a wrong-direction "diagram above" reference, and a renumber leftover INSIDE an SVG, all invisible to the banned-string ratchet. One screenshot of the hero is NOT this gate. **Cognitive load + F-pattern rules (mandatory for long-form posts > 800 words):** - Research-grounded rules from `docs/projects/2605-tech-for-non-technical-founders/10-19-research/10.05-content-organization-patterns-2026.md` Part 2 (Gloria Mark / Pew 2026 / NN/g F-pattern / Sweller CLT). Pew 2026: 71% of readers scroll past within 3 seconds without a visual hook; Gloria Mark 2026: per-screen attention = 43s. diff --git a/content/course/tech-for-non-technical-founders-2026/_index.md b/content/course/tech-for-non-technical-founders-2026/_index.md index e21b837f9..6623fbd14 100644 --- a/content/course/tech-for-non-technical-founders-2026/_index.md +++ b/content/course/tech-for-non-technical-founders-2026/_index.md @@ -65,7 +65,7 @@ The five mistakes below sink more first products than bad code does - we have wa - You have never systematically validated a business before - You might have tinkered with no-code tools, but you want a structured path instead of guessing -Skip this course if you want to learn to code or hand off founder judgment to someone else. +Skip this course if you want to learn to code or hand off founder judgment to someone else. And if what you need most is cohort deadlines and peers, [YC Startup School](https://www.startupschool.org/) runs free - this course is the self-paced, artifact-first alternative. ## Module map diff --git a/content/course/tech-for-non-technical-founders-2026/build-path-decision-worksheet/index.md b/content/course/tech-for-non-technical-founders-2026/build-path-decision-worksheet/index.md index 2ed3e8257..c9d71cdf6 100644 --- a/content/course/tech-for-non-technical-founders-2026/build-path-decision-worksheet/index.md +++ b/content/course/tech-for-non-technical-founders-2026/build-path-decision-worksheet/index.md @@ -38,7 +38,7 @@ She showed us the contract on a Tuesday. By Friday we had walked her through the ## How to use this -Friday afternoon, alone, 30 minutes, before coffee runs out. Bring three documents: your filled-in [Validated Problem Statement](/course/tech-for-non-technical-founders-2026/validated-problem-statement-template/) from Chapter 2.1, your filled-in [one-page brief](/course/tech-for-non-technical-founders-2026/vibe-prd-template/) from Chapter 3.1, and a current bank statement showing months of runway. Pen on paper. Phone in another room. +Friday afternoon, alone, 30 minutes, before coffee runs out. Bring three documents: your filled-in [Validated Problem Statement](/course/tech-for-non-technical-founders-2026/validated-problem-statement-template/) from Chapter 2.5, your filled-in [one-page brief](/course/tech-for-non-technical-founders-2026/vibe-prd-template/) from Chapter 3.1, and a current bank statement showing months of runway. Pen on paper. Phone in another room. Answer the five questions in order. Each one is factual, not aspirational. "Number of paying pre-orders" is a count from your Stripe dashboard, not a vibe. "Months of runway" is cash on hand divided by monthly burn, not a guess. The matrix at the bottom routes you to Path 1, 2, 3, or 4 based on the five answers. @@ -189,7 +189,7 @@ your Notion doc) | Path | Choose when | First action this week | Cost | |---|---|---|---| -| **1. Validate without code** | Q1 = No, OR Q3 = less than 4 months | Ship Carrd page + Stripe checkout + Notion FAQ. Send to 35 ICP prospects. | $0 - $300 in tools + optional $100-200 in paid ads | +| **1. Validate without code** | Q1 = No, OR Q3 = less than 4 months | Ship Carrd page + Stripe checkout + Notion FAQ. Send to your 30-name outreach list. | $0 - $300 in tools + optional $100-200 in paid ads | | **2. Self-serve build (6A)** | Q1 yes, Q2 light, Q4 = $0-$400/wk, Q5 = senior eng in network | Paste one-page brief into Lovable. Hook Supabase + Stripe + Resend. | $200 - $1,200 / month | | **3. Fractional CTO bridge (5.2)** | Q1 yes, Q2 mid, Q4 = $1.6K-$4K/mo OR Q5 = no senior eng | Hire 5-10 hrs/wk Fractional CTO. Use for architecture, PR review, hiring, cost watch. | $1,600 - $4,000 / month | | **4. Hire a team (6B)** | Q1 yes, Q2 heavy, Q4 = $5K+/mo | Read draft SOW clause-by-clause. Confirm GitHub/AWS/domain ownership before kickoff. | $30K - $80K / month | diff --git a/content/course/tech-for-non-technical-founders-2026/channel-selection-before-outbound/index.md b/content/course/tech-for-non-technical-founders-2026/channel-selection-before-outbound/index.md index 9cae1823f..393c4aba2 100644 --- a/content/course/tech-for-non-technical-founders-2026/channel-selection-before-outbound/index.md +++ b/content/course/tech-for-non-technical-founders-2026/channel-selection-before-outbound/index.md @@ -96,8 +96,8 @@ At this stage you are choosing from four options. Here is what each one actually | Channel | Best for | Requires | Red flag | |---------|----------|----------|----------| -| **LinkedIn DM** | B2B SaaS/services, professional buyers, job-title filtering, $200+/mo | 1-2 hrs/week; Sales Navigator trial or Apollo.io free tier (credit-based: ~100 email credits + ~10 export credits/mo); one clear filter (title + company + industry) | Buyer is not a professional (freelancer, solo creator, non-employee) | -| **Cold email** | Any B2B with verified work emails; cheaper at volume | Separate sending domain; free tool ([Instantly](https://instantly.ai) / [Smartlead](https://smartlead.ai)); 30-50 emails from [Apollo](https://apollo.io) / [Hunter](https://hunter.io) (25 searches/mo free tier) | Open rate <20% after first batch = domain rep or subject lines broken; fix before scale | +| **LinkedIn DM** | B2B SaaS/services, professional buyers, job-title filtering, $200+/mo | 1-2 hrs/week; Sales Navigator trial or Apollo.io free tier (credit-based free tier); one clear filter (title + company + industry) | Buyer is not a professional (freelancer, solo creator, non-employee) | +| **Cold email** | Any B2B with verified work emails; cheaper at volume | Separate sending domain; free tool ([Instantly](https://instantly.ai) / [Smartlead](https://smartlead.ai)); 30-50 emails from [Apollo](https://apollo.io) / [Hunter](https://hunter.io) (free tier available) | Open rate <20% after first batch = domain rep or subject lines broken; fix before scale | | **Community outreach** | B2B and prosumer where buyers already gather in Slack/Discord/forum | Must be a genuine participant first; one signal-quality post per sprint (not per week); spend 2 weeks commenting before posting product or get banned permanently | Joining this week then immediately selling = permanent ban from the community | | **Social organic** | B2C and prosumer, visual products (apps, productivity tools, demos); buyer discovery from peers/influencers | A sustained posting cadence; format shows product working (screen recordings, before/after, results) | Never posted before AND can't commit to the early low-visibility stretch | | **Engineering as Marketing** | Any B2B or prosumer where your ICP searches for tactical solutions; zero-CAC organic SEO | One free no-code micro-tool (calculator, checklist, grader, template) that solves one micro-problem for your ICP; build it on Carrd/Tally/Notion in an afternoon | Your ICP doesn't search for tactical tooling (they buy via referral or sales call); the micro-tool solves a toy problem nobody actually has | @@ -144,7 +144,7 @@ The prompt is a forcing function, not a crystal ball. The real data comes from r > > **The real gate:** ≥9/12 channel-fit score + a full send/reply/follow-up arc with reply rate >5%. > -> **Optional: auto-parse social media for leads.** [WorthBuild](https://worthbuild.io) (1 free report/month) scans Reddit, Twitter/X, and LinkedIn for posts matching your ICP's problem description and returns a list of named people publicly complaining about the thing you solve. Use it to seed your outreach list when the manual reading in Ch 2.3-2.4 didn't produce enough names. The free tier gives you one batch per month - save it until you have exhausted your hand-picked list and need fresh contacts. +> **Optional: auto-parse social media for leads.** [WorthBuild](https://worthbuild.io) (free tier available) scans Reddit, Twitter/X, and LinkedIn for posts matching your ICP's problem description and returns a list of named people publicly complaining about the thing you solve. Use it to seed your outreach list when the manual reading in Ch 2.3-2.4 didn't produce enough names. The free tier is metered - save it until you have exhausted your hand-picked list and need fresh contacts. ## Channel Selection Worksheet diff --git a/content/course/tech-for-non-technical-founders-2026/engineering-org-chart-non-technical-founder/index.md b/content/course/tech-for-non-technical-founders-2026/engineering-org-chart-non-technical-founder/index.md index d09dd2a80..7937ef15a 100644 --- a/content/course/tech-for-non-technical-founders-2026/engineering-org-chart-non-technical-founder/index.md +++ b/content/course/tech-for-non-technical-founders-2026/engineering-org-chart-non-technical-founder/index.md @@ -30,7 +30,7 @@ related_posts: false course_nav: false --- -> **Chapter 5.2 · Step 1 of 5** · [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) +> **Going Further · Manage a Hired Team** · [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) > > **Input:** a team in place + a signed SOW > diff --git a/content/course/tech-for-non-technical-founders-2026/find-10-people-where-to-look/index.md b/content/course/tech-for-non-technical-founders-2026/find-10-people-where-to-look/index.md index de6bcc48f..b620c22be 100644 --- a/content/course/tech-for-non-technical-founders-2026/find-10-people-where-to-look/index.md +++ b/content/course/tech-for-non-technical-founders-2026/find-10-people-where-to-look/index.md @@ -216,7 +216,7 @@ These are skip-by-default. The main chapter works without any of them. > **Next:** [2.4 · Find 10 People: What to Say](/course/tech-for-non-technical-founders-2026/find-10-people-with-problem-outreach-2026/) - the message templates, cadence, and follow-up sequence. > **If blocked:** If the AI returned "NOT FOUND" for every community, your hypothesis is too vague. Go back to Ch 1.1 and rewrite the customer sentence with a specific role, company size, and the moment in their week when the pain happens. -> **Stuck? Most first-timers stall here:** your name list stops at 3 people. **Fix:** search a related keyword - "boarding costs" instead of "pet sitter," "claim denial appeal" instead of "medical billing." The second-degree search surfaces people with the same problem but different vocabulary. 30 minutes of keyword variation turns 3 names into 12. Not "License Apollo Pro." +> **Stuck here?** Your name list stops at 3 people. **Fix:** search a related keyword - "boarding costs" instead of "pet sitter," "claim denial appeal" instead of "medical billing." The second-degree search surfaces people with the same problem but different vocabulary. 30 minutes of keyword variation turns 3 names into 12. Not "License Apollo Pro." --- diff --git a/content/course/tech-for-non-technical-founders-2026/first-paying-customer-operating-kit/index.md b/content/course/tech-for-non-technical-founders-2026/first-paying-customer-operating-kit/index.md index ab0523184..d1661572d 100644 --- a/content/course/tech-for-non-technical-founders-2026/first-paying-customer-operating-kit/index.md +++ b/content/course/tech-for-non-technical-founders-2026/first-paying-customer-operating-kit/index.md @@ -80,7 +80,7 @@ Why it matters: removes the "what do I say in the email" friction so you spend 6 ### 3. Design Partner Agreement template (one-page LOI + paid pilot) -The one-page DPA from [Chapter 5.3](/course/tech-for-non-technical-founders-2026/paid-pilot-charge-before-ship/). Six sections plus signature block. Plain English, mutual-edit document, no lawyer required for v1. Comes in three formats: Google Docs (default), PDF (for customers who want to print), DocuSign-import (for customers who want to e-sign with audit trail). +The one-page DPA from [Chapter 5.4](/course/tech-for-non-technical-founders-2026/paid-pilot-charge-before-ship/). Six sections plus signature block. Plain English, mutual-edit document, no lawyer required for v1. Comes in three formats: Google Docs (default), PDF (for customers who want to print), DocuSign-import (for customers who want to e-sign with audit trail). Two annotated examples: a $1,500 B2B SaaS pilot DPA and a $5,000 B2B services pilot DPA, both based on real (anonymized) 2026 founder deals. diff --git a/content/course/tech-for-non-technical-founders-2026/first-ten-customers-outreach-message/index.md b/content/course/tech-for-non-technical-founders-2026/first-ten-customers-outreach-message/index.md index 47a30e50c..b6a3cd0ee 100644 --- a/content/course/tech-for-non-technical-founders-2026/first-ten-customers-outreach-message/index.md +++ b/content/course/tech-for-non-technical-founders-2026/first-ten-customers-outreach-message/index.md @@ -48,7 +48,7 @@ If no real reference exists for a cold-bucket name, move them to [Ch 5.5 cold ou **Part 2: One line on the problem, in their language.** Use the verbatim Q3 answers from your [Chapter 5.1 survey](/course/tech-for-non-technical-founders-2026/must-have-segment-pmf-test/). "I am building a tool that lets B2B marketers run an end-to-end attribution model without an analyst." -**Part 3: A Loom video, not a paragraph.** Record one 90-second Loom. Free tier gives you 25 videos. Show your product in 60 seconds, you on camera for the other 30. The Loom script comes directly from your Ch 5.1 verbatims. Read the Q2-Q3 quotes aloud, then point at the product feature that addresses the pain they describe. +**Part 3: A Loom video, not a paragraph.** Record one 90-second Loom. The free tier covers this batch. Show your product in 60 seconds, you on camera for the other 30. The Loom script comes directly from your Ch 5.1 verbatims. Read the Q2-Q3 quotes aloud, then point at the product feature that addresses the pain they describe. **Part 4: A specific ask.** "15 minutes to walk you through it and see if it solves [the problem]? Open to a paid pilot if it does. Calendly: [link]." The "paid pilot" teaser is load-bearing. Full mechanic lives in [5.4](/course/tech-for-non-technical-founders-2026/paid-pilot-charge-before-ship/). diff --git a/content/course/tech-for-non-technical-founders-2026/friday-demo-rule-founder-progress/index.md b/content/course/tech-for-non-technical-founders-2026/friday-demo-rule-founder-progress/index.md index 9b963078a..87953107d 100644 --- a/content/course/tech-for-non-technical-founders-2026/friday-demo-rule-founder-progress/index.md +++ b/content/course/tech-for-non-technical-founders-2026/friday-demo-rule-founder-progress/index.md @@ -29,7 +29,7 @@ related_posts: false course_nav: false --- -> **Chapter 5.3 · Step 2 of 5** · [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) +> **Going Further · Manage a Hired Team** · [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) > > **Input:** a team in place + a signed SOW > diff --git a/content/course/tech-for-non-technical-founders-2026/friday-demo-template/index.md b/content/course/tech-for-non-technical-founders-2026/friday-demo-template/index.md index e23aca999..82889d56b 100644 --- a/content/course/tech-for-non-technical-founders-2026/friday-demo-template/index.md +++ b/content/course/tech-for-non-technical-founders-2026/friday-demo-template/index.md @@ -24,7 +24,7 @@ canonical_url: "https://jetthoughts.com/course/tech-for-non-technical-founders-2 related_posts: false --- -📋 Template companion to the Oversight Rhythm sub-section (Chapter 5.2) of the [From Idea to First Paying Customer course](/course/tech-for-non-technical-founders-2026/). Send to your team Monday. Run Friday at 4pm. +📋 Template companion to the Oversight Rhythm sub-section of [The Founder Org Chart](/course/tech-for-non-technical-founders-2026/engineering-org-chart-non-technical-founder/) (Going Further). Send to your team Monday. Run Friday at 4pm. # The Friday Demo Template diff --git a/content/course/tech-for-non-technical-founders-2026/github-aws-database-ownership-checklist/index.md b/content/course/tech-for-non-technical-founders-2026/github-aws-database-ownership-checklist/index.md index 44b2380d7..cac9ab9d3 100644 --- a/content/course/tech-for-non-technical-founders-2026/github-aws-database-ownership-checklist/index.md +++ b/content/course/tech-for-non-technical-founders-2026/github-aws-database-ownership-checklist/index.md @@ -80,7 +80,9 @@ If the contractor controls the root email, AWS support will treat them as the ac ![Side-by-side panel showing the AWS root account fields - account email, billing card, your access level, recovery time if the agency disappears - in the bad scenario where everything points at the agency, and the good scenario where everything points at the founder. The Bad column shows aws@bigdevshop.com, agency AmEx, IAM-only access, and a 3-5 day support recovery. The Good column shows aws@mycompany.com, founder AmEx, root password in 1Password with MFA, and same-day recovery by revoking the contractor.](bad-vs-good-email.svg) -**Item #7 - Production database password**> Bad: "Marcus has it. Slack him and he can DM it to you." +**Item #7 - Production database password** + +> Bad: "Marcus has it. Slack him and he can DM it to you." > Good: "I opened AWS Secrets Manager just now and read it myself. I rotated it once in March when we offboarded the previous DBA." The Marcus answer means you have a single point of failure. It does not matter whether Marcus is honest, kind, or available - one person holding the prod DB password is one person away from a production outage you cannot fix. Firing Marcus does not fix it. Putting the credential in a store you administer, with Marcus pulling read access from there, does. diff --git a/content/course/tech-for-non-technical-founders-2026/how-this-course-works/index.md b/content/course/tech-for-non-technical-founders-2026/how-this-course-works/index.md index cae6a5080..ba5feca77 100644 --- a/content/course/tech-for-non-technical-founders-2026/how-this-course-works/index.md +++ b/content/course/tech-for-non-technical-founders-2026/how-this-course-works/index.md @@ -89,7 +89,7 @@ This course takes a non-technical founder from a rough idea to a signed paid pil ### Module 3 - Design from Evidence **You have:** 10 interview transcripts + prototype feedback. **You walk away with:** a one-page Product Brief written from real customer vocabulary. -**Time:** ~3-5 days. +**Time:** ~3-5 days on the calendar - about one evening of writing plus a lunch-break quality check, with a night's sleep between drafts. | Step | What You Do | Key Tool | |---|---|---| diff --git a/content/course/tech-for-non-technical-founders-2026/module-3-walkthrough-mia/index.md b/content/course/tech-for-non-technical-founders-2026/module-3-walkthrough-mia/index.md new file mode 100644 index 000000000..c1932c8e1 --- /dev/null +++ b/content/course/tech-for-non-technical-founders-2026/module-3-walkthrough-mia/index.md @@ -0,0 +1,50 @@ +--- +title: "Module 3 Walkthrough: Mia Writes the One-Page Brief" +description: "Follow Mia through Module 3 as she turns ten scored transcripts and prototype vocabulary into a one-page Product Brief, then quality-checks it until an AI contractor prompt can't invent anything she didn't ask for." +date: 2026-07-09 +draft: false +slug: module-3-walkthrough-mia +--- + +> **Module 3 walkthrough · Mia** · [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) +> +> *Illustrative composite based on patterns from real founder builds, not a single client story. Mia's earlier runs are in the [Module 1](/course/tech-for-non-technical-founders-2026/module-1-walkthrough-mia/) and [Module 2](/course/tech-for-non-technical-founders-2026/module-2-walkthrough-mia/) walkthroughs.* + +Mia came out of Module 2 with a BUILD verdict, a one-page validated problem statement, and a sentence three parents had handed her almost verbatim: "a vetted shortlist instead of Googling." She also carried one prototype finding that still stung a little - the fifth test parent scrolling a profile page, looking for a price that wasn't there. + +Module 3 was one evening and one lunch break: draft the brief, then try to break it. + +--- + +## [Lesson 3.1: The One-Page Product Brief](/course/tech-for-non-technical-founders-2026/one-page-product-brief-vibe-prd/) + +Section 1 took ninety seconds, because the lesson forbids writing it: she copied the problem paragraph from her validated problem statement word for word - parents of kids with learning differences, 8 of 10 with real past spend, the mother who "called eleven places in March," the $600 generic-center mistake. + +Section 2 she wrote from memory of her own interviews: a parent at 9:30pm after the kids are asleep, a Facebook group thread in one tab and a search in the other, tired of opening tutor sites that all say "all subjects, all ages." Section 3 came out as one paragraph built on the parents' own words: *a web app where a parent searches by their kid's specific need, gets a short vetted list of tutor profiles - each with parent reviews, credentials, the session rate, and response time - and requests an intro call in one click.* The session rate on the profile was the prototype fail, promoted to a requirement. + +The no-go list ran longer than the build paragraph, which the lesson says is the healthy shape: no in-person coordination, no school-district partnerships, no tutor self-signup (she would onboard the first fifteen tutors by hand), no multi-child accounts, one metro area only. When she read the brief aloud to a founder friend and asked what he'd build that wasn't on the list, he said "a chat so parents can message tutors" before she finished the question. Messaging went on the no-go list; the intro call already did that job. + +Her Section 4 metric: of the first 20 parents who search, 10 request an intro call within 30 days - counted by the request event, not by signups. + +--- + +## [Lesson 3.2: Quality-check the Brief](/course/tech-for-non-technical-founders-2026/stop-specifying-features-start-outcomes/) + +Reading Section 3 out loud the next day, two phrases came out feature-shaped: the search and the tutor profiles - both named things the software has, not things a parent does. The rewrites came straight from the transcripts. *When I search for a math tutor for my 10-year-old with dyslexia, I want to filter by "dyslexia-trained" and see reviews from other parents - not scroll 50 generic math tutors.* And the one the prototype had taught her: *When I open a tutor's profile, I want the session rate next to the reviews, so I can rule out the ones outside my budget before I request a call.* + +Then she ran the contractor prompt against the brief. Claude's first answer named an availability-calendar sync, automated tutor matching, and in-app messaging. Messaging was already on her no-go list, but the other two were not - 2+ items outside the list, which the rubric counts as a fail. The gap was hers: Section 3 never said the shortlist was curated by hand in v1. She added the line "the shortlist is assembled manually by us; there is no matching algorithm in v1," put calendar sync on the no-go list (the intro call already covers scheduling), and re-ran the prompt. The second answer stayed inside her scope, and she filed the brief in her Founder OS folder next to the problem statement. + +--- + +## What Mia Walked Away With at the End of Module 3 + +- **A one-page Product Brief** with Section 1 copied verbatim from her validated problem statement - nothing softened, nothing reworded. +- **An outcome-shaped Section 3** where every line traces back to something a parent actually said in the Module 2 interviews or prototype sessions. +- **A no-go list longer than the build paragraph** - the cheapest scope-control document she will ever write. +- **A passed quality check**: one failed AI contractor run, one fix, one clean run. The fuzziness got caught on paper instead of in a Lovable build. + +**Next: [Module 4, where Mia decides who builds TutorMatch - and the brief decides with her](/course/tech-for-non-technical-founders-2026/should-you-hire-2026-decision-tree/).** + +--- + +*Built by [JetThoughts](https://jetthoughts.com) as part of the [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) free curriculum.* diff --git a/content/course/tech-for-non-technical-founders-2026/must-have-segment-pmf-test/index.md b/content/course/tech-for-non-technical-founders-2026/must-have-segment-pmf-test/index.md index 450144716..758151bad 100644 --- a/content/course/tech-for-non-technical-founders-2026/must-have-segment-pmf-test/index.md +++ b/content/course/tech-for-non-technical-founders-2026/must-have-segment-pmf-test/index.md @@ -44,7 +44,7 @@ The dashboard will tell you the same thing it would have told you if you had cal The real question after the MVP ships is whether the people who already touched it would notice if it vanished tomorrow. If less than 40% would be very disappointed, no amount of ad spend will turn that group into customers. Paid traffic does not fix a product problem; it routes more users into something they will not return to. > **What your first-pass numbers will probably look like (and that is not a failure signal).** An idea-stage founder with 4-6 onramp users typically sees one of three patterns on the first survey run: -> - All "somewhat disappointed" or "not disappointed" → directional KILL. Run more interviews before re-attempting. +> - All "somewhat disappointed" or "not disappointed" → that segment is not must-have; do not scale it. Run more interviews before re-attempting. > - 2-3 "very disappointed" out of 6 → directional MAYBE. Almost certainly a sample-size problem, not a product problem; book 5-10 more users. > - 4+ "very disappointed" out of 6 → directional YES. Advance to M5.2 with the caveat above. > @@ -171,7 +171,7 @@ Under 40% means you have a product problem, not a marketing problem, and the Q2- |---|---|---|---| | **You built for the wrong segment** | The product works, but the people you onboarded do not have the pain. Your Q5 slice shows: one segment is at 55%, the rest are at 5%. | Stop selling to the audience and start selling to the segment. | [Chapter 5.3a](/course/tech-for-non-technical-founders-2026/first-ten-customers-network-list/) personal-network outreach to the right segment. | | **You built the right thing, but it is not finished** | The Q3 verbatims are hedged ("it is nice to have," "I would use it if it had X"). The main benefit answers lack conviction. | Go back into the build and finish the thing. | Schedule a [Friday demo](/course/tech-for-non-technical-founders-2026/friday-demo-rule-founder-progress/) with the next release. | -| **The pain is real, but your product is not the relief** | The Q4 verbatims name a workaround that is already 80% of the job (a spreadsheet, an existing tool, a person they pay). | Either niche into the 20% the workaround does not cover, or pivot. | [Chapter 2.1](/course/tech-for-non-technical-founders-2026/mom-test-synthesis-build-pivot-kill/) validated-problem statement. | +| **The pain is real, but your product is not the relief** | The Q4 verbatims name a workaround that is already 80% of the job (a spreadsheet, an existing tool, a person they pay). | Either niche into the 20% the workaround does not cover, or pivot. | [Chapter 2.5](/course/tech-for-non-technical-founders-2026/mom-test-synthesis-build-pivot-kill/) validated-problem statement. | | **The product solves the pain, but the workflow is too long** | Users say "very disappointed" but session logs show they bailed before the payoff. Funnel collapses between signup and the "30-minute save" moment. | UX cut, not a strategy pivot. Shorten the path to the first win. | Retest after shortening the funnel; re-run the 40% test after the next UX release. | ## When founders should skip the test diff --git a/content/course/tech-for-non-technical-founders-2026/one-page-product-brief-vibe-prd/index.md b/content/course/tech-for-non-technical-founders-2026/one-page-product-brief-vibe-prd/index.md index 5fc8ed6ad..478d9b748 100644 --- a/content/course/tech-for-non-technical-founders-2026/one-page-product-brief-vibe-prd/index.md +++ b/content/course/tech-for-non-technical-founders-2026/one-page-product-brief-vibe-prd/index.md @@ -29,17 +29,19 @@ canonical_url: "https://jetthoughts.com/course/tech-for-non-technical-founders-2 related_posts: false --- -> **Module 3 · Step 1 of 2** · [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) +> **Module 3 · Lesson 3.1 · [CORE]** · [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) > -> **Input:** a one-page validated problem statement (from [Ch 2.5 · Mom Test Synthesis](/course/tech-for-non-technical-founders-2026/mom-test-synthesis-build-pivot-kill/), after running interviews in Ch 2.3 + 2.4) + verbatim "describe in one sentence" vocabulary (from your [Ch 2.6 prototype sessions](/course/tech-for-non-technical-founders-2026/clickable-prototype-validation-2-hour-lovable/) - Section 3 of the brief uses these exact words) +> **Input:** a one-page validated problem statement (from [Ch 2.5 · Mom Test Synthesis](/course/tech-for-non-technical-founders-2026/mom-test-synthesis-build-pivot-kill/), after running interviews in Ch 2.3 + 2.4) + verbatim "describe in one sentence" vocabulary (from your [Ch 2.6 prototype sessions](/course/tech-for-non-technical-founders-2026/clickable-prototype-validation-2-hour-lovable/)) > -> **Output:** a one-page Product Brief (Vibe PRD) you can hand to Lovable or a hired team +> **Output:** a one-page Product Brief (Vibe PRD) you can hand to [Lovable](https://lovable.dev) (an AI app builder that turns a plain-English prompt into a working web app) or a hired team +> +> **Progress:** M3 · 1 of 2 · Results so far: a validated problem statement (2.5) + a prototype pass/fail with user vocabulary (2.6) - this page turns them into the one page Module 4 builds from > **TL;DR:** One page, five sections. The problem (verbatim from interviews), the user's 60-second context, the one workflow, the one metric, and what you're NOT building. Hand it to Lovable or a contractor tomorrow morning. -Sarah, an EdTech founder we audited in Q2 2026, had 17 settings toggles in her admin UI. In a one-day spec review we found 12 had no backend code and 2 crashed on toggle. The Vibe PRD she wrote next listed 5 settings she actually needed. Everything else came out. That is what a one-page brief does to a build that has drifted - it forces every line to earn its place tomorrow morning. +Sarah, an EdTech founder we audited in Q2 2026, had 17 settings toggles in her admin UI - 12 had no backend code and 2 crashed on toggle. The Vibe PRD she wrote next listed the 5 settings she actually needed, and everything else came out. That is what a one-page brief does to a build that has drifted: it forces every line to earn its place. -This chapter walks you through the **Product Brief** - some founders call it a **Vibe PRD** (PRD stands for Product Requirements Document). It is a single page that names the user, the problem, the one workflow you are building, the one metric you will measure, and what you are explicitly NOT building. The five sections below are the same ones Drew Falkman teaches in a 4-week Maven cohort for $1,000; this chapter walks you through the template so you can fill yours in tonight. +This chapter walks you through the **Product Brief** - some founders call it a **Vibe PRD** (PRD stands for Product Requirements Document). It is a single page that names the user, the problem, the one workflow you are building, the one metric you will measure, and what you are explicitly NOT building. The five sections below are the same ones Drew Falkman teaches in a paid multi-week Maven cohort; this chapter walks you through the template so you can fill yours in tonight. ![One-page Vibe PRD template with five labeled sections: the problem, the user and their context, what you're building, success metric, what you're NOT building.](vibe-prd-template-visual.svg) @@ -60,9 +62,9 @@ The simplest reliable order is *problem → user → build → metric → no-go* > **How long is each section?** Each of the 5 sections is 2-4 sentences in plain English. Section 5 (no-go list) is 5-8 bullet lines. Total brief ≤ 250 words on one side of A4 at 11pt. If you spill past 250 words, the persona is too broad or the pain is too vague - revise the section that ran longest first. -### Section 1 - The problem (lifted from Chapter 2.1 synthesis) +### Section 1 - The problem (lifted from your Chapter 2.5 synthesis) -What goes in it: one paragraph copied directly from your [validated problem statement](/course/tech-for-non-technical-founders-2026/mom-test-synthesis-build-pivot-kill/). Named persona, named industry, dated 10-call sample, one verbatim quote, one quantified cost. +What goes in it: one paragraph copied directly from your [validated problem statement](/course/tech-for-non-technical-founders-2026/mom-test-synthesis-build-pivot-kill/). Named persona, named industry, dated 10-call sample, one verbatim quote, one quantified cost, and the one-line why-now from your problem statement. Example: *Pre-seed B2B SaaS founders doing their own Stripe-to-QuickBooks reconciliation lose 6 hours per week and $800 per month in CFO contractor time. 8 of 10 interviewees confirmed (May 2026 sample). One founder said: "Tuesday at 9pm I spent 40 minutes copying Stripe payouts into QuickBooks. I called my CFO. She did it in 90 seconds."* @@ -74,13 +76,13 @@ What goes in it: who the user is *while* they're using your product. Not the per Example: *A pre-seed founder, alone in their browser at 9pm on a Tuesday, finishing the week's bookkeeping. They have a Stripe dashboard open in one tab and a QuickBooks ledger in another. They are tired, mildly annoyed, looking for a way to finish in 10 minutes instead of 40. They will open our app from a bookmark, paste one Stripe export, and close the tab when the numbers line up.* -Common mistake: writing the persona's company size, ARR (annual recurring revenue), and tech stack as if pitching to investors. The agent or contractor doesn't need their TAM (Total Addressable Market - how big the whole market is in dollars; investor-pitch math, not builder math). They need to know the user is tired, has two tabs open, and wants to be done. Specific context produces a usable interface; abstract persona data produces a dashboard with seventeen filters nobody uses. +Common mistake: writing the persona's company size, ARR (annual recurring revenue), and tech stack as if pitching to investors. The agent or contractor doesn't need their TAM (Total Addressable Market - how big the whole market is in dollars; investor-pitch math, not builder math). They need to know the user is tired, has two tabs open, and wants to be done. Specific context produces a usable interface; abstract persona data produces a dashboard full of filters nobody uses. ### Section 3 - What you're building (one paragraph, plain English) What goes in it: one paragraph that names the smallest end-to-end thing a user can do. Verb-led. Mentions the inputs the user provides and the output they get back. No feature list, no tech stack instructions, no mention of microservices or auth strategies. -Example: *A web app where the founder pastes a Stripe payout CSV and the app returns a QuickBooks-compatible journal entry CSV they can import in one click. The first version supports USD only, one Stripe account per user, and no multi-currency. The user authenticates with email + magic link. We never store the CSV after the conversion completes.* +Example: *A web app where the founder pastes a Stripe payout CSV (a plain spreadsheet-style file exported from Stripe) and the app returns a QuickBooks-compatible journal entry CSV they can import in one click. The first version supports USD only, one Stripe account per user, and no multi-currency. The user authenticates with email + magic link (they type their email and click a one-time sign-in link - no password to build or store). We never store the CSV after the conversion completes.* Common mistake: writing this in feature-list form ("Stripe integration · QuickBooks export · user dashboard · settings page"). The agent reads the feature list and produces a settings page nobody asked for and an integration that breaks in the first edge case. One paragraph forces you to name the thing the user *does*, not the menu items the engineer might build. @@ -90,7 +92,7 @@ What goes in it: one number, with a unit, that tells you whether the build worke Example: *Of the first 20 users who land on the app, 10 successfully convert at least one Stripe export to a QuickBooks journal entry within 30 days of signup. Below that, the persona is wrong or the workflow is wrong. The metric is the conversion-completed event in our analytics, not signups.* -Common mistake: listing three metrics (signups, retention, NPS) instead of one. Three metrics let you cherry-pick whichever one looks best. One metric forces a build/no-build decision in 30 days. The [pre-PMF founder rule](/blog/sales-pre-pmf-should-be-done-by-founders/) applies: one number, measured by you, defended in front of one advisor. +Common mistake: listing three metrics (signups, retention, a satisfaction score) instead of one. Three metrics let you cherry-pick whichever one looks best. One metric forces a build/no-build decision in 30 days. The [pre-PMF founder rule](/blog/sales-pre-pmf-should-be-done-by-founders/) applies: one number, measured by you, defended in front of one advisor. ### Section 5 - What you're NOT building (the no-go list) @@ -98,7 +100,7 @@ What goes in it: 5 to 8 lines naming the things a competent agent or contractor Example: *Not in v1: multi-currency support, multi-Stripe-account support, automatic recurring sync, a settings page, a billing dashboard, user roles and permissions, a marketing site beyond the signup page, mobile responsive design beyond "works on a 1024px screen." We will revisit each of these after metric in Section 4 is hit.* -Common mistake: leaving this section blank because "we'll just say what we want and skip what we don't." Lovable, [Cursor](https://cursor.com), and a hired junior all fill blanks with reasonable defaults, and reasonable defaults stack into a settings page nobody asked for. The same shape produced Sarah's 17 toggles (12 wired to nothing) at the top of this chapter. +Common mistake: leaving this section blank because "we'll just say what we want and skip what we don't." Lovable, [Cursor](https://cursor.com) (an AI coding tool developers run on their own machines), and a hired junior all fill blanks with reasonable defaults, and reasonable defaults stack into a settings page nobody asked for. The same shape produced Sarah's 17 toggles (12 wired to nothing) at the top of this chapter. ![Side by side bad vs good Vibe PRD. Left: bad brief reads 'Build a CRM.' Right: good brief names the persona, the 60-second context, the one workflow, the one metric, and the no-go list.](good-vs-bad-prd.svg) @@ -109,15 +111,15 @@ Not every brief is a Vibe PRD. The audience tells you which to write. ```mermaid %%{init: {'theme':'base', 'themeVariables': {'fontFamily':'Caveat, Patrick Hand, cursive', 'primaryColor':'#fff5f5', 'primaryBorderColor':'#cc342d', 'lineColor':'#333', 'primaryTextColor':'#1a1a1a'}}}%% flowchart TD - Start(["One-page Product Brief written.
Where does it go next?"]) - Start --> Q1{Who reads it
and builds from it?} - Q1 -->|Lovable / Cursor / AI agent| Vibe1[Vibe PRD
Hand the page as-is.
Paste into prompt.] - Q1 -->|Hired junior contractor| Vibe2[Vibe PRD
Hand the page +
short kickoff call.] - Q1 -->|Hired senior engineer| Trad1[Traditional PRD
Expand to 3-5 pages.
Add API + data model.] - Q1 -->|Product committee / board| Trad2[Traditional PRD
Expand to 5-10 pages.
Add roadmap + budget.] - Vibe1 --> Ship1[Short build loop.
Measure Section 4.] + Start(["Brief written"]) + Start --> Q1{Who builds
from it?} + Q1 -->|AI agent| Vibe1[Vibe PRD
hand as-is] + Q1 -->|Hired junior| Vibe2[Vibe PRD
+ kickoff call] + Q1 -->|Senior engineer| Trad1[Traditional PRD
3-5 pages] + Q1 -->|Committee / board| Trad2[Traditional PRD
5-10 pages] + Vibe1 --> Ship1[Short build loop] Vibe2 --> Ship1 - Trad1 --> Ship2[Long build loop.
Kickoff, sprints, demos.] + Trad1 --> Ship2[Long build loop] Trad2 --> Ship2 classDef start fill:#e8f4f8,stroke:#0277bd,stroke-width:2.5px,color:#1a1a1a @@ -137,20 +139,20 @@ flowchart TD **Traditional PRD if** the next stop is a senior engineering team, an in-house product committee, or a board that needs a budget number attached. Senior engineers read briefs to find load-bearing assumptions you haven't named, and they expect a data model, an API outline, and an integration list. Product committees expect a roadmap, a phasing plan, and a go-to-market section. Both audiences will write the missing parts themselves if you don't include them, which is rarely what you want. -The trap most founders fall into is writing a traditional PRD for a junior or an AI agent. The 5-page document buries the one paragraph the builder needed. By page 3, the agent has skimmed past the no-go list and started building a settings page. +The classic trap is writing a traditional PRD for a junior or an AI agent. The 5-page document buries the one paragraph the builder needed. By page 3, the agent has skimmed past the no-go list and started building a settings page. -## When the $1,000 Maven course is worth it +## When a paid cohort course is worth it -Drew Falkman runs ["Vibe Coding Data-Enabled AI Apps" on Maven](https://maven.com/), a 4-week cohort priced at $1,000. The course teaches the same five-section Vibe PRD template, plus the Lovable + Supabase + Stripe + GitHub stack, plus live community and 1:1 instructor feedback. The Maven [course reviews](https://maven.com/p/about) hover around 4.8/5. +Drew Falkman runs ["Vibe Coding Data-Enabled AI Apps" on Maven](https://maven.com/), a multi-week live cohort (paid - check the course page for current pricing and format). The course teaches the same five-section Vibe PRD template, plus the Lovable + Supabase + Stripe + GitHub stack, plus live community and 1:1 instructor feedback. | Scenario | Maven cohort is worth it | This template is enough to start | |---|---|---| | You wrote the page tonight and can't tell whether it is good. | Yes. Go for peer review + feedback. | Actually, post the draft in a founder Slack - free feedback in 2 hours. | | Accountability is your blocker. (3 abandoned briefs in a drawer.) | Yes. The cohort structure + deadline forces you through. | No. You need external structure. The template alone won't help. | -| You want to go deeper on Lovable + Supabase + Stripe stack mechanics. | Yes. The cohort spends 2 of 4 weeks on this. | No. You'll need the stack tutorials anyway; the template is concept-only. | -| You can sit alone for 2 hours and finish the brief from the page above. | No. | Yes. The cohort buys peer review + deadline + deeper stack work, but you'll ship either way. | +| You want to go deeper on Lovable + Supabase + Stripe stack mechanics. | Yes. The cohort spends much of its time on exactly this. | No. You'll need the stack tutorials anyway; the template is concept-only. | +| You can sit alone for 90 minutes and finish the brief from the page above. | No. | Yes. The cohort buys peer review + deadline + deeper stack work, but you'll ship either way. | -**Rule of thumb:** If you can sit alone for two hours and finish the brief, start here. The cohort buys structure, deadline, and stack depth. If you can't sit alone, $1,000 buys the accountability that gets the brief out of you. +**Rule of thumb:** If you can sit alone for 90 minutes and finish the brief, start here. The cohort buys structure, deadline, and stack depth. If you can't sit alone, the cohort fee buys the accountability that gets the brief out of you. ## What to do tomorrow @@ -166,7 +168,7 @@ Skipping the brief and going straight into prompting is the most common way a no ## What comes next (Chapter 3.2, then Chapter 4.1) -You now have two validated artifacts: a one-page problem statement (from Chapter 2.1 synthesis) and a one-page Vibe PRD (from this chapter). Two more steps before Lovable touches your brief: +You now have two validated artifacts: a one-page problem statement (from your Chapter 2.5 synthesis) and a one-page Vibe PRD (from this chapter). Two more steps before Lovable touches your brief: 1. **[Chapter 3.2 - Quality-check your brief: features to outcomes](/course/tech-for-non-technical-founders-2026/stop-specifying-features-start-outcomes/)** - stress-test Section 3 ("what you're building") by rewriting feature nouns as outcome-shaped job stories. This is the quality gate on the brief you just wrote, not a separate writing exercise. 2. **[Chapter 4.1 - Should You Hire? The 2026 Decision Tree](/course/tech-for-non-technical-founders-2026/should-you-hire-2026-decision-tree/)** - a 5-question decision tree that routes you to one of 4 build paths (validate without code / self-serve / fractional CTO / hire). The default for a non-technical founder is self-serve ([Chapter 4.3a · Stack](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-lovable-supabase-stripe-2026/) + [4.3b · Build Phases](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-build-phases/)), but only after the decision gate confirms it's right for YOUR runway and YOUR problem. Chapter 4.1 explicitly requires the outcome-shaped brief from Chapter 3.2 as its input. @@ -175,7 +177,7 @@ A Vibe PRD is what's left when you remove everything an AI agent or a hired juni ## Further reading -- Drew Falkman, [Vibe Coding Data-Enabled AI Apps on Maven](https://maven.com/) - the $1,000, 4-week cohort that teaches the Vibe PRD with live feedback. Recommended if accountability is your blocker. +- Drew Falkman, [Vibe Coding Data-Enabled AI Apps on Maven](https://maven.com/) - the paid live cohort that teaches the Vibe PRD with instructor feedback. Recommended if accountability is your blocker. - Marty Cagan, [Good Product Manager / Bad Product Manager](https://www.svpg.com/good-product-manager-bad-product-manager/) - the canonical essay on what a PRD is for. The Vibe PRD is the AI-era compression of the same shape. - Marty Cagan, [Product vs Feature Teams](https://www.svpg.com/product-vs-feature-teams/) - why the brief shapes what gets built. The no-go list is the part feature teams ignore. - Jake Knapp and John Zeratsky, [Foundation Sprint (Click, April 2025)](https://www.thesprintbook.com/foundation-sprint) - the 2-day version of the same artifact for teams that have 2 days. The Foundation Sprint workbook is freely sampled from the book site. @@ -183,17 +185,15 @@ A Vibe PRD is what's left when you remove everything an AI agent or a hired juni - Veracode, [GenAI Code Security Report 2025](https://www.veracode.com/blog/genai-code-security-report/) - the 45% LLM-generated-code-flaw stat. Context for why the no-go list matters. - Y Combinator, [How to Write a PRD (Startup Library)](https://www.ycombinator.com/library/) - YC's distilled version of the same compression. -> **Done when:** All 5 sections of your one-page brief are filled in, Section 1 is copied verbatim from your validated problem statement, and you have read the brief aloud to one peer. -> **Founder OS · Artifact #4 of 6:** The one-page Product Brief (Vibe PRD). Save as `Product Brief - [date]` in your `Founder OS` folder. Module 4.1 reads the brief to decide your build path; Module 4.3 reads it to prompt Lovable. -> **Next click:** [3.2 · Quality-check your brief: features to outcomes](/course/tech-for-non-technical-founders-2026/stop-specifying-features-start-outcomes/) -> **If blocked:** If you can't fill Section 3 (what you're building) in one paragraph, your scope is too big. Pick the single smallest workflow one persona can complete end-to-end and cut everything else to the no-go list. - -> **Case Study: Tomas & Mia** +> **Done:** all 5 sections of your one-page brief are filled in, Section 1 is copied verbatim from your validated problem statement, and you have read the brief aloud to one peer. > -> **Tomas**: Drafts a 1-page brief that passes the quality gate. Core 3 jobs: (1) auto-match Stripe to QuickBooks, (2) flag the 5% exceptions needing a human, (3) generate a reconciliation report. Out of scope: no ERP integrations, no multi-currency - just matching. +> **You have now:** a validated problem statement (2.5) + prototype vocabulary (2.6) + the one-page Product Brief (Vibe PRD). Save it as `Product Brief - [date]` in your `Founder OS` folder - Chapter 4.1 reads it to decide your build path, and Chapter 4.3 reads it to prompt Lovable. > -> **Mia**: Drafts a 1-page brief that passes the quality gate. Core 3 jobs: (1) search tutors by specialty + location, (2) read parent reviews before booking, (3) book + pay in one flow. Out of scope: no in-person coordination, no school district partnerships. +> **Next:** [3.2 · Quality-check your brief: features to outcomes](/course/tech-for-non-technical-founders-2026/stop-specifying-features-start-outcomes/) - the quality gate on the brief you just wrote. +> **If blocked:** If you can't fill Section 3 (what you're building) in one paragraph, your scope is too big. Pick the single smallest workflow one persona can complete end-to-end and cut everything else to the no-go list. --- +*See it in action: [Module 3 walkthrough: Mia writes the one-page brief](/course/tech-for-non-technical-founders-2026/module-3-walkthrough-mia/)* + *Built by [JetThoughts](https://jetthoughts.com) as part of the [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) curriculum.* diff --git a/content/course/tech-for-non-technical-founders-2026/one-page-product-brief-vibe-prd/vibe-prd-template-visual.svg b/content/course/tech-for-non-technical-founders-2026/one-page-product-brief-vibe-prd/vibe-prd-template-visual.svg index 065b0f171..0e7726c36 100644 --- a/content/course/tech-for-non-technical-founders-2026/one-page-product-brief-vibe-prd/vibe-prd-template-visual.svg +++ b/content/course/tech-for-non-technical-founders-2026/one-page-product-brief-vibe-prd/vibe-prd-template-visual.svg @@ -1,4 +1,4 @@ - + One-page Vibe PRD - 5 sections on a notebook page A clean notebook page divided into five fillable blocks. Section 1 copies the validated problem statement verbatim. Section 2 names the user, where they are, and the 60 seconds around using the product. Section 3 describes what is being built in one paragraph of plain English. Section 4 names one success metric with a number and a timeframe. Section 5 lists what is NOT being built in v1. @@ -28,13 +28,13 @@ Vibe PRD - One-Page Product Brief - Fill in 45 minutes after the validated problem statement. Hand to Lovable, Cursor, or a hired junior. + One 90-minute sitting. Hand to Lovable, Cursor, or a hired junior. 1. - The problem (copy from Chapter 2.1) + The problem (copy from Chapter 2.5) Persona + industry + dated sample + verbatim quote + cost. _______________________________________________________ _______________________________________________________ @@ -48,7 +48,7 @@ Who they are while using your product: __________________ 60 seconds before reaching for it: ______________________ 60 seconds after they close it: _________________________ - e.g., "Founder alone at 9pm, Stripe + QuickBooks tabs open, wants to be done in 10 min." + e.g., "Founder alone at 9pm, two finance tabs open, wants done in 10 min." @@ -58,7 +58,7 @@ Smallest end-to-end thing the user can do: ______________ Inputs they provide + output they get back: _____________ What v1 explicitly supports (scope of done): ____________ - e.g., "Paste Stripe CSV. Get QuickBooks journal entry CSV. USD only. Magic-link auth." + e.g., "Paste Stripe CSV. Get QuickBooks CSV back. USD only. Magic-link auth." @@ -67,7 +67,7 @@ Success metric (one number) Number + unit + timeframe: ______________________________ How it's measured (event name, not gut feel): ___________ - e.g., "10 of first 20 signups convert at least 1 file within 30 days. Event: conversion_completed." + e.g., "10 of first 20 signups convert in 30 days. Event: conversion_completed." diff --git a/content/course/tech-for-non-technical-founders-2026/outbound-without-sales-team/index.md b/content/course/tech-for-non-technical-founders-2026/outbound-without-sales-team/index.md index d94338e0a..c02fcae0b 100644 --- a/content/course/tech-for-non-technical-founders-2026/outbound-without-sales-team/index.md +++ b/content/course/tech-for-non-technical-founders-2026/outbound-without-sales-team/index.md @@ -43,7 +43,7 @@ related_posts: false > > Reading this chapter before your network is dry is the most common sequencing mistake founders make in Module 5 - it feels like progress, but you are skipping the higher-converting path for the lower one. The chapter will still be here when your network is done. -> **$0 outbound stack.** Apollo's free tier (credit-based: roughly 100 email credits + 10 export credits per month) + a Google Sheet + Gmail mail-merge add-on (free) + Loom free + Calendly free covers the entire pipeline at zero monthly cost. You ship the same 30-message batch, you just enrich the list manually in a sheet instead of automating it through Smartlead. Upgrade to Apollo Pro ($49) or Smartlead ($39 Base plan) only when you're sending 100+ messages a week and the manual enrichment is the bottleneck. +> **$0 outbound stack.** Apollo's free tier (credit-based - check the current allowance) + a Google Sheet + Gmail mail-merge add-on (free) + Loom free + Calendly free covers the entire pipeline at zero monthly cost. You ship the same 30-message batch, you just enrich the list manually in a sheet instead of automating it through Smartlead. Upgrade to Apollo's or Smartlead's paid tiers only when you're sending 100+ messages a week and the manual enrichment is the bottleneck. This chapter is sales outbound asking buyers for money, which is a different motion from the interview-recruitment outreach in [Chapter 2.4](/course/tech-for-non-technical-founders-2026/find-10-people-with-problem-outreach-2026/) where you were asking for 30 minutes of their time. @@ -53,7 +53,7 @@ The one difference is that those Module 2 interviewees are warm targets - they a Product Hunt converted at 3.1% per launch event across 387 launches OpenHunts studied in 2024. Indie Hackers - posts written as engagement rather than launch announcements - converted at 23.1% per engaged post over the same period. -89% of the Product Hunt founders OpenHunts surveyed said they would not launch on the platform again ([source](https://awesome-directories.com/blog/indie-hackers-launch-strategy-guide-2025/)). The data has been public since the OpenHunts study released in mid-2024, yet every "first 10 customers" article still leads with Product Hunt. +89% of the Product Hunt founders OpenHunts surveyed said they would not launch on the platform again ([OpenHunts launch statistics](https://openhunts.com/blog/tech-product-launch-statistics-insights)). The data has been public since the OpenHunts study released in mid-2024, yet every "first 10 customers" article still leads with Product Hunt. Product Hunt is not bad; it is a one-day event in a job that needs sustained motion over a quarter. @@ -92,9 +92,9 @@ The five tools and their 2026 pricing: | Tool | Role | Price | |---|---|---| -| LinkedIn Sales Navigator | Filter buyers by title, company size, funding signal, role tenure | $99/month single-user (Core tier) | -| Apollo.io (Starter / free tier) | Cheaper alternative to Sales Nav for B2B email + filters | Free tier available; paid Apollo Pro starts ~$49/mo | -| Loom | 90s product walkthrough + you on camera | Free tier: 25 videos | +| LinkedIn Sales Navigator | Filter buyers by title, company size, funding signal, role tenure | Paid single-user plans - check LinkedIn pricing | +| Apollo.io (Starter / free tier) | Cheaper alternative to Sales Nav for B2B email + filters | Free tier available; paid plans for scale | +| Loom | 90s product walkthrough + you on camera | Free tier available | | Calendly | 15-min demo booking, auto-confirm | Free tier supports one event type | | Stripe Invoice | Pilot deposit, no monthly fee | 2.9% + 30c per transaction | @@ -137,7 +137,7 @@ Pull 100-150 raw rows. Strip three categories before sending: You should be left with 30-50 clean names. Hold the bottom 20 for a later batch and send the top 30 in the first batch. -> **Apollo free-tier reality.** Apollo's free tier is credit-based (~100 email credits + ~10 EXPORT credits per month). The "pull 100-150 raw rows" instruction is achievable on the free tier only if you spread it across 10+ months OR use LinkedIn DM for batch 1 and reserve Apollo exports for batch 2+. Recommended sequence for free-tier founders: (1) build batch 1 from your existing LinkedIn 1st-degree connections + Sales Navigator trial (free for 1 month, no Apollo needed); (2) start Apollo on month 2 with the credits dripping in over time; (3) upgrade to Apollo Pro ($49/mo) only when you have a working reply-rate signal that justifies the spend. +> **Apollo free-tier reality.** Apollo's free tier is credit-based (a small monthly allowance of email and export credits). The "pull 100-150 raw rows" instruction usually exceeds one month of free credits, so either spread it over time OR use LinkedIn DM for batch 1 and reserve Apollo exports for batch 2+. Recommended sequence for free-tier founders: (1) build batch 1 from your existing LinkedIn 1st-degree connections + Sales Navigator trial (free for 1 month, no Apollo needed); (2) start Apollo on month 2 with the credits dripping in over time; (3) upgrade to a paid Apollo tier only when you have a working reply-rate signal that justifies the spend. ### Personalize: 60-90 seconds per name, not 10 minutes @@ -209,7 +209,7 @@ flowchart TB class W3,W7 conv; ``` -Expect a 10-20% reply rate on a properly filtered, properly personalized 30-message batch. That is 3-6 replies, of which 2-4 will agree to a 15-minute demo. Of the demos, 1-2 will agree to a paid pilot. Of the pilots, the [Chapter 5.4](/course/tech-for-non-technical-founders-2026/paid-pilot-charge-before-ship/) deposit-to-year-one conversion math holds - around 60% of paid pilots convert to year-one customers. +Expect a 10-20% reply rate on a properly filtered, properly personalized 30-message batch. That is 3-6 replies, of which 2-4 will agree to a 15-minute demo. Of the demos, 1-2 will agree to a paid pilot. Of the pilots, the [Chapter 5.4](/course/tech-for-non-technical-founders-2026/paid-pilot-charge-before-ship/) deposit-to-year-one conversion math holds. The 30-message batch is not a one-time event. Run fresh 30-message batches until you have 20 customers. The second and third batches will outperform the first by 30-50% because you will have learned which reference patterns earn replies and which do not. @@ -277,7 +277,7 @@ Module 5 closes with a deposit in your Stripe account. Everything from here is k ## Further reading -- OpenHunts (via Awesome Directories), [Indie Hackers Launch Strategy Guide 2025](https://awesome-directories.com/blog/indie-hackers-launch-strategy-guide-2025/) - source for the Product Hunt 3.1% vs Indie Hackers 23.1% per-engaged-post conversion data from the 387-launch 2024 study. +- OpenHunts, [Product Launch Statistics: Success Rates & Data](https://openhunts.com/blog/tech-product-launch-statistics-insights) - the primary source for the Product Hunt 3.1% vs Indie Hackers 23.1% per-engaged-post conversion data (387-launch 2024 study, 156 founders surveyed). - Lenny Rachitsky, [How to win your first 10 B2B customers](https://www.lennysnewsletter.com/p/how-to-win-your-first-10-b2b-customers) - the 7-step playbook from 100+ B2B founders, including the cold-outbound section. - First Round Capital, [Cold Outreach That Works: A Founder Playbook](https://review.firstround.com/from-1-to-1000-users-tactics-from-airbnb-tinder-etsy-reddit-and-more/) - tactical cold-outreach scripts from Airbnb, Tinder, Etsy, Reddit founder interviews. - Paul Graham, [Do Things That Don't Scale](http://paulgraham.com/ds.html) - the foundational text on manual customer recruitment, including the Stripe Collison-brothers cold-DM-and-install motion. diff --git a/content/course/tech-for-non-technical-founders-2026/paid-pilot-charge-before-ship/index.md b/content/course/tech-for-non-technical-founders-2026/paid-pilot-charge-before-ship/index.md index 8ec03f81a..0f99af79d 100644 --- a/content/course/tech-for-non-technical-founders-2026/paid-pilot-charge-before-ship/index.md +++ b/content/course/tech-for-non-technical-founders-2026/paid-pilot-charge-before-ship/index.md @@ -41,7 +41,7 @@ Two pilots, same product, same buyer profile, different deposit timing: | Variant | Setup | Result at Week 8 | |---|---|---| -| **Free pilot** | Six weeks of free build, customer "loves it," 47 enthusiastic Slack messages, year-one contract sent on day pilot ended | "We're going to revisit at the next budget cycle." There is no next budget cycle. | +| **Free pilot** | Six weeks of free build, customer "loves it," a wall of enthusiastic Slack messages, year-one contract sent on day pilot ended | "We're going to revisit at the next budget cycle." There is no next budget cycle. | | **Paid pilot** | One-page Design Partner Agreement, $1,200 refundable deposit collected before any code ships | Year-one contract closes day one. | The playbook below is the second variant: a one-page Design Partner Agreement, a 15-minute Stripe Checkout setup, and the pricing math that puts you in the conversation instead of stuck waiting for a CFO who never approved the pilot. @@ -171,7 +171,7 @@ Two annotated worked examples (a $1,500 B2B SaaS pilot and a $5,000 B2B services The deposit number is not arbitrary. It is anchored to projected year-one ACV and to what a typical CFO will sign without a procurement review. The bands by sector: -> For Sam's first pilot, the per-seat / 5-10 seats row applies. Skip the mid-market row until you have 5+ customers. +> For your first pilot, the per-seat / 5-10 seats row applies. Skip the mid-market row until you have 5+ customers. | Sector | Year-1 ACV | Pilot fee (10-30%) | Pilot fee notes | |---|---|---|---| @@ -316,7 +316,7 @@ A 20% deposit at kickoff puts the CFO question on Week 0. Conversion in Week 7 b > > **If blocked:** If the customer says "can we start free and convert later," reframe: the deposit is year-one ACV prepaid, not added cost. If they still say no, they are not in your must-have segment - move to the next lead. -> **Stuck? Most first-timers stall here:** asking for money from someone you know, even as a refundable deposit. **Fix:** the deposit is a test of whether the problem is real - not a test of whether you deserve to be paid. If they value the solved problem less than the deposit, their problem isn't acute enough. Send the DPA to your warmest lead first. The second one is easier. +> **Stuck here?** Asking for money from someone you know is the stall point, even as a refundable deposit. **Fix:** the deposit is a test of whether the problem is real - not a test of whether you deserve to be paid. If they value the solved problem less than the deposit, their problem isn't acute enough. Send the DPA to your warmest lead first. The second one is easier. > **Case Study: Tomas & Mia** > diff --git a/content/course/tech-for-non-technical-founders-2026/pivot-or-persevere-decision-framework/pivot-ledger.svg b/content/course/tech-for-non-technical-founders-2026/pivot-or-persevere-decision-framework/pivot-ledger.svg index 52d20a8ac..3f4db2cbf 100644 --- a/content/course/tech-for-non-technical-founders-2026/pivot-or-persevere-decision-framework/pivot-ledger.svg +++ b/content/course/tech-for-non-technical-founders-2026/pivot-or-persevere-decision-framework/pivot-ledger.svg @@ -39,7 +39,7 @@ Validated problem (survived) - Chapter 2.1 + Chapter 2.5 YES Carry forward as anchor diff --git a/content/course/tech-for-non-technical-founders-2026/quickstart/index.md b/content/course/tech-for-non-technical-founders-2026/quickstart/index.md index b8347102d..1caa1ab4a 100644 --- a/content/course/tech-for-non-technical-founders-2026/quickstart/index.md +++ b/content/course/tech-for-non-technical-founders-2026/quickstart/index.md @@ -51,7 +51,7 @@ Skip the lessons marked "optional" on the [course landing page](/course/tech-for ### Module 2 - Validate the Problem *Output: 10 Mom Test interviews + clickable prototype tested with 5 people.* -- [**2.1** · The Mom Test: Ask About the Past](/course/tech-for-non-technical-founders-2026/mom-test-ask-about-past-not-future/) +- [**2.1** · The Mom Test: Ask About the Past](/course/tech-for-non-technical-founders-2026/mom-test-ask-about-past-not-future/) *(2.2, the optional AI interview rehearsal, is skip-safe on this fast path)* - [**2.3** · Find 10 People: Where to Look](/course/tech-for-non-technical-founders-2026/find-10-people-where-to-look/) - [**2.4** · Find 10 People: What to Say](/course/tech-for-non-technical-founders-2026/find-10-people-with-problem-outreach-2026/) - [**2.5** · Mom Test Synthesis: Build, Pivot, or Kill](/course/tech-for-non-technical-founders-2026/mom-test-synthesis-build-pivot-kill/) diff --git a/content/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-build-phases/index.md b/content/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-build-phases/index.md index 01f51c849..f7264f114 100644 --- a/content/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-build-phases/index.md +++ b/content/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-build-phases/index.md @@ -82,7 +82,7 @@ In Lovable, install the Supabase integration. Lovable will add the Supabase JS c > **Self-test your RLS policy before going live (two paths).** > -> *No-code path (default for Sam).* In Claude or ChatGPT, paste: *"Audit my Supabase RLS policy. Here is my schema: [paste your table definitions from Supabase Table Editor]. Here is my current RLS policy: [paste from Authentication -> Policies]. Tell me whether a logged-in user with a fake user-id can read rows that belong to other users. If yes, give me the exact policy SQL to fix it."* Paste the AI's suggested policy into Supabase Authentication -> Policies. +> *No-code path (the default for a non-technical founder).* In Claude or ChatGPT, paste: *"Audit my Supabase RLS policy. Here is my schema: [paste your table definitions from Supabase Table Editor]. Here is my current RLS policy: [paste from Authentication -> Policies]. Tell me whether a logged-in user with a fake user-id can read rows that belong to other users. If yes, give me the exact policy SQL to fix it."* Paste the AI's suggested policy into Supabase Authentication -> Policies. > > *SQL path (only if you are comfortable writing SQL).* In Supabase Dashboard -> SQL Editor, paste the test below, replacing `` with your main user-data table. The pretend user-id `999` has no real rows; if the query returns any, your policy has a hole. > @@ -105,7 +105,7 @@ Spend the rest of the phase running $1 test transactions through the flow: signu ### Phase 4 - deploy, send to 5 ICP users, iterate from the data -Switch Stripe out of test mode. Buy a domain (~$10/year on [Porkbun](https://porkbun.com/) - .com registration is $9.73 first year, $10.91 renewal as of 2026 - or your registrar of choice; never let a tool hold your domain). Point the domain at the Lovable staging URL. Take final screenshots, write a 3-line cold email or LinkedIn DM, and send to 5 ICP prospects from your [Module 2 outreach list](/course/tech-for-non-technical-founders-2026/outreach-sequence-template/). +Switch Stripe out of test mode. Buy a domain (roughly $10/year for a .com on [Porkbun](https://porkbun.com/) or your registrar of choice; never let a tool hold your domain). Point the domain at the Lovable staging URL. Take final screenshots, write a 3-line cold email or LinkedIn DM, and send to 5 ICP prospects from your [Module 2 outreach list](/course/tech-for-non-technical-founders-2026/outreach-sequence-template/). > "Hey [name] - the workflow you described recently (logging client check-ins by hand on a spreadsheet) is now a tool. Quick first-use, $29/month after a trial window. URL: [staging URL]. Honest reactions only." @@ -163,8 +163,8 @@ What the stack actually costs, per published vendor pricing: | Phase | Cost shape | Line items | |------|-------|-----------| | Start | Free tiers | Free tiers across Lovable, Supabase, Stripe, GitHub | -| First ship | Per-tool monthly fees | Lovable Pro $25 + Supabase Pro $25 + Porkbun .com ~$10/yr + Resend $20 + Stripe 2.9% + $0.30 per transaction | -| Post-launch | Scale-tier monthly fees | Lovable Scale $100 + Supabase Pro $25 + Resend $35 + Sentry $26 + monitoring $14 | +| First ship | Per-tool monthly fees | Lovable + Supabase entry paid tiers + a .com domain (~$10/yr) + Resend entry tier + Stripe per-transaction fees | +| Post-launch | Scale-tier monthly fees | Lovable scale tier + Supabase paid tier + Resend/Sentry/monitoring paid tiers - check vendor pricing pages | The architectural ceiling tends to land at the post-launch tier - at ~10K users, route to Chapter 4.4 or a [Fractional CTO](/course/tech-for-non-technical-founders-2026/hire-track-supplementary-reference/#the-fractional-cto-bridge). A hire-a-team build is material monthly burn before revenue; this stack ships the same first 10 paying customers on a fraction of that. diff --git a/content/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-lovable-supabase-stripe-2026/index.md b/content/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-lovable-supabase-stripe-2026/index.md index 3464ccf34..34f4dc5d5 100644 --- a/content/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-lovable-supabase-stripe-2026/index.md +++ b/content/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-lovable-supabase-stripe-2026/index.md @@ -52,8 +52,8 @@ The stack, top to bottom: | Layer | Tool | Job | Cost | |-------|------|-----|------| -| UI | Lovable | Render the screens. Send form data down. | $0 free / $25 Pro / $100 Scale | -| Data | Supabase | Store the user, the row, the file. Listen for Stripe events. | $0 free / $25 Pro | +| UI | Lovable | Render the screens. Send form data down. | Free tier + paid tiers | +| Data | Supabase | Store the user, the row, the file. Listen for Stripe events. | Free tier + paid tiers | | Money | Stripe | Charge the card. Tell Supabase the customer is paid. | 2.9% + $0.30 per transaction | The buyer opens the staging URL → Lovable shows the screens → Supabase stores the data → Stripe charges the card → a Stripe webhook tells Supabase the row is now paid. @@ -96,7 +96,7 @@ Pre-seed founders ask "which framework" before they ask "which job." Three tools Lovable is an AI-powered builder for the screens. You describe an app in English: *"a dashboard for fitness coaches to log client check-ins, with a weekly export to CSV"*, and Lovable generates a working web frontend with proper component structure, routing, and form validation. Every save deploys to a public staging URL you can paste into a Slack message. -[Lovable's pricing tiers in 2026](https://lovable.dev/pricing) run $0 (Free, capped messages), $25/mo (Pro), $50/mo (Business), and $100/mo (Scale, the tier most paying-MVP founders settle on after the first month). +[Lovable's pricing](https://lovable.dev/pricing) runs from a capped free tier through paid tiers sized by build velocity - check the pricing page for current numbers. Most paying-MVP founders settle on a mid or scale tier after the first month. The key thing it does not do well: heavy backend logic, complex auth flows, anything custom on the database side. That is what Supabase is for. @@ -104,9 +104,9 @@ The key thing it does not do well: heavy backend logic, complex auth flows, anyt Supabase is managed Postgres + auth + file storage + row-level security in one console. Lovable's built-in storage is fine for a prototype; Supabase is what you connect when you have real users whose data has to survive a redeploy. -The free tier handles up to 50,000 monthly active users and 500MB of database before you have to upgrade. Pro is $25/month and most pre-seed founders never outgrow it before they hit the architectural ceiling. +The free tier comfortably covers early-stage usage - [check Supabase's pricing page](https://supabase.com/pricing) for current limits. Most pre-seed founders never outgrow the first paid tier before they hit the architectural ceiling. -Supabase auto-generates a REST API and a JavaScript client on top of any table you create, which is what Lovable calls when it needs to read or write a row. [Supabase's 2026 pricing](https://supabase.com/pricing) lists the bands clearly. The auth product replaces 80% of what founders used to pay Auth0 or Clerk for; the row-level security policies replace what a contractor would have hand-coded over two weeks. +Supabase auto-generates a REST API and a JavaScript client on top of any table you create, which is what Lovable calls when it needs to read or write a row. [Supabase's 2026 pricing](https://supabase.com/pricing) lists the bands clearly. The auth product replaces most of what founders used to pay Auth0 or Clerk for; the row-level security policies replace what a contractor would have hand-coded over two weeks. ### Stripe - the money layer @@ -167,7 +167,7 @@ Synthesis of every rule scattered across Module 4 and the supplementary referenc 6. **Set up GitHub sync in Lovable Settings on day 1.** Lovable can drop the work; GitHub is your backup. Skipping this is the #1 reason founders cannot retrieve their source. 7. **Enable Row-Level Security on every Supabase table from day 1.** RLS is the rule that says "Coach A can only read Coach A's rows." Skipping it ships the cross-tenant data leak that ends pilots (see Ch 4.4 Signal 4). 8. **Stripe webhook handler must be idempotent.** Idempotent means "safe to run twice without breaking anything" - Stripe sometimes sends the same payment event more than once, and your handler must not double-charge or double-activate. Check `WHERE event_id = $1 AND processed = true` before re-running the update. (See production hardening section of [hire-track reference](/course/tech-for-non-technical-founders-2026/hire-track-supplementary-reference/#production-hardening-checklist-what-your-fractional-cto-will-look-for) for details.) -9. **Budget envelope: vendor free tiers + per-tool monthly fees.** Lovable free, Supabase free, Stripe transaction fees, domain registration. Upgrade Lovable to $25/mo Pro only when build velocity demands it. +9. **Budget envelope: vendor free tiers + per-tool monthly fees.** Lovable free, Supabase free, Stripe transaction fees, domain registration. Upgrade Lovable to a paid tier only when build velocity demands it. 10. **Ship before scope creep, then a short stabilization phase.** Build the smallest end-to-end thing, then a stabilization phase before paid-pilot conversations. Sits inside the multi-month journey to first paying customer. 11. **Monthly Ch 4.4 ceiling-signal check once the live MVP is up.** Even if everything is green, the habit catches the 5 architectural break-points before they become rebuilds. 12. **Do not scale a Lovable stack past ~5K users or 2 ceiling signals at red.** When you hit either limit, graduate to a Fractional CTO bridge (see [hire-track reference](/course/tech-for-non-technical-founders-2026/hire-track-supplementary-reference/#the-fractional-cto-bridge)). The shed is not the house; pouring skyscraper foundations into a shed slab does not build a skyscraper. @@ -184,7 +184,7 @@ You are about to hit a wall: a Lovable prompt that produces the wrong component, | **[Indie Hackers](https://www.indiehackers.com/)** | Bootstrap-focused | Honest revenue posts + shipping logs; Friday-demo accountability rhythm | Free + paid tier (varies) | | **[No Code Founders (NCF Slack)](https://www.nocodefounders.com/)** | Full no-code stack (Bubble, Webflow, Glide, Softr) | If Lovable is wrong for your UI shape; worth membership even if you stay on Lovable | Free membership | | **r/nocode + r/vibecoding (Reddit)** | Free, indexable | Lower signal-to-noise than Slack; search before post | Free | -| **[Buildspace + Maven cohorts](https://maven.com/)** | Drew Falkman's "Vibe Coding Data-Enabled AI Apps" (~$1K) | Peer cohort + office hours; for founders who ship harder under deadline | ~$1,000 | +| **[Buildspace + Maven cohorts](https://maven.com/)** | Drew Falkman's "Vibe Coding Data-Enabled AI Apps" | Peer cohort + office hours; for founders who ship harder under deadline | Paid - check the course page | None of these is JetThoughts. None of them sells you a service. They are the founder peer pool the YC stance on co-founders [now points at](https://www.ycombinator.com/library/) instead of the 50%-equity hire. @@ -205,7 +205,7 @@ None of these is JetThoughts. None of them sells you a service. They are the fou > > **If blocked:** If the tools don't click yet, skim the Lovable Discord or Indie Hackers to see real founders shipping with this exact stack. The communities section above lists free help channels. -> **Stuck? Most first-timers stall here:** the 12 rules list feels like a homework checklist and you haven't opened Lovable yet. **Fix:** read ONLY the 3 pre-Lovable rules at the top of the list. The other 9 fire inline during the build - they're reminders, not prerequisites. Open Lovable and paste your brief's Section 3. Ship one screen tonight. +> **Stuck here?** The 12 rules list feels like a homework checklist and you haven't opened Lovable yet. **Fix:** read ONLY the 3 pre-Lovable rules at the top of the list. The other 9 fire inline during the build - they're reminders, not prerequisites. Open Lovable and paste your brief's Section 3. Ship one screen tonight. > **Case Study: Tomas & Mia** > diff --git a/content/course/tech-for-non-technical-founders-2026/should-you-hire-2026-decision-tree/airbnb-test.svg b/content/course/tech-for-non-technical-founders-2026/should-you-hire-2026-decision-tree/airbnb-test.svg index 2508304e7..c9d07bb31 100644 --- a/content/course/tech-for-non-technical-founders-2026/should-you-hire-2026-decision-tree/airbnb-test.svg +++ b/content/course/tech-for-non-technical-founders-2026/should-you-hire-2026-decision-tree/airbnb-test.svg @@ -32,7 +32,7 @@ Step 2 Send the link to - 35 ICP prospects. + 30 ICP prospects. Watch what happens. 7 reply. 5 ask questions. 3 click checkout. @@ -53,7 +53,7 @@ - If 0 of 35 click: the problem is real, + If 0 of 30 click: the problem is real, your pitch is wrong. Re-write the page. $0 spent on engineering. 0% sunk cost. 100% information. diff --git a/content/course/tech-for-non-technical-founders-2026/should-you-hire-2026-decision-tree/index.md b/content/course/tech-for-non-technical-founders-2026/should-you-hire-2026-decision-tree/index.md index 9e9a1debe..cefd5670a 100644 --- a/content/course/tech-for-non-technical-founders-2026/should-you-hire-2026-decision-tree/index.md +++ b/content/course/tech-for-non-technical-founders-2026/should-you-hire-2026-decision-tree/index.md @@ -62,15 +62,15 @@ Brian Chesky and Joe Gebbia did not write code first. They blew up an air mattre The product was a website with a payment link. The validation was three strangers paying real money. Paul Graham later wrote about the same instinct in [*Do things that don't scale*](https://paulgraham.com/ds.html): the founders who win are the ones who do the unscalable, manual experiment that proves demand before they industrialize it. -The 2026 version of the Airbnb test takes one afternoon: a Carrd page with a Stripe checkout for an annual plan, a Notion FAQ that explains exactly what the buyer gets, and the link sent to 35 ICP prospects from your [Find 10 People With the Problem](/course/tech-for-non-technical-founders-2026/find-10-people-with-problem-outreach-2026/) outreach list. The result you are watching for is in the next paragraph. +The 2026 version of the Airbnb test takes one afternoon: a Carrd page with a Stripe checkout for an annual plan, a Notion FAQ that explains exactly what the buyer gets, and the link sent to the 30 people from your [Find 10 People With the Problem](/course/tech-for-non-technical-founders-2026/find-10-people-with-problem-outreach-2026/) outreach list. The result you are watching for is in the next paragraph. -![A 3-step illustration of the Airbnb test: Carrd page with Stripe checkout (Step 1), send link to 35 ICP prospects (Step 2), refund non-buyers and build only what you sold (Step 3). A sticky note at the bottom warns: if 0 of 35 click, the problem is real but your pitch is wrong, rewrite the page.](airbnb-test.svg) +![A 3-step illustration of the Airbnb test: Carrd page with Stripe checkout (Step 1), send link to 30 ICP prospects (Step 2), refund non-buyers and build only what you sold (Step 3). A sticky note at the bottom warns: if 0 of 30 click, the problem is real but your pitch is wrong, rewrite the page.](airbnb-test.svg) The signal you are looking for is small. Two paying buyers from 35 cold outreach hits is enough to flip the build switch. We know a B2B SaaS founder who sold five annual contracts at $1,800 each via a Stripe link and a Notion doc before she wrote a line of code. By the time her contractor delivered the v1 web app eight weeks later, she had $9,000 in pre-revenue and a customer-feedback loop already running. The build was constrained by what she had already promised the five buyers, which is the cheapest scope-control mechanism that exists. -Zero clicks from 35 prospects is brutal in the other direction. The problem might be real (you validated it in [Decide What's Next](/course/tech-for-non-technical-founders-2026/mom-test-synthesis-build-pivot-kill/)) but your pitch is wrong, your price is wrong, or the timing is wrong. Find out for $200 instead of $30,000. +Zero clicks from 30 prospects is brutal in the other direction. The problem might be real (you validated it in [Decide What's Next](/course/tech-for-non-technical-founders-2026/mom-test-synthesis-build-pivot-kill/)) but your pitch is wrong, your price is wrong, or the timing is wrong. Find out for $200 instead of $30,000. ## Pick the right building before you commit to build @@ -91,13 +91,13 @@ Most build-vs-hire posts give you one answer. The honest answer is four answers, ### 1. Validate without code -Use this path when you have no MVP yet, a single untested hypothesis, and no confirmation that anyone will pay. This week: ship a Carrd page + Stripe checkout + Notion FAQ, add a Lovable demo screen recording if you have one, and send the link to 35 ICP prospects from your [Find 10 People With the Problem](/course/tech-for-non-technical-founders-2026/find-10-people-with-problem-outreach-2026/) outreach list. Tooling is per-vendor (Carrd annual domain + page, Stripe free until transactions, Notion free, Lovable trial), with optional LinkedIn or Google ad spend on top. If zero buyers click, you found that out before you spent real runway - rewrite the pitch or pivot the problem. +Use this path when you have no MVP yet, a single untested hypothesis, and no confirmation that anyone will pay. This week: ship a Carrd page + Stripe checkout + Notion FAQ, add a Lovable demo screen recording if you have one, and send the link to 30 ICP prospects from your [Find 10 People With the Problem](/course/tech-for-non-technical-founders-2026/find-10-people-with-problem-outreach-2026/) outreach list. Tooling is per-vendor (Carrd annual domain + page, Stripe free until transactions, Notion free, Lovable trial), with optional LinkedIn or Google ad spend on top. If zero buyers click, you found that out before you spent real runway - rewrite the pitch or pivot the problem. ### 2. Self-serve build ([The Self-Serve MVP Stack](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-lovable-supabase-stripe-2026/)) Pick this path when the problem is validated (10+ Mom Test interviews with ≥7 strong-signal scores per the Ch 2.5 synthesis rubric + a Ch 1.4 smoke test that cleared the 6%+ "Promising" band - pre-orders and paid pilots are produced LATER in Module 5, do not require them as the gate), the scope is one workflow for one persona, and the backend requirements are simple - no real-time collaboration, no complex refund flows, no compliance scope. -This week: paste your [one-page brief](/course/tech-for-non-technical-founders-2026/vibe-prd-template/) into [Lovable](https://lovable.dev) (an AI app builder - free trial, paid plans from $25/month), ship the smallest end-to-end thing it generates, and connect [Supabase](https://supabase.com) (database + auth, free tier) + Stripe + Resend on top. Tooling is per-vendor pricing across the stack. Watch one failure mode: hitting the architectural ceiling when the app crosses ~5,000 users or your second integration. [5 Ceiling Signals](/course/tech-for-non-technical-founders-2026/vibe-coding-ceiling-signals/) tells you when to move up. +This week: paste your [one-page brief](/course/tech-for-non-technical-founders-2026/vibe-prd-template/) into [Lovable](https://lovable.dev) (an AI app builder - free trial available), ship the smallest end-to-end thing it generates, and connect [Supabase](https://supabase.com) (database + auth, free tier) + Stripe + Resend on top. Tooling is per-vendor pricing across the stack. Watch one failure mode: hitting the architectural ceiling when the app crosses ~5,000 users or your second integration. [5 Ceiling Signals](/course/tech-for-non-technical-founders-2026/vibe-coding-ceiling-signals/) tells you when to move up. ### 3. Fractional CTO bridge ([The Fractional CTO Bridge](/course/tech-for-non-technical-founders-2026/hire-track-supplementary-reference/#the-fractional-cto-bridge)) @@ -142,7 +142,7 @@ flowchart TD class Hire hire ``` -The Mermaid above is the worksheet. The five questions live in the diagram. The table below adds what each routed-to outcome means in practice and which chapter Sam reads next: +The Mermaid above is the worksheet. The five questions live in the diagram. The table below adds what each routed-to outcome means in practice and which chapter you read next: | Route | What it means | Next chapter to read | |---|---|---| @@ -151,7 +151,7 @@ The Mermaid above is the worksheet. The five questions live in the diagram. The | **Fractional CTO (Q4=No, Q5=fractional)** | Same self-serve build, but the architecture review is bought commercially instead of borrowed from your network. 0% equity. | [hire-track supplementary reference](/course/tech-for-non-technical-founders-2026/hire-track-supplementary-reference/) | | **Hire a team (Q2=Yes OR Q5=full team)** | Backend-heavy OR runway gives you 12+ months. Material monthly burn. Read the SOW first. | [SOW reading guide](/course/tech-for-non-technical-founders-2026/sow-reading-guide/) before signing anything | -**Q1 ("problem validated?")** counts as yes only if you have 10+ Mom Test interviews showing strong past-behavior signal, a smoke test that cleared the 6%+ "Promising" band (or a 5%+ Stripe-click), and a 2.4 prototype run with 4 of 5 testers reaching the right screen. +**Q1 ("problem validated?")** counts as yes only if you have 10+ Mom Test interviews showing strong past-behavior signal, a smoke test that cleared the 6%+ "Promising" band (or a 5%+ Stripe-click), and a Ch 2.6 prototype run with 4 of 5 testers reaching the right screen. **Q2 ("backend-heavy?")** translates to plain English: does your app need users to see each other typing in real time (Google Docs / Slack behavior), OR does it touch healthcare data, payment-card numbers stored on your servers, or enterprise SOC 2 audits? If neither, the answer is almost certainly **no** - simple apps, dashboards, forms, and single-user tools are not heavy. @@ -186,7 +186,7 @@ Two refundable deposits beat 200 LinkedIn likes. - Paul Graham, [*Do Things That Don't Scale*](https://paulgraham.com/ds.html) - the YC essay that named the Airbnb-style validation pattern. The first section is the Airbnb story; the rest is the manual that founders skip. - Paul Graham, [*The Airbnbs*](https://www.paulgraham.com/airbnbs.html) - PG's own short note on the Airbnb founders' early experiments. 6-minute read. - Sophia Matveeva, [*The Non-Technical Founder's Guide to Hiring*](https://www.amazon.com/Non-Technical-Founders-Guide-Hiring-Product-ebook/dp/B0B7WRLBZF) - the long-form companion to this post. Heavy on hiring, light on the validate-without-code path that comes first. -- Drew Falkman, [*Vibe Coding Data-Enabled AI Apps* on Maven](https://maven.com/) - the $1,000 cohort that teaches the self-serve stack (Path 2). Recommended if accountability is your blocker. +- Drew Falkman, [*Vibe Coding Data-Enabled AI Apps* on Maven](https://maven.com/) - the paid live cohort that teaches the self-serve stack (Path 2). Recommended if accountability is your blocker. - Y Combinator, [Startup School: Customer Discovery](https://www.ycombinator.com/library/) - YC's distilled take on validating before building. The path-1 reading list. - DHH, [The One Person Framework](https://world.hey.com/dhh/the-one-person-framework-711e6318) - the Rails case for keeping the architecture small enough that one developer can ship outcomes end-to-end. Reading for Path 2 and Path 3 founders. - Veracode, [GenAI Code Security Report 2025](https://www.veracode.com/blog/genai-code-security-report/) - 45% of LLM-generated code shipped at least one exploitable security flaw. Context for why Path 2 needs the 1-hour-a-month architecture review. diff --git a/content/course/tech-for-non-technical-founders-2026/stop-specifying-features-start-outcomes/index.md b/content/course/tech-for-non-technical-founders-2026/stop-specifying-features-start-outcomes/index.md index ebaec5fed..d785f6c90 100644 --- a/content/course/tech-for-non-technical-founders-2026/stop-specifying-features-start-outcomes/index.md +++ b/content/course/tech-for-non-technical-founders-2026/stop-specifying-features-start-outcomes/index.md @@ -29,31 +29,33 @@ canonical_url: "https://jetthoughts.com/course/tech-for-non-technical-founders-2 related_posts: false --- -> **Module 3 · Step 2 of 2** · [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) +> **Module 3 · Lesson 3.2 · [CORE] - the quality gate on your 3.1 brief** · [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) > > **Input:** a one-page Product Brief (from [Chapter 3.1](/course/tech-for-non-technical-founders-2026/one-page-product-brief-vibe-prd/)) > > **Output:** a one-page Product Brief rewritten so engineers and AI agents stop overengineering - -> **Jump to:** [What to do tomorrow](#what-to-do-tomorrow) · [Artifacts you carry out](#artifacts-you-carry-out-of-module-3) +> +> **Progress:** M3 · 2 of 2 · Results so far: one-page brief drafted (3.1) - this page stress-tests Section 3 before Module 4 builds from it > **TL;DR:** Rewrite every feature noun as an outcome-shaped job story. "Build a CSV export" becomes "When I prepare the weekly report, I want to grab the top 5 metrics in 30 seconds." The engineer has nothing left to invent. -> **Skip to the action:** [What to do tomorrow](#what-to-do-tomorrow) if you have your Ch 3.1 brief open and want the rewrite steps now. The examples and the theory will still be here. +*Skip to the action: [What to do tomorrow](#what-to-do-tomorrow) if you have your Ch 3.1 brief open and want the rewrite steps now, or jump ahead to [Artifacts you carry out of Module 3](#artifacts-you-carry-out-of-module-3). The examples and the theory will still be here.* You sent your engineer (or your AI agent) a one-line spec: *"build a simple admin panel."* Ten weeks later you have an admin panel with 47 buttons, role-based permissions, an audit log, and a co-pilot AI assistant. Your engineer isn't a show-off - those four words "a simple admin panel" don't tell anyone what "simple" means, who's using the panel, or what the panel needs to do. The engineer (or the training data) filled in those blanks from every big-company SaaS panel they had ever seen. +You finished Section 3 of your brief in the last lesson, so this page can feel like being asked to write it twice. It is not a rewrite for style - it is the 20-minute check that decides whether the builder ships the three buttons you meant or that 47-button spaceship. The Section 3 you fix here is the exact text Module 4 pastes into Lovable. + ![A hand-drawn comparison: the simple three-button admin panel you asked for on the left, the absurdly complex 47-button control deck that got built on the right, connected by a red arrow labeled 10-week build, $15K](admin-panel-spaceship.svg) ## Why feature briefs overbuild -Engineers and AI agents fill vague requests from training data - big-company SaaS panels, GitHub-scraped baselines, the busiest version of whatever they last saw. A feature word in isolation ("CSV export," "user roles") has no anchor to your actual job, so the engineer or agent invents the missing context. An outcome-shaped request ("when I prepare the weekly investor report, I want to grab the top 5 metrics in 30 seconds before the 4pm call") leaves nothing for them to invent - the moment, the action, the deadline, and the result are already on the page. +Engineers and AI agents fill vague requests from training data - big-company SaaS panels, GitHub-scraped baselines, the busiest version of whatever they last saw. A feature word in isolation ("CSV export," "user roles") has no anchor to your actual job, so the engineer or agent invents the missing context. An outcome-shaped request ("when I prepare the weekly investor report, I want to grab the top 5 metrics in 30 seconds before the 4pm call") leaves no blanks to fill - the moment, the action, the deadline, and the result are already on the page. ## Two briefs, two shapes each Same job, two ways to write it. Read each pair out loud. Notice how much the engineer or the agent has to invent under the feature shape, and how little they have to invent under the outcome shape. -![Feature-shaped brief on the left leading to a sketched BI suite with nine modules; outcome-shaped brief on the right leading to a single 'Copy top 5 metrics' button with a five-row data table](feature-vs-outcome.svg) +![Feature-shaped brief on the left leading to a sketched BI suite bristling with modules; outcome-shaped brief on the right leading to a single 'Copy top 5 metrics' button with a five-row data table](feature-vs-outcome.svg) ### Pair 1 - The CSV button @@ -63,7 +65,7 @@ Same job, two ways to write it. Read each pair out loud. Notice how much the eng What the engineer builds from the feature shape: a reporting module with three dashboards, scheduled email exports, role-based access on who can export, a date-range picker, custom column selectors, and an audit log of every download. Six weeks of work. You used the CSV button once a week for the investor email and ignored the other eight features. -What the engineer builds from the outcome shape: one button at the bottom of the existing dashboard that says *"Copy top 5 metrics to clipboard,"* hard-coded to MRR, net new MRR, active accounts, trial-to-paid conversion, and runway. Ninety minutes of work in a Rails controller, one line per metric. The next investor email goes out before the deck even opens. +What the engineer builds from the outcome shape: one button at the bottom of the existing dashboard that says *"Copy top 5 metrics to clipboard,"* hard-coded to MRR (monthly recurring revenue - what subscribers pay you each month), net new MRR, active accounts, trial-to-paid conversion, and runway. Ninety minutes of work in a Rails controller, one line per metric. The next investor email goes out before the deck even opens. ### Pair 2 - The CRM module @@ -85,7 +87,7 @@ Both outcome-shaped briefs in the section above use the same three parts. The sh **So I can [outcome]** - the business or personal result that proves the build worked. *"So I can paste them into the deck before the 4pm call"* gives a finish line the engineer can hold up against any feature suggestion. The engineer can now say: *"Does the build let you paste into the deck before 4pm? Then we are done. Does the audit log help with that? No? Cut it."* -Put the three parts together and the engineer (or the AI agent) has nowhere left to invent. Drop any one part - the timeframe, the action, or the outcome - and the gap gets filled in from training data instead of your intent. The same shape has a name in product-management literature; see *Further reading* below if you want to chase the lineage. +Put the three parts together and the engineer (or the AI agent) has no gaps left to guess at. Drop any one part - the timeframe, the action, or the outcome - and the gap gets filled in from training data instead of your intent. The same shape has a name in product-management literature; see *Further reading* below if you want to chase the lineage. ```mermaid %%{init: {'theme':'base', 'themeVariables': {'fontFamily':'Caveat, Patrick Hand, cursive', 'primaryColor':'#fff5f5', 'primaryBorderColor':'#cc342d', 'lineColor':'#333', 'primaryTextColor':'#1a1a1a'}}}%% @@ -117,14 +119,13 @@ flowchart TD Three actions, in order. -- **Open your filled-in [one-page brief](/course/tech-for-non-technical-founders-2026/vibe-prd-template/) from Chapter 3.1.** Find Section 3 ("What you're building"). Read the section out loud. If any line begins with a noun-shaped feature ("a CSV button," "a CRM," "user roles," "a settings page"), it is feature-shaped. Mark it. -- **Rewrite each marked line in the *When / I want / So I can* shape.** The *when* has to name a specific moment with a deadline, the *I want* has to name a verb and a budget, and the *so I can* has to name a result you can measure that week. Keep the whole section to a single focused pass. If you spill, the section is too big - your one-page brief is trying to be three. +- **Open your filled-in [one-page brief](/course/tech-for-non-technical-founders-2026/vibe-prd-template/) from Chapter 3.1.** Find Section 3 ("What you're building"). Read the section out loud. If any sentence leans on a noun-shaped feature ("a CSV button," "a CRM," "user roles," "a settings page"), it is feature-shaped. Mark it. +- **Rewrite each marked sentence in the *When / I want / So I can* shape.** The *when* has to name a specific moment with a deadline, the *I want* has to name a verb and a budget, and the *so I can* has to name a result you can measure that week. Keep the whole section to a single focused pass. If you spill, the section is too big - your one-page brief is trying to be three. - **Share the rewritten section with your engineer or your AI agent and ask exactly one question**: *"What would you build differently from this brief than you would have built from the feature list?"* Their first answer is the scope you were about to lose. Their second answer is the scope you are about to keep. > **The pass/fail rubric.** Read the peer's answer. The brief PASSES quality-check only if their answer stays inside your scope - the features in your Section 3 and the items NOT in your no-go list. The brief FAILS if their answer: > -> - names any feature you didn't list in Section 3, OR -> - mentions anything you explicitly cut in your no-go list, OR +> - names anything you explicitly cut in your no-go list, OR > - includes 2+ items outside the no-go list (your scope is too vague). > > FAIL = revise Section 3 outcome-shape and ask a fresh peer. Do NOT advance to Module 4 with a failed brief; the Lovable build will inherit the fuzziness. @@ -139,15 +140,17 @@ Three actions, in order. > > If Claude names 2+ items outside your no-go list, the brief failed quality-check the same as a peer flagging them. Revise Section 3 and re-run. This is the same failure signal a peer would surface, with no calendar coordination needed. > +> **No peer and no AI account?** The manual pass works too: read each Section 3 line and ask, "is this a thing the user does, or a thing the software has?" A line that names software parts (a dashboard, user roles, a settings page) is feature-shaped - rewrite it in the *When / I want / So I can* shape until it names a moment and a result instead. +> > **What AI cannot prove or substitute:** > - Whether your scope solves the validated problem (only the Module 4 build + real users can) > - Whether a real contractor would interpret the brief the same way (AI is a proxy, not a substitute) > > **The real gate:** a clean peer QA (human or AI) where the answer stays inside your scope AND no-go list. -> The cheap fix for this whole pattern is the rewrite tomorrow morning. The expensive fix is the salvage decision you read after the spaceship lands and investors ask why the demo is so heavy. One focused pass with a marker now spares you the build-and-throwaway later. +The cheap fix for this whole pattern is the rewrite tomorrow morning. The expensive fix is the salvage decision you read after the spaceship lands and investors ask why the demo is so heavy. One focused pass with a marker now spares you the build-and-throwaway later. -> **Optional: stack-rank features with real users.** After you have rewritten Section 3 as outcome-shaped job stories, you still have a list. If you need to know which outcome to build first, [OpinionX](https://opinionx.co) (free tier available) uses forced-ranking pairwise voting - users pick A or B, not rate everything "very important." Paste your 5-7 outcome statements, send the link to your Ch 2.3-2.4 interviewees, and the forced-choice format surfaces real priorities that a 1-10 rating scale hides. The output is a ranked list backed by pairwise win rates, not averaged scores. Use this before handing the brief to Lovable or a contractor - it prevents the "build everything because everything scored 8/10" trap. +**Optional: stack-rank features with real users.** After you have rewritten Section 3 as outcome-shaped job stories, you still have a list. If you need to know which outcome to build first, [OpinionX](https://opinionx.co) (free tier available) uses forced-ranking pairwise voting - users pick A or B, not rate everything "very important." Paste your 5-7 outcome statements, send the link to your Ch 2.3-2.4 interviewees, and the forced-choice format surfaces real priorities that a 1-10 rating scale hides. The output is a ranked list backed by pairwise win rates, not averaged scores. Use this before handing the brief to Lovable or a contractor - it prevents the "build everything because everything scored 8/10" trap. ## Artifacts you carry out of Module 3 @@ -156,14 +159,14 @@ After finishing Ch 3.1-3.2, you have five artifacts. Each one feeds a specific d | Artifact | Where it goes next | |---|---| | **One-Page Product Brief / Vibe PRD** (Ch 3.1 output) | Ch 4.1 build-path decision (the brief is the input the worksheet routes against) + Ch 4.3 (a + b) Lovable kickoff prompt. The single source of truth Module 4 builds from. | -| **Outcome-shaped feature list** (Ch 3.2 rewrite of Section 3 in Job Story format) | Ch 4.1 contractor SOW (if you route to hire) + Ch 4.3 (a + b) Lovable prompt body. Replaces the noun-shaped feature list that causes overbuild. | -| **No-Go list** (5-10 items you explicitly cut from Ch 3.1 Section 5) | Ch 4.3 (a + b) self-serve scope guard + Ch 4.4 ceiling-signal monitoring. The written "we are not building this yet" line that prevents Module 4 scope creep. | +| **Outcome-shaped feature list** (Ch 3.2 rewrite of Section 3 in Job Story format) | Ch 4.1 contractor SOW (Statement of Work - the document that tells a contractor exactly what to build) if you route to hire + Ch 4.3 (a + b) Lovable prompt body. Replaces the noun-shaped feature list that causes overbuild. | +| **No-Go list** (5-8 items you explicitly cut from Ch 3.1 Section 5) | Ch 4.3 (a + b) self-serve scope guard + Ch 4.4 ceiling-signal monitoring. The written "we are not building this yet" line that prevents Module 4 scope creep. | | **Audience-of-one fork** (the audience choice from Ch 3.1: AI agent / junior dev / senior team) | Ch 4.1 Q2 build-path routing. The fork decides whether the brief routes to Lovable (AI agent) or a contractor (junior or senior team). | | **Quality-check verdict** (Ch 3.2 - peer answers "what would you build differently?" cleanly?) | Checkpoint before Module 4. If the peer cannot answer cleanly, return to Ch 3.2 and rewrite Section 3 before opening Lovable or sending the SOW. | -> **Module 3 closes here.** Before opening Module 4, you should have: (1) a one-page Product Brief (Vibe PRD) with 5 sections filled in (Ch 3.1), (2) Section 3 rewritten as outcome-shaped job stories that pass the peer "what would you build differently?" test (this chapter), and (3) a no-go list of 5-10 items you explicitly cut. Both in your `Founder OS` folder. Missing one? Go back - Module 4 reads the brief into Lovable prompts; a half-written brief produces a half-working MVP. +> **Module 3 closes here.** Before opening Module 4, you should have: (1) a one-page Product Brief (Vibe PRD) with 5 sections filled in (Ch 3.1), (2) Section 3 rewritten as outcome-shaped job stories that pass the peer "what would you build differently?" test (this chapter), and (3) a no-go list of 5-8 items you explicitly cut. Both in your `Founder OS` folder. Missing one? Go back - Module 4 reads the brief into Lovable prompts; a half-written brief produces a half-working MVP. -When your brief skips the moment, the action, and the result, the engineer or the AI agent fills them in from training data. Name those three and there is nothing left for them to invent. +When your brief skips the moment, the action, and the result, the engineer or the AI agent fills them in from training data. Name all three in every line of Section 3, and the builder builds only what you asked for. ## Further reading @@ -175,18 +178,17 @@ When your brief skips the moment, the action, and the result, the engineer or th - Tom Kerwin, [JTBD Job Stories vs User Stories](https://jtbd.info/replacing-the-user-story-with-the-job-story-af7cdee10c27) - the 2013 Klement piece on Medium that popularised the shape, for readers who want the original 1,500 words. - Y Combinator, [Startup School: How to Write a Product Spec](https://www.ycombinator.com/library/) - YC's distilled take on specs that ship versus specs that sit. -> **Done when:** Every feature in Section 3 of your brief is rewritten as an outcome-shaped job story, and a peer (or Claude) confirms the brief stays inside your scope and no-go list. -> **Next click:** [4.1 · Should You Hire? The 2026 Decision Tree](/course/tech-for-non-technical-founders-2026/should-you-hire-2026-decision-tree/) -> **If blocked:** If Claude names 2+ items outside your no-go list when you run the quality-check prompt, your Section 3 is still too vague. Tighten the "When / I want / So I can" shape until Claude's answer stays inside your scope. - -> **Stuck? Most first-timers stall here:** every feature in Section 3 looks equally important, so the list keeps growing. **Fix:** pick the ONE outcome that would make a real customer pay or stay. Build that. Cut the rest to the no-go list. You can add them back after the first pilot in Module 5. - -> **Case Study: Tomas & Mia** +> **Done:** every line of Section 3 is rewritten in the *When / I want / So I can* shape, and one quality-check pass (peer, AI, or the manual question) names nothing outside your Section 3 scope and no-go list. > -> **Tomas**: Rewrites 3 feature-nouns as job stories. Example: "When a Stripe transaction has no matching QuickBooks invoice, I want to see the top 3 candidate matches so I can confirm in one click - not scan 200 line items." Passes the outcome filter: 4 of 5 sections are now outcomes, not features. +> **You have now:** the complete Module 3 output - a one-page Product Brief with an outcome-shaped Section 3, a no-go list of 5-8 items, and a passed quality check, all in your `Founder OS` folder. This is the page Module 4 builds from. > -> **Mia**: Rewrites 3 feature-nouns as job stories. Example: "When I search for a math tutor for my 10-year-old with dyslexia, I want to filter by 'dyslexia-trained' and see reviews from other parents - not scroll 50 generic math tutors." Passes: 5 of 5 sections are outcomes. +> **Next:** [4.1 · Should You Hire? The 2026 Decision Tree](/course/tech-for-non-technical-founders-2026/should-you-hire-2026-decision-tree/) - it reads the brief you just quality-checked as its input. +> **If blocked:** If Claude names 2+ items outside your no-go list when you run the quality-check prompt, your Section 3 is still too vague. Tighten the "When / I want / So I can" shape until Claude's answer stays inside your scope. + +> **Stuck here?** Every feature in Section 3 looks equally important, so the list keeps growing. **Fix:** pick the ONE outcome that would make a real customer pay or stay. Build that. Cut the rest to the no-go list. You can add them back after the first pilot in Module 5. --- +*See it in action: [Module 3 walkthrough: Mia writes the one-page brief](/course/tech-for-non-technical-founders-2026/module-3-walkthrough-mia/)* + *Built by [JetThoughts](https://jetthoughts.com) as part of the [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) curriculum.* diff --git a/content/course/tech-for-non-technical-founders-2026/three-questions-turn-standup-into-proof/index.md b/content/course/tech-for-non-technical-founders-2026/three-questions-turn-standup-into-proof/index.md index d00273862..e664ec779 100644 --- a/content/course/tech-for-non-technical-founders-2026/three-questions-turn-standup-into-proof/index.md +++ b/content/course/tech-for-non-technical-founders-2026/three-questions-turn-standup-into-proof/index.md @@ -29,7 +29,7 @@ cover_image_alt: "JetThoughts blog cover for Three Questions That Turn a Standup canonical_url: "https://jetthoughts.com/course/tech-for-non-technical-founders-2026/three-questions-turn-standup-into-proof/" --- -> **Chapter 5.4 · Step 3 of 5** · [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) +> **Going Further · Manage a Hired Team** · [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) > > **Input:** a team in place + a signed SOW > diff --git a/content/course/tech-for-non-technical-founders-2026/vibe-coding-ceiling-signals/index.md b/content/course/tech-for-non-technical-founders-2026/vibe-coding-ceiling-signals/index.md index f25df2fd4..0fb83e828 100644 --- a/content/course/tech-for-non-technical-founders-2026/vibe-coding-ceiling-signals/index.md +++ b/content/course/tech-for-non-technical-founders-2026/vibe-coding-ceiling-signals/index.md @@ -38,11 +38,11 @@ related_posts: false > **TL;DR:** Five architectural signals that mean the self-serve stack is maxed out. Two firing for 4+ weeks = graduate to a fractional CTO or hire. Run this check monthly once your MVP is live. -A working morning. Your [Lovable](https://lovable.dev) app is live (Lovable is an AI app builder that generates a working web app from a prompt - free trial, paid plans from $25/month, no coding required). 47 paying coaches on the platform. +A working morning. Your [Lovable](https://lovable.dev) app is live (Lovable is an AI app builder that generates a working web app from a prompt - free trial available, no coding required). 38 paying coaches on the platform. The dashboard takes 11 seconds to load for your largest account, a coach managing 80 clients. The Stripe webhook fired twice on three of yesterday's payments and you spent the morning refunding duplicates. -Two of your users keep landing on each other's data because the [Supabase](https://supabase.com) row-level security drifted last week when a contractor patched the check-in form (Supabase is a database + auth service that Lovable connects to automatically - free tier covers early-stage usage, paid plans from $25/month). +Two of your users keep landing on each other's data because the [Supabase](https://supabase.com) row-level security drifted last week when a contractor patched the check-in form (Supabase is a database + auth service that Lovable connects to automatically - free tier covers early-stage usage). The ceiling is visible now, but it was visible two months earlier too. That's when this check should have caught it. @@ -56,7 +56,7 @@ Once your build goes live, run this 5-signal check monthly. Each signal that fir ## Who this 5-signal check is for -The Lovable + Supabase + Stripe shed from [The Self-Serve MVP Stack](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-lovable-supabase-stripe-2026/) holds 80% of pre-seed B2B SaaS workloads. The other 20% is what this post is about. +The Lovable + Supabase + Stripe shed from [The Self-Serve MVP Stack](/course/tech-for-non-technical-founders-2026/self-serve-mvp-stack-lovable-supabase-stripe-2026/) holds most pre-seed B2B SaaS workloads. The remainder is what this post is about. Run this check monthly once your MVP is live and the ceiling shows up while it is still a tuning problem. Wait until something breaks - slow dashboard, duplicate webhooks, support tickets climbing - and you are paying late-fix prices on what was an early-fix problem. @@ -156,7 +156,7 @@ Vanta, [Drata](https://drata.com), and [Secureframe](https://secureframe.com) au > *"Thank you for the SOC2 / [BAA / PCI] questionnaire. We are pre-SOC2 [or pre-BAA] today and are starting the readiness work in Q3. In the meantime, I can share our security one-pager (encryption at rest via Supabase, payments via Stripe Checkout, data deletion on request) and offer a 90-day pilot with the data-handling restrictions of your choice - including hosting in a sandboxed instance if that helps your security team approve. Would that bridge work while we complete the formal certification?"* -This buys you 60-90 days to start the engineering work. About 30-40% of enterprise security teams will accept a documented bridge for a small pilot; the rest will say "come back when SOC2 is done" - which is the same answer you would get from ghosting them, plus you have preserved the relationship for the rebid 6 months later. +This buys you 60-90 days to start the engineering work. Some enterprise security teams will accept a documented bridge for a small pilot; the rest will say "come back when SOC2 is done" - which is the same answer you would get from ghosting them, plus you have preserved the relationship for the rebid 6 months later. Keep the security one-pager as a shared Google Doc with: data flow diagram, encryption-at-rest summary, vendor list (Supabase, Stripe, Lovable, Loom, etc.), and a one-line incident-response contact. 30 minutes to draft; reusable across every enterprise sales conversation. diff --git a/content/course/tech-for-non-technical-founders-2026/vibe-prd-template/cover.png b/content/course/tech-for-non-technical-founders-2026/vibe-prd-template/cover.png index 3b9ce53f0..afddddd10 100644 Binary files a/content/course/tech-for-non-technical-founders-2026/vibe-prd-template/cover.png and b/content/course/tech-for-non-technical-founders-2026/vibe-prd-template/cover.png differ diff --git a/content/course/tech-for-non-technical-founders-2026/vibe-prd-template/index.md b/content/course/tech-for-non-technical-founders-2026/vibe-prd-template/index.md index 9350e762d..18b1e0a43 100644 --- a/content/course/tech-for-non-technical-founders-2026/vibe-prd-template/index.md +++ b/content/course/tech-for-non-technical-founders-2026/vibe-prd-template/index.md @@ -20,11 +20,21 @@ tags: - course-companion - product categories: ["Templates"] +cover_image: cover.png +metatags: + image: cover.png + og_title: "Vibe PRD Template - One-Page Product Brief" + og_description: "One-page Product Brief template. Five sections, one 90-minute sitting. Hand to Lovable, Cursor, or a hired junior. Free." +cover_image_alt: "JetThoughts template cover for the one-page Vibe PRD - five labeled sections on a single page" canonical_url: "https://jetthoughts.com/course/tech-for-non-technical-founders-2026/vibe-prd-template/" related_posts: false --- -📋 Template companion to the [Chapter 3.1 post](/course/tech-for-non-technical-founders-2026/one-page-product-brief-vibe-prd/). Print after running the synthesis from [Chapter 2.1](/course/tech-for-non-technical-founders-2026/mom-test-synthesis-build-pivot-kill/). Fill in 45 minutes. Hand to your AI agent or contractor tomorrow. +> **Template companion to [Chapter 3.1 - The One-Page Product Brief (Vibe PRD)](/course/tech-for-non-technical-founders-2026/one-page-product-brief-vibe-prd/)** · [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) +> +> **Input:** your validated problem statement (from the [Chapter 2.5 synthesis](/course/tech-for-non-technical-founders-2026/mom-test-synthesis-build-pivot-kill/)) + the "describe in one sentence" vocabulary from your [Chapter 2.6 prototype sessions](/course/tech-for-non-technical-founders-2026/clickable-prototype-validation-2-hour-lovable/) +> +> **Output:** a filled one-page Product Brief (Vibe PRD), written in one 90-minute sitting, ready to hand to your AI agent or contractor tomorrow # Vibe PRD Template - One Page, Five Sections @@ -39,13 +49,13 @@ related_posts: false ## Why this exists -A solo founder I spoke with last quarter had a validated problem statement and a Lovable subscription. She typed her problem statement into the Lovable prompt and asked it to "build the simplest version of this." Twelve hours later she had a working web app with a settings page, a billing dashboard, three integrations, and 17 toggles she didn't ask for. She spent the next three weeks deciding which parts to delete. When she opened a second project with a one-page one-page brief - the same problem, but now with a no-go list - Lovable shipped the smallest end-to-end thing in 90 minutes. The page she filled in between the two attempts was the difference. The agent fills blanks with reasonable defaults; the brief is your only way to forbid the defaults. +A solo founder I spoke with last quarter had a validated problem statement and a Lovable subscription. She typed her problem statement into the Lovable prompt and asked it to "build the simplest version of this." Twelve hours later she had a working web app with a settings page, a billing dashboard, three integrations, and a pile of toggles she didn't ask for. She spent the next three weeks deciding which parts to delete. When she opened a second project with a one-page brief - the same problem, but now with a no-go list - Lovable shipped the smallest end-to-end thing in 90 minutes. The page she filled in between the two attempts was the difference. The agent fills blanks with reasonable defaults; the brief is your only way to forbid the defaults. ## How to use this Block 90 minutes on a single morning. Print the template (or copy the markdown block below into a Notion doc). Bring your filled-in [validated problem statement](/course/tech-for-non-technical-founders-2026/validated-problem-statement-template/). Open Lovable, Cursor, or your contractor's kickoff doc in a second tab. You will not type into the second tab yet. The page first. -Section 1 copies directly from your validated problem statement, word for word. Sections 2 through 5 you write from scratch. Hard cap at 45 minutes per section, 90 minutes total. If you spill, the persona is too broad or you are designing too much. +Section 1 copies directly from your validated problem statement, word for word. Sections 2 through 5 you write from scratch. Hard cap: 90 minutes total. If you spill, the persona is too broad or you are designing too much. After the page is filled, read it aloud to one peer over a 20-minute call. Ask them: "If you built this in a week using Lovable, what would you build that isn't on my no-go list?" Their first answer is your missing no-go item. @@ -123,7 +133,7 @@ _________________________________________________________ Output the user gets back: _________________________________________________________ -Authentication method (magic link / OAuth / none): +Authentication method (magic link = email sign-in link / OAuth = "sign in with Google" / none): _________________________________________________________ What v1 explicitly supports (scope of "done"): @@ -210,7 +220,7 @@ The same one page works for the first three audiences below. Senior engineers an > Bad: *"Founders need a better way to handle their finances."* -> Good: *"Pre-seed B2B SaaS founders running their own Stripe-to-QuickBooks reconciliation lose 6 hours per week and £800 per month in CFO contractor time. 8 of 10 interviewees confirmed (May 2026 sample). Quote: 'Tuesday at 9pm I spent 40 minutes copying Stripe payouts into QuickBooks. I called my CFO. She did it in 90 seconds.' Why now: AI inference cost for the classification step fell to $0.001 per call - the unit economics flip at $9/month per seat."* +> Good: *"Pre-seed B2B SaaS founders running their own Stripe-to-QuickBooks reconciliation lose 6 hours per week and $800 per month in CFO contractor time. 8 of 10 interviewees confirmed (May 2026 sample). Quote: 'Tuesday at 9pm I spent 40 minutes copying Stripe payouts into QuickBooks. I called my CFO. She did it in 90 seconds.' Why now: the AI step that does the matching now costs a fraction of a cent per transaction - cheap enough to sell the whole tool at $9/month per seat."* The good version is inherited from the validated problem statement. It names the persona by stage, industry, and specific workflow. It puts the cost in time and money. It includes a verbatim quote with a specific moment. It names the why-now with a specific number. A peer can argue with it. The bad version is too broad to argue with, which is why the agent or the junior fills it in for you. @@ -228,7 +238,7 @@ The good version is one paragraph, verb-led. It names the input (paste CSV), the > Good: *"Not in v1: multi-currency support. Multi-Stripe-account support. Automatic recurring sync. A settings page. A billing dashboard. User roles and permissions. A marketing site beyond the signup page. Mobile responsive design beyond 'works on a 1024px screen.' We will revisit each of these after the Section 4 metric is hit."* -The good no-go list names eight things a competent agent or junior might add. Each is concrete. The bad version is blank, which is how an EdTech founder I spoke with ended up with 17 settings toggles in version one. Twelve had no backend. Two crashed the app. The team had read her brief as a wish list and added everything she didn't forbid. +The good no-go list names eight things a competent agent or junior might add. Each is concrete. The bad version is blank, which is how the EdTech founder who opens [Chapter 3.1](/course/tech-for-non-technical-founders-2026/one-page-product-brief-vibe-prd/) ended up with 17 settings toggles in version one - 12 with no backend, 2 that crashed. Her team had read the brief as a wish list and added everything she didn't forbid. ## What to do after @@ -238,7 +248,7 @@ The good no-go list names eight things a competent agent or junior might add. Ea Skip the no-go list and you ship a working demo of a product nobody asked for. Six weeks later you're posting a [salvage or rebuild question](/course/tech-for-non-technical-founders-2026/salvage-vs-rebuild-decision-tree/) about an MVP you can't extend. The page is cheap. The build round you save by writing it is the expensive thing you avoid. -If you want the doctrine in long form, the [Chapter 3.1 post](/course/tech-for-non-technical-founders-2026/one-page-product-brief-vibe-prd/) walks through the five sections with the worked example, the decision between one-page brief and traditional PRD, and the case for paying $1,000 vs writing the page yourself for free. +If you want the doctrine in long form, the [Chapter 3.1 post](/course/tech-for-non-technical-founders-2026/one-page-product-brief-vibe-prd/) walks through the five sections with the worked example, the decision between one-page brief and traditional PRD, and the case for paying for a live cohort vs writing the page yourself for free. --- diff --git a/content/course/tech-for-non-technical-founders-2026/weekly-dev-report-template-founders/index.md b/content/course/tech-for-non-technical-founders-2026/weekly-dev-report-template-founders/index.md index 4555b3d63..2972894f9 100644 --- a/content/course/tech-for-non-technical-founders-2026/weekly-dev-report-template-founders/index.md +++ b/content/course/tech-for-non-technical-founders-2026/weekly-dev-report-template-founders/index.md @@ -29,7 +29,7 @@ cover_image_alt: "JetThoughts blog cover for The Plain-English Weekly Dev Report canonical_url: "https://jetthoughts.com/course/tech-for-non-technical-founders-2026/weekly-dev-report-template-founders/" --- -> **Chapter 5.5 · Step 4 of 5** · [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) +> **Going Further · Manage a Hired Team** · [From Idea to First Paying Customer](/course/tech-for-non-technical-founders-2026/) > > **Input:** a team in place + Friday demos running > diff --git a/data/course_banned_strings.yaml b/data/course_banned_strings.yaml index a540b1181..bab256b7a 100644 --- a/data/course_banned_strings.yaml +++ b/data/course_banned_strings.yaml @@ -19,8 +19,8 @@ banned: - string: " -- " reason: "em-dash replacement artifact" - string: "Case Study: Tomas & Mia" - reason: "case studies live only in module-end walkthroughs (30.03 §2.7) - applies to migrated modules M1/M2; remove entries per module as each migrates" - scope: "mom-test-|ai-persona-|find-10-|clickable-prototype|smoke-test-|form-your-founding|price-hypothesis|module-1-|module-2-|outreach-sequence|validated-problem" + reason: "case studies live only in module-end walkthroughs (30.03 §2.7) - applies to migrated modules M1/M2/M3; remove entries per module as each migrates" + scope: "mom-test-|ai-persona-|find-10-|clickable-prototype|smoke-test-|form-your-founding|price-hypothesis|module-1-|module-2-|module-3-|outreach-sequence|validated-problem|one-page-product-brief|stop-specifying|vibe-prd-template" - string: "<5 of 10 scored" reason: "gate is 7+/4-6/<4 (canonical: mom-test-synthesis)" - string: "fewer than 5 scores" @@ -54,4 +54,95 @@ banned: - string: "persona-setup prompt with your 3 ICP variants" reason: "2.6 step must use its own 3-screen prompt, not 2.2's" - string: "47-button admin panel" - reason: "recurring fake-specific number across anecdotes" + reason: "recurring fake-specific number across anecdotes (3.2 owns the canonical admin-panel story; ban stops reuse elsewhere)" + - string: "Chapter 2.1 synthesis" + reason: "synthesis is Lesson 2.5 after the M2 renumber (fixed 2026-07-11 in 3.1)" + - string: "Chapter 2.1](/course/tech-for-non-technical-founders-2026/mom-test-synthesis" + reason: "2.1 label linking to the 2.5 synthesis page (renumber mislabel class)" + - string: "$1,000" + reason: "volatile Maven cohort price - capability language only (de-hardcoding policy)" + scope: "one-page-product-brief-vibe-prd|stop-specifying-features-start-outcomes|vibe-prd-template|should-you-hire-2026-decision-tree|self-serve-mvp-stack-lovable-supabase-stripe-2026" + - string: "4.8/5" + reason: "volatile third-party review score (Maven)" + - string: "Artifact #4 of 6" + reason: "hardcoded artifact index retired in 3.1 v2 footer (2026-07-11)" + - string: "one-page one-page" + reason: "doubled-word typo (vibe-prd-template)" + - string: "Chapter 5.2 · Step" + reason: "stale manage-your-team 5.x scheme collides with live First-Customer 5.x (fixed 2026-07-10)" + - string: "Chapter 5.3 · Step" + reason: "stale manage-your-team 5.x scheme" + - string: "Chapter 5.4 · Step" + reason: "stale manage-your-team 5.x scheme" + - string: "Chapter 5.5 · Step" + reason: "stale manage-your-team 5.x scheme" + - string: "sub-section (Chapter 5.2)" + reason: "renumbered chapter mislabel (friday-demo-template)" + - string: "DPA from [Chapter 5.3]" + reason: "DPA chapter is 5.4 (operating-kit mislabel)" + - string: "Sam reads next" + reason: "internal ICP persona name in reader-facing prose" + - string: "default for Sam" + reason: "internal ICP persona name in reader-facing prose" + - string: "Sam's first pilot" + reason: "internal ICP persona name in reader-facing prose" + - string: "directional KILL" + reason: "retired gate vocabulary; 40% test outcome is not-must-have, gate is count-based" + - string: "35 ICP prospects" + reason: "outreach list canon is 30 names" + - string: "paid plans from $25/month" + reason: "volatile third-party price" + - string: "Free tier: 25 videos" + reason: "volatile plan limit (Loom)" + - string: "Free tier gives you 25 videos" + reason: "volatile plan limit (Loom)" + - string: "$99/month single-user" + reason: "volatile third-party price (Sales Navigator)" + - string: "Apollo Pro ($49" + reason: "volatile third-party price" + - string: "Smartlead ($39" + reason: "volatile third-party price" + - string: "$9.73 first year" + reason: "volatile registrar price with year-stamp" + - string: "Lovable Scale $100" + reason: "volatile third-party price" + - string: "Pro is $25/month" + reason: "volatile third-party price" + - string: "$25/mo (Pro)" + reason: "volatile third-party price" + - string: "up to 50,000 monthly active users" + reason: "volatile plan limit (Supabase)" + - string: "email credits + 10 export credits" + reason: "volatile plan limit (Apollo)" + - string: "25 searches/mo" + reason: "volatile plan limit (Hunter)" + - string: "1 free report/month" + reason: "volatile plan limit (WorthBuild)" + - string: "around 60% of paid pilots convert" + reason: "unsourced precision stat" + - string: "30-40% of enterprise security teams" + reason: "unsourced precision stat" + - string: "of pre-seed B2B SaaS workloads" + reason: "unsourced 80% precision stat" + - string: "47 enthusiastic Slack messages" + reason: "recurring fake-specific 47" + - string: "47 paying coaches" + reason: "recurring fake-specific 47" + - string: "awesome-directories.com" + reason: "thin secondary source; cite openhunts.com primary" + - string: "password**>" + reason: "glued blockquote render defect (4.2 Item #7)" + - string: "spends 2 of 4 weeks" + reason: "hardcoded third-party cohort structure" + - string: "Most first-timers" + reason: "cohort generalization dodging the Most-founders ban (fixed in 4 Stuck boxes 2026-07-10)" + - string: "no-go list of 5-10" + reason: "no-go list canon is 5-8 lines (3.1 owns it)" + - string: "£800" + reason: "currency drift on the shared reconciliation example ($ everywhere)" + - string: "2.4 prototype" + reason: "the prototype chapter is 2.6" + - string: "seventeen filters" + reason: "second fake-specific 17 on the 3.1 page" + - string: "founder I spoke with ended up with 17" + reason: "Sarah's 3.1 anecdote must not be re-attributed anonymously" diff --git a/docs/projects/2605-tech-for-non-technical-founders/10-19-research/10.02-curriculum-sequence-synthesis.md b/docs/projects/2605-tech-for-non-technical-founders/10-19-research/10.02-curriculum-sequence-synthesis.md index 4c664d70e..03dc80534 100644 --- a/docs/projects/2605-tech-for-non-technical-founders/10-19-research/10.02-curriculum-sequence-synthesis.md +++ b/docs/projects/2605-tech-for-non-technical-founders/10-19-research/10.02-curriculum-sequence-synthesis.md @@ -2,7 +2,7 @@ **Project**: 2605-tech-for-non-technical-founders **Created**: 2026-05-12 -**Status**: 🟡 Proposal awaiting confirmation - do not change existing artifacts until reviewed +**Status**: ⛔ SUPERSEDED (2026-07-10) - this 5-pillar spine proposal was NOT adopted. The live course uses the Hypothesis → Validate → Design → Build → First Customer spine per 20.01 + 20.10. Kept for research provenance only. **Author**: re-review pass after user re-framed the project goal mid-session --- diff --git a/docs/projects/2605-tech-for-non-technical-founders/10-19-research/10.08-validation-tools-analysis-2026.md b/docs/projects/2605-tech-for-non-technical-founders/10-19-research/10.08-validation-tools-analysis-2026.md index 5671352fb..be5e1f3ae 100644 --- a/docs/projects/2605-tech-for-non-technical-founders/10-19-research/10.08-validation-tools-analysis-2026.md +++ b/docs/projects/2605-tech-for-non-technical-founders/10-19-research/10.08-validation-tools-analysis-2026.md @@ -145,12 +145,12 @@ The research presents a SIPOC model that maps the startup launch pipeline: | # | Gap | Effort | Impact | Status | |---|---|---|---|---| -| 1 | Perplexity/Trend Seeker pre-hypothesis research | Low (sidebar) | High | → Overview chapter | -| 2 | Wizard of Oz Concierge MVP stack | Medium (new alt path) | Critical | → Future chapter | -| 3 | Echo chamber warning in Ch 5.3 + 2.3 | Low (inline callout) | High | → Future edit | -| 4 | Loom video outreach tactic | Low (tactic option) | Medium | → Future edit | -| 5 | Engineering as Marketing micro-tools | Low (tactic option) | Medium | → Future edit | -| 6 | IdeaProof/ValidatorAI ensemble validation | Low (sidebar) | Medium | → Overview chapter | +| 1 | Perplexity/Trend Seeker pre-hypothesis research | Low (sidebar) | High | ✅ Shipped - validation-tools overview chapter | +| 2 | Wizard of Oz Concierge MVP stack | Medium (new alt path) | Critical | ✅ Shipped - HTCW + 4.3a + glossary | +| 3 | Echo chamber warning in Ch 5.3 + 2.3 | Low (inline callout) | High | 🟡 Structurally addressed (M2 = strangers, 5.3 = sales-not-validation); inline callout in 2.3 still optional | +| 4 | Loom video outreach tactic | Low (tactic option) | Medium | ✅ Shipped - 5.3b outreach message | +| 5 | Engineering as Marketing micro-tools | Low (tactic option) | Medium | ✅ Shipped - 5.2 channel-selection callout | +| 6 | IdeaProof/ValidatorAI ensemble validation | Low (sidebar) | Medium | ✅ Shipped - validation-tools overview chapter | --- diff --git a/docs/projects/2605-tech-for-non-technical-founders/30-39-architecture-design/30.03-course-format-requirements-for-creators.md b/docs/projects/2605-tech-for-non-technical-founders/30-39-architecture-design/30.03-course-format-requirements-for-creators.md index 9aaa7b563..f8c303195 100644 --- a/docs/projects/2605-tech-for-non-technical-founders/30-39-architecture-design/30.03-course-format-requirements-for-creators.md +++ b/docs/projects/2605-tech-for-non-technical-founders/30-39-architecture-design/30.03-course-format-requirements-for-creators.md @@ -621,6 +621,8 @@ A final "toolkit" or checklist the student can keep using after the course — i Before accepting a module or lesson from a creator, run this checklist: +> **Rendered-output gate (2026-07-10):** every lesson/companion/walkthrough page also passes the visual SCROLL gate - a section-by-section chrome-devtools walk at 1280×800 + 390×844 with per-view screenshots, per `docs/workflows/visual-scroll-gate.md`. The text checks below cannot see mermaid clipping, SVG-internal facts, cover staleness, or callout stacking; the scroll gate is the only check for that class. + ### Per Lesson - [ ] Does the lesson have exactly one clearly stated outcome? (Section 2.2) diff --git a/docs/projects/2605-tech-for-non-technical-founders/40-49-review/40.13-retrospective-review-churn-2026-07-10.md b/docs/projects/2605-tech-for-non-technical-founders/40-49-review/40.13-retrospective-review-churn-2026-07-10.md index 137dffb1c..89f1a5616 100644 --- a/docs/projects/2605-tech-for-non-technical-founders/40-49-review/40.13-retrospective-review-churn-2026-07-10.md +++ b/docs/projects/2605-tech-for-non-technical-founders/40-49-review/40.13-retrospective-review-churn-2026-07-10.md @@ -38,6 +38,12 @@ introduced BY fix sweeps themselves. step") in every touched file, not just the moved labels. - Report language: never "everything is fine" - state "all N mechanized gates pass; review round K found X" so confidence claims are auditable. +- Every new/edited page passes the visual SCROLL gate before handback + (docs/workflows/visual-scroll-gate.md): full section-by-section + chrome-devtools walk at both viewports. Added 2026-07-10 after the M3 + pass found five rendered-output defect classes invisible to the + ratchet (mermaid clipping, SVG-internal facts, stale cover badge, + positional prose, artwork border overflow). ## Candidates for future validators (not yet built) - course_facts.yaml + course-fact shortcode for thresholds/budgets (kills diff --git a/docs/projects/2605-tech-for-non-technical-founders/40-49-review/40.15-whole-course-review-2026-07-10.md b/docs/projects/2605-tech-for-non-technical-founders/40-49-review/40.15-whole-course-review-2026-07-10.md new file mode 100644 index 000000000..f6abfc19d --- /dev/null +++ b/docs/projects/2605-tech-for-non-technical-founders/40-49-review/40.15-whole-course-review-2026-07-10.md @@ -0,0 +1,52 @@ +# 40.15 - Whole-Course Validity Review (2026-07-10) + +**Trigger**: user asked mid-M3-sprint: "can we re-review the whole course, is it valid, should we improve it while we are working on it? check the guides and researches." + +**Method**: 4 parallel read-only review agents, each grounded in a different doc base, findings triaged and fixed in commit 46b3f0a4 (branch `module-3-design-from-evidence`). + +## Verdicts + +| Lens | Grounding docs | Verdict | +|---|---|---| +| Curriculum vs research | 10.02/10.04/10.08/20.01/20.02 + yaml + landing | VALID-WITH-GAPS (gaps = stale tracking docs, no P1) | +| Spec compliance | 30.03 + all chapter files | REAL-DEFECTS (M5 numbering collision on Going Further pages; M1 fully compliant; bridge chain 1.1→3.1 intact) | +| ICP journey (Sam) | 40.06/40.07/90.10 + full reader path | COHERENT-WITH-FRICTION (3 persona leaks; M2 rework RESOLVED the old 40.06 trust-floors and flattened the U-curve trough) | +| Voice/claims M4-M5 | 90.11 + ratchet | SCATTERED-ISSUES (volatile price hardcodes in 6 files; canon otherwise consistent) | + +## Bottom line + +The course is valid: the 5-module spine matches the current strategy base, competitor-research recommendations (10.04 R1-R3) are demonstrably absorbed, every module boundary chains Input/Output correctly, and the decision-gate canon is consistent everywhere. The improvement work is exactly the kind worth doing while migrating: leftover classes in the NOT-yet-migrated M4/M5 chapters. + +## Fixed in this sprint (commit 46b3f0a4 unless noted) + +1. Stale "manage-your-team" Chapter 5.2-5.5 banners on 4 Going Further pages (engineering-org-chart, friday-demo-rule, three-questions-standup, weekly-dev-report) relabeled "Going Further · Manage a Hired Team" - they collided with the live First-Customer 5.x spine. +2. operating-kit DPA mislabel (5.3→5.4); friday-demo-template repointed to the org-chart page by name. +3. "Sam" persona leaks in 4.1/4.3b/5.4 → second person. +4. Quickstart fast path notes optional 2.2 (the exposed 2.1→2.3 gap). +5. Volatile third-party price/plan-limit hardcodes de-hardcoded in 4.1, 4.3a, 4.3b, 4.4, 5.2, 5.3b, 5.5 (+ worksheet, caught by ratchet). +6. OpenHunts 3.1%/23.1%/89% stats repointed to the primary source (openhunts.com/blog/tech-product-launch-statistics-insights, verified via web search); awesome-directories.com secondary dropped and banned. +7. Unsourced precision stats softened (60% pilots, 30-40% security teams, 80% workloads ×2). +8. Outreach-list canon: 35→30 in 4.1 prose + airbnb-test.svg + worksheet. +9. "directional KILL" (lowercase near-miss) in 5.1 → "not must-have" vocabulary. +10. Two fake-specific 47s varied (5.4 Slack messages, 4.4 paying coaches). +11. 4.2 Item #7 glued blockquote (`password**> Bad:`) render defect. +12. Doc hygiene: 10.02 marked SUPERSEDED (unadopted spine proposal); 10.08 gap table statuses corrected (5 of 6 shipped); YC Startup School named on landing as the cohort alternative (20.02 prescription). +13. 32 new ratchet signatures; the ratchet immediately caught 2 live instances outside the reviewers' scope. + +## Confirmed stale/no-action findings (do NOT re-open) + +- 3.1 case-study block: already removed in 453fc5be before the reviewer's snapshot. +- M2 bodies not word-band-compressed: known accepted waiver (carry-forward). +- Artifact #5/#6 footers in 4.3b/5.4: renumber in their module sprints (recorded). +- Case Study blocks in 9 M4/M5 chapters: strip in their sprints; ratchet scope extends per module. +- HTCW "5 modules / 20+ chapters" frontmatter: sanctioned near-number policy. +- 2.4 "Next" leading with the 2.1 back-reference: intentional (interviews run before synthesis). +- 5.1 "burned-thousands-on-paid-ads": forward-risk framing, on-ICP. + +## Deferred (carry-forwards, priority order) + +1. **M5 sprint**: strip 5 case blocks, Artifact #6 footer, external-URL checks (mailwarm.com, worthbuild.io), cohort-estimate fractions if flagged again. +2. **M4 sprint**: strip 4 case blocks, Artifact #5 footer, $200/hr single-point rate. +3. **See-it-in-action format**: shipped convention (italic line) deviates from 30.03 §2.7 blockquote example - reconcile the SPEC to shipped reality (needs user sign-off to edit 30.03). +4. **Slug hygiene** (tool names + year stamps in one-page-product URLs, e.g. self-serve-mvp-stack-lovable-supabase-stripe-2026): decided DEFER - redirect cost + SEO equity outweighs; bodies are already tool-agnostic. +5. **Echo-chamber inline callout in 2.3** (10.08 GAP 3 last 10%): optional one-liner; structural split already prevents the mistake. diff --git a/docs/projects/2605-tech-for-non-technical-founders/TASK-TRACKER.md b/docs/projects/2605-tech-for-non-technical-founders/TASK-TRACKER.md index c36f468f9..25e6d057a 100644 --- a/docs/projects/2605-tech-for-non-technical-founders/TASK-TRACKER.md +++ b/docs/projects/2605-tech-for-non-technical-founders/TASK-TRACKER.md @@ -305,7 +305,11 @@ Six principles drive this schedule. The wrong order wastes hours; the right orde **Module 2 exit gate:** All 6 micro-lessons follow template. Core path (2.1 → 2.3a → 2.3b → 2.4) produces validated problem statement without 2.2. Bridge chain verified. -#### Module 3 — Design from Evidence (~1-2 days) — PLAN REVISED + CONFIRMED 2026-07-09 (post-M2 re-review) +#### Module 3 — Design from Evidence (~1-2 days) — IN PROGRESS on branch `module-3-design-from-evidence` (2026-07-09) + +**Progress 2026-07-10:** whole-course 4-lens validity review run mid-sprint at user request - verdict VALID, 13 finding-classes fixed in 46b3f0a4 (M5 numbering collision on Going Further pages, 3 Sam persona leaks, volatile price hardcodes across 7 M4/M5 files, OpenHunts primary-source repoint, 35→30 canon, 32 ratchet sigs). Full report + carry-forwards: `40-49-review/40.15-whole-course-review-2026-07-10.md`. M4/M5 sprint scopes now pre-seeded by 40.15 §Deferred. + +**Progress 2026-07-09:** steps 1-6 done - 3.1 v2 (ea8943ec, incl. course-wide 2.1→2.5 mislabel + Maven price sweep across 5.1/4.1/4.3a/worksheet/companion, 6 ratchet sigs), 3.2 v2 with I1-I3 (4a2ff457), Mia walkthrough + See-it-in-action + case-block removal (453fc5be), companion aligned + cover wired + 90-min contradiction fixed (95a5c23e), SVG-internal renumber leftovers fixed - visual QA caught 'Chapter 2.1' inside vibe-prd-template-visual.svg and pivot-ledger.svg, note the ratchet does NOT scan SVGs (3220e2f2, 498974ca). I4 verified already-compliant (2-forks section already sits below the template as a labeled flowchart). Covers verified current (no regen needed). Mobile: no overflow, mermaids compact. Orientation pages already correct for M3. 2026-07-10 finalization: 4-lens M3 fan-out (ICP/quality/voice/boundary) - all findings fixed in e854b3d9 (walkthrough coherence, rubric contradiction, callout stacks, glosses, Sarah-anecdote single-sourcing, Most-first-timers dodge in 4 Stuck boxes); visual scroll gate run on all 4 pages x 2 viewports (mermaid clipping + SVG border overflow + stale companion cover fixed, cover regenerated); scroll gate codified as blocking check in docs/workflows/visual-scroll-gate.md + CLAUDE.md + 30.03 §7 + 40.13 (a05424f5). PR #352 carries the full sprint. > The original "2 chapters → ~3 micro-lessons" plan predates the M2 sprint and is superseded by this section. Revision grounded in: M2 shipped shape (PR #351), 40.13 process rules, 30.03 §2.7, and a fresh re-read of both M3 chapters on 2026-07-09. diff --git a/docs/workflows/visual-scroll-gate.md b/docs/workflows/visual-scroll-gate.md new file mode 100644 index 000000000..496390b85 --- /dev/null +++ b/docs/workflows/visual-scroll-gate.md @@ -0,0 +1,43 @@ +# Visual Scroll Gate (BLOCKING before handback) + +**When**: any new or edited content page (course lesson, walkthrough, companion/template page, blog post, landing page) and ANY change to a visual asset (SVG, mermaid, cover, image) - run BEFORE declaring the page done, in the same session as the edit. + +**Why this exists**: text validators cannot see rendered output. On 2026-07-10 this gate caught, in one Module 3 pass: mermaid node text clipped in every node (cursive theme font overflows mermaid's measured boxes), SVG text lines crossing the artwork's card border (user-visible defect), a stale "Curriculum 06/30" badge on a cover that had just been wired as og:image, a "the spaceship above" reference rendering BELOW the image, and a "Chapter 2.1" renumber leftover living INSIDE SVG artwork where the banned-string ratchet never looks. + +## Protocol + +1. `hugo server` + chrome-devtools MCP. Load the page at **1280×800**. +2. **Scroll section by section** (jump anchor-to-anchor via the h2 list, plus every diagram/image/table/callout) and screenshot each view. Actually look at each screenshot - the gate is your eyes, not the tool call. "Screenshot taken" is not the gate. +3. Repeat the walk at **390×844** (or at minimum: numeric probes + screenshots of every diagram). +4. Run the numeric probes on each page: + +```js +() => ({ + bodyOverflowX: document.documentElement.scrollWidth > document.documentElement.clientWidth, + mermaidHeights: [...document.querySelectorAll('svg[id^="mermaid"]')].map(m => Math.round(m.getBoundingClientRect().height)), + images: [...document.querySelectorAll('article img')].map(i => ({src: i.src.split('/').pop(), complete: i.complete, h: Math.round(i.getBoundingClientRect().height)})) +}) +``` + +5. Check the console (errors) and network (404s). Dev-server-only artifacts (e.g. webmanifest CORS when browsing via 127.0.0.1 against a localhost baseURL) are excusable - name them explicitly in the report; everything else is a blocker. + +## Per-view checklist + +| Class | What to look for | Caught before | +|---|---|---| +| Diagram text fit | Mermaid/SVG node text clipped, truncated mid-word, or crossing box borders (cursive theme fonts overflow mermaid's measurement) | 3.1 forks mermaid, 2026-07-10 | +| Artwork border overflow | SVG text lines extending past the card/page shape inside the artwork | vibe-prd-template-visual.svg | +| Facts inside artwork | Chapter numbers, counts, prices, time-boxes INSIDE SVGs/covers - the ratchet does not scan SVGs | "Chapter 2.1" in 2 SVGs | +| Cover staleness | Badge style, counters ("NN/30"), chip facts vs current canon - especially if the cover is og:image | vibe-prd-template cover | +| Positional prose | "the diagram above/below" pointing the wrong way after content moved | 3.2 spaceship hook | +| Diagram height | Rendered height > ~2× viewport (1600px desktop) = wall, compress | 2.1 interview-flow (M2 sprint) | +| Callout rhythm | 3+ same-form blockquotes stacked back to back | 3.2 opener + action section | +| Mobile overflow | bodyOverflowX true, tables without scroll containers, images past 100% | - | +| First-fold hook | An informational visual inside the first viewport at 1280×800 (hero rule) | - | +| Image wiring | cover_image present in frontmatter when cover.png exists; images actually load (complete=true after scroll) | vibe-prd-template | + +## Reporting + +State the result as evidence, not assurance: "scroll gate run on N pages × 2 viewports; found X (list), fixed; remaining console errors are dev-only (named)". Never "looks fine". + +Any fix that changes prose gets its ratchet signature (`data/course_banned_strings.yaml`) in the same commit, per `docs/projects/2605-tech-for-non-technical-founders/40-49-review/40.13-retrospective-review-churn-2026-07-10.md`. Fixes INSIDE SVGs cannot be ratcheted - re-run this gate after any SVG edit instead.