Idea Validation Playbooks
How founders pressure-test an idea before building it — the demand signals worth chasing, the cheap experiments that surface real intent, and the traps that waste months. Every tactic below is quoted directly from a founder podcast and linked to its source.
245 tactics · page 7 of 9
“When we launched Fitness AI we hard-paywalled everything. The people who paid were telling us: this is real, this is a problem worth solving, and we're willing to put money down. That validated the product far faster than free users ever could.”
Paywalling everything at launch filters for users whose problem you actually solve
Moore argues that free tiers at launch add noise: free users are exploring, not confirming product-market fit. Paying users from day one constitute a cleaner signal — if strangers pay without persuasion, the problem and solution are real. The additional benefit is financial: early revenue funds iteration without fundraising urgency. The trade-off is slower install growth, which Moore accepted as a fair price for signal quality.
“Golf influencers had already trained golfers to use apps on the course. They taught the behaviour — I just built the product that fulfilled the need they'd created. You don't need to create a new behaviour if someone else has already done the hard work.”
Ride a behaviour influencers already taught — don't try to create a new one
Duffett noticed that YouTube golf channels were teaching viewers to use GPS yardage apps to improve their course management — but the apps available were clunky and data-poor. Rather than educating a market from scratch, he entered a market where the education was already happening and the demand was unmet. This is a distribution insight as much as a product insight: existing media consumption created pull before the product existed.
“I had zero marketing. I just submitted it to the App Store. And people were finding it and paying for it — people I'd never talked to, never told about the app. That's when I knew the product had something.”
The clearest PMF signal: strangers paying without you ever talking to them
Duffett submitted Shot Pattern without a launch campaign, email list, or social media push. Organic downloads followed by paid conversions from strangers — people who found the app through App Store search and chose to pay — told him the product solved a real problem at a price people accepted. He contrasts this with a previous app that required constant persuasion to convert anyone, which he now recognises as an absence of product-market fit.
“I spent five years on an app before Shot Pattern. Never broke $500 in a month. I kept building features thinking 'this will be the thing that makes people pay.' It never was. Looking back, nobody had a problem worth paying for.”
Five years on the wrong app taught what PMF isn't — no purchasing intent means no problem to solve
Duffett's first app (a coaching tool for a sport he played recreationally) never generated meaningful revenue despite sustained effort and multiple pivots. He now diagnoses it as a fundamental PMF absence: users were mildly interested but didn't have an urgent, recurring problem that made them willing to pay. The lesson is that feature iteration cannot substitute for a problem people are already motivated to solve.
“It's a fun platform to experiment but understand if you're trying to make a business this is a really really small audience still. I still think of it like it's a publicly available dev kit.”
Vision Pro is a publicly available dev kit — experiment if you can afford it, but don't build a business on it yet
Apple Watch, at launch, sold far fewer units than the iPhone or iPad yet was seen as a failure only because expectations were so high — Vision Pro is in an even earlier phase. The commercial opportunity is not yet there: hundreds of thousands of units compared to tens of millions for prior platform launches. Developers with bandwidth and financial flexibility can explore creatively, but building a business on it today is premature.
“A big market is great only if you can take a substantial share of that market. If it is so competitive that you can't actually garner market share, it's not actually valuable to you. There's a little bit of a Goldilocks approach — markets that are big enough to create enduring products but where you could still be a relative big fish in a smaller pond.”
Market size is only half the story — competition determines whether you can actually capture any of it
Falzon describes the two-dimensional market assessment framework applied at Mosaic when evaluating acquisitions: market size alone is insufficient. VPNs were avoided because every dollar of user acquisition competed against players spending aggressively. Personal finance was avoided because banks with 10x higher LTVs would always outbid a standalone budgeting app for the same acquisition keywords. The lesson: find markets large enough to build a real business but not so contested that you must outspend incumbents just to exist.
“I thought all right let's talk to everybody let's just talk to everybody see what see what's out there and I did and I talked to a ton of just like incredibly nice people I would talk to the CEOs and they were like hey man I'd love to have you come work here you have you've got it though if you want to go out on your own you've got it and I would be your first client”
Validate by talking to everybody in parallel, not one at a time
Aaron ran parallel conversations with as many potential employers and clients as possible in a compressed window. The signal that emerged from dozens of simultaneous calls — multiple CEOs offering to be the first client if he went solo — was clearer than any single conversation could have surfaced.
“I think there's a notion that like you can sit around and think up your best idea and that might be true for people with brains more powerful than my own but when I sit around and think up ideas they're usually bad but when ideas uh make themselves known to me as I am on the journey those ideas tend to be a lot better”
Best ideas surface from doing the work in public, not from brainstorms
Screencasting.com only exists because viewers kept asking how Aaron made his videos at PlanetScale. The validated demand surfaced from doing the work in public — not from a planning session. Stop trying to invent ideas; do real work visibly and listen for the question that keeps repeating.
“before you even jump to the what questions am I going to ask if you just stop and say what progress am I trying to make I really don't know what I should be charging I would like to make progress in knowing what I should charge”
Design surveys backwards from the business decision you need to make
Most founders build surveys by listing the questions they want to ask, which biases the survey toward what they want to hear. Asia flips it: define the business decision you need to make ('I don't know what to charge,' 'I don't know what to build next'), and only then design the questions that produce that decision.
“we really only do surveys when we have a larger volume of customers so if you have 100 plus customers surveys are going to be your jam but if you don't have 100 customers I would say interviews interviews are going to be your best friend”
100 paying customers is the survey-vs-interview cutoff
Surveys need volume to be useful. Below 100 paying customers, do 10-15 qualitative interviews instead — the signal is richer and the sample size is honest. Website surveys only start producing usable data once monthly traffic hits 5-10K. Pick the research method by current scale, not by what feels easier.
“oftentimes I'll get the best insights when I'm like I ask my question then I put myself on mute strategically and I'll just kind of wait for five to 10 seconds and you'll get really really good answers doing that by just wanting to like at least for myself Embrace That Awkward PA”
Mute yourself after asking the question to surface the real answer
Awkward silence is a research tool. Ask the question, hit mute for five to ten seconds, and the interviewee fills the gap with the answer that actually matters. Most founders rescue the silence and lose the insight — the discomfort IS the technique.
“in my head the choice is sort of binary in that either this stays in a private git repo and no one ever sees it the end or make it open source and then like maybe somebody can do something with it I'm curious what other people will do with it curiosity more than anything”
Open-sourcing a dead repo is a cheap validation test
After shutting Maybe down, Josh treated open-sourcing as the lowest-stakes possible 'launch' — pure curiosity, zero plan to revive. The repo hit a nerve, tens of thousands of people showed up, and the project came back to life with $1.1M+ in fresh funding within 10 days. Shipping something dead in public can be a cheaper validation test than building something new.
“that added a ton of overhead it meant that we could only be in the US we have to keep an unchangeable copy of every single interaction for like seven years we're not doing that anymore there's no advice component we can rip out half the code”
Every "and we also do X" silently shrinks the addressable market
Bolting a regulated financial-advisor layer onto v1 forced US-only rollout, locked the tech stack to seven-year audit trails, and ballooned overhead. The revival ripped that surface out — half the code went with it. Every 'and we also do X' tacked on at launch silently shrinks the market and slows the iteration loop. Cut the regulated piece, ship the simple version, see if anyone cares.
“embed yourself into these communities this is how stuff gets pulled out of you because there there are things that you know that you don't even realize that maybe other people want it or they're willing to pay you money for it you undervalue things most people do that”
Embed in a community so others pull insights out of you
Louie had never considered teaching a real-estate course until a community peer pointed at the expertise he was undervaluing. Products get easier to validate when peers point at the knowledge you've been ignoring in yourself. Sit inside a community of operators and listen for the asks — the next product is in those questions.
“I have packed a bunch of failed startups in the past and I would drive my mind crazy I would spend a year building a product that nobody would ever want and so now my marketing is mostly launching and I see how people react”
The launch IS the marketing — ship to see real reaction, not to win
After burning a year on products nobody wanted, Marc inverted the loop: launches ARE the validation. Ship it, watch the reaction. Real traction means go all-in; a couple hundred bucks at launch with no excitement means keep it running and move on — never spend another six months on something probably nobody wants.
“I build it live on uh YouTube I set up my stream I have my little microphone and I go live every morning and I would spend two to 6 or 8 hours live building the product and then I get people's feedback so they're like they sometime they help debug my code this is my pre pre validation thing”
Stream the build live as pre-pre-validation
Before any launch, Marc builds on YouTube live. Viewers debug code, suggest headlines, and a subset become potential customers asking for specific features. The stream functions as a free QA team, marketing channel, and pre-pre-validation signal — all collapsed into the building itself, not a separate marketing step.
“what if we just focused on this segment of the market right like just doing the knowledge-based thing because at the end of that when we started looking for tools to do this there didn't seem to be a lot of other tools doing this exact thing we figured we could just focus on this aspect of it make it play well with these other tools but just focus on doing this one thing really well”
Scope down to one segment of a crowded category and hold the line
KnowledgeOwl started as a full help-desk ambition inside another company, then narrowed to just the knowledge-base slice when an internal technical writer surfaced the gap. Picking one segment and integrating with the rest makes the yes/no calls obvious: not a forum tool, not light ticketing, not a chatbot. The constraint compounds — going narrow reveals how deep even one slice really is.
“we still track like how often because I think should never say never right you should leave your doors open we always said like we're not doing the chatbot right and now here we are in like 2024 like maybe it makes sense for eventually for us to actually have a chat bot even though for years we're like we're not doing that that's like out of scope”
Track every "no" so the tipping point becomes visible later
Out-of-scope feature requests don't get built, but they do get logged. Counting how often a request lands gives a tipping-point signal — what felt obviously off-scope (a chatbot) eventually becomes obviously core as the market shifts. Saying no today without locking the door shut tomorrow keeps optionality cheap.
“you have to kind of approach it more like um a researcher studying human behavior in a way you know you have to kind of um kind of observe what's happening in different um extreme cases um and then uh and then and then you start to form a pattern”
Treat the model like a tribe to observe, not code to debug
Models aren't deterministic functions — they refuse, hallucinate, and drift for no apparent reason. Working with them is closer to anthropology than software engineering: observe edge cases, log refusals, note the percentage of weird outputs, build a mental model over many trials. The blackbox doesn't yield to debugging, only to patient observation.
“users don't really care about what it looks or what you use I've seen other people say like well would a list help or how about a table maybe or a graph and then the users are like well I don't care I just want to see where I mentioned I don't care what you're doing”
Never offer solutions during user interviews
When a user complains, do NOT float 'would a table help? a dropdown? a graph?' — that's engineer brain looking for the solution. Lean in, ask why the pain matters and what it would unlock, and keep solutions out of the conversation. Take those back to the desk and return with something to test.
“maybe like once a week or once per two weeks like talk to maybe three people and they can be the same people like I know you can give them like a longer trial version or a big discount like in return I really want to keep it simple”
Continuous feedback cadence with the same three users
Set a continuous feedback loop: same three users, every one or two weeks, compensated with extended trials or discounts. Adding one feature reshuffles the whole page, so the priorities from last month may not apply now — only a recurring conversation with consistent people catches that drift.
“I really I I build the product with text to video for everybody why do I need a use case this is cool technology but then smart people told me it's going to be much easier to sell if you if you have a customer in mind right but then I picked the use case that I know best which is music videos”
Niche down to the use case you personally know
Klemke launched Neural Frames as a generic text-to-video tool for everyone. Smart advisors pushed him to pick a customer persona, so he chose music videos — the niche he knew personally from his own music background. Domain familiarity skipped the slow user-research feedback loop and made features, marketing, and roadmap compound for one clear persona.
“I always tell people three people three customers 48 hours then stick with it or find someone else that can stick with it instead of you”
Three customers in 48 hours, then commit or hand it off
Noah's validation rule: get three paying customers in 48 hours before committing serious time. If three real humans won't hand over money in two days, the idea isn't ready — pivot, hand it to someone who will stick with it, or move on. Forces a brutally fast signal instead of months of building in the dark.
“you have this little exercise in there where you look is it a million dollar idea and you look at what am I what is my average sale price and how many people are in the market and you multiply these two very simple numbers”
Run the million-dollar math before falling in love with an idea
ACV multiplied by addressable market. If the product is under $1M ceiling, it's structurally capped — no amount of execution fixes the math. Run two numbers before committing: 'how much will each buyer pay?' × 'how many such buyers exist?' Most founder ideas die in this calculation before they ever launch.
“I'm treating it as a product studio with the intent of basically creating like a validation engine that just figures out if something could sell could sell to his audience could sell past his audience right um and if those things are true then it's a thing that we pursue”
Treat the partner-creator project as a validation engine, not a single bet
Rox frames creator partnerships as a product studio, not a single bet. Every idea passes through a validation engine that tests whether it sells to the creator's audience AND past it before committing further build. The studio model bakes failure in: most ideas die fast, the few that pass both filters become the actual product.
“I'm starting with base hits so the creator has sold products before we're going to try and digitize those and that's going to be you know the first couple months and see how much revenue we can pull from that and then use that to fund the next projects”
Start with base hits — digitize what the creator already sold
Rather than guess at new ideas, Rox de-risks the first months by digitizing products the creator already proved sellable, then recycles that revenue to fund the next experiments. Pre-validated demand pays for the unproven swings. A solo founder version: ship the obvious answer to a problem you've already gotten paid for before betting on a new one.
“I thought I would use it and I'm not using it the the solution or the problem I have and that's where I generally I would ask people to start as well are you solving your own problem are you being your own first customer or first user if you are not then even like you know don't even pursue”
If you're not the first user, don't even pursue it
Sharath retired Bluey when he realized he wasn't using it himself. The validation filter: if the builder isn't the first customer of the solution, the project shouldn't be pursued. Two weeks after shipping v1, check the usage log — if you aren't a weekly user without willpower, treat it as a kill candidate, not a marketing problem.
“I'm having this issue as someone who's doing this so I started researching other people who were doing similar things in in that space and I saw that they were having the same similar issues and I'm like well if I'm not the only one having the issues and they're having these issues that must mean there's a gap here somewhere”
Hit the gap you hit — then check peers feel it too
Spencer found product-market fit by being his own first user. Day-trading with a partner surfaced a workflow problem; researching peers in the same niche confirmed the same gap existed for others. That overlap — your own pain plus a tribe sharing it — is the validation signal worth building on.
“you have to identify the M[oat] prior to building I think that's one of the big things because if you just go into this going oh I'm just going to build this I think you go well how can I prevent someone else from taking it”
Identify the moat before you build, not after
Spencer's rule for the AI-wrapper era: decide what makes the business hard to copy before writing a line of code. A scraped database of 5M podcast transcripts is a moat because replicating it costs time and compute. A Tailwind wrapper around an OpenAI call isn't — Vercel will one-click-deploy your idea before the launch tweet lands.
“if you are looking for an ID something that where you would just be uh totally free free of of competition from the big guys just just go for a Chrome extension doing some shady stuff with the private API from from website it's it's it's a good M you can do a lot of things”
Sketchy Chrome extensions are one of the few moats indies have
Tapio scrapes LinkedIn data via a Chrome extension on top of the public API — the kind of gray-area move large companies legally can't ship. Thibault's ethical line: is the user's account at risk? If no, ship it. This is one of the few defensible moats a solo founder has against well-funded incumbents.