5 Experiments You Can Run in 15 Minutes for Product Concept Validation

You’ve probably never run “user research” in your life, and the word alone makes you want to close this tab. It sounds like a six-week process with a slide deck at the end: something a researcher at a company with 200 designers and researchers does, not something you have time for while you’re still sketching your business concept on the back of a napkin (or, let’s be honest, a food delivery app receipt). That’s not what this is.

Every product is built for someone. If that someone isn’t in the room while you’re building, you’re not moving fast, you’re just iteratively guessing, hoping to hit the jackpot of product-market-fit.

What follows are five ways to get that someone in the room today, without hiring anyone, blocking off a week, or reading a single research textbook (we know, you have 47 tabs open already). Each one takes about fifteen minutes – less time than your last “quick sync” that ran an hour plus. 

This isn’t a skill you’re missing. It’s one you’ve been using on investors and cofounders this whole time and just never turned on your actual users.

Already built something and have real users? This one’s not for you. Go straight to 5 Ways to Validate a Live MVP Before You Spend Another Dollar instead.

The rule that makes all five of these work

Ask about what people do, not what they’d want. “How do you currently track your freelance income?” tells you something real. “Would you use an app that tracks freelance income for you?” tells you nothing! Partly because people are too polite to say no to your face, and partly because most of us are just bad at imagining something that doesn’t exist yet. Nobody knew they needed a washing machine until someone built one. Every experiment below leans on this one habit. If you take nothing else from this piece, take that line.

1. The One-Sentence Pitch Test

This one takes fifteen minutes and tells you something most founders never actually check: whether a stranger understands your idea, not whether they like it. Those are two completely different questions, and it’s easy to mistake a polite nod for the second when you’ve only really tested the first.

Write your idea down as one plain sentence. Cut the jargon. No “leveraging AI to disrupt X.” If you catch yourself writing something like “AI-powered platform that leverages machine learning to optimize your financial workflows,” stop. That’s a sentence built to survive a pitch deck, not to be understood by a stranger. Try this instead: “An app that pulls out money for your tax and bills first, so the number left over is the real number you can spend.” Same idea, but now your barista could repeat it back to you.

Say it out loud, once, to someone who’s never heard it before, and ask them to repeat it back in their own words. Do that with three people.

Here’s what you’re listening for: if they get the “who it’s for” and “what it does for them” roughly right, even in completely different words than yours, that’s a real signal. If they just parrot your own sentence back at you, that’s not comprehension, that’s politeness. It means they nodded along, but nothing actually landed.

The instinct to fight here is jumping in to explain more the second someone looks confused. Don’t. Let the silence sit for a beat. Their confusion is the whole point of the exercise. That’s the data you came for.

2. The Current-Behavior DM (Direct message)

This tells you whether the problem is real. It costs 15 minutes to send, though replies trickle in over the next three or four days, so don’t expect an instant answer.

Pick 5 to 8 people in your target group and send them one specific question about how they currently handle the problem. 

“Would you use an app that helps you schedule client sessions?” gets a “yes” from almost anyone and tells you nothing. 

“How do you currently keep track of your clients’ bookings?” actually gets you somewhere, because it forces them to describe something they really do instead of imagining something hypothetical. Send it over whatever reaches them: WhatsApp, a LinkedIn DM, LINE, email. Send it to all those 5 to 8 people. One reply on its own doesn’t tell you much, it’s a story about one person. It is not a pattern with enough evidence just yet.

One rule: leave your idea out of the message entirely. Mention it and you’ve turned an honest question into a sales pitch they’ll feel obligated to be polite about.

You’ll know it worked when someone gives you unprompted detail, or even a bit of a rant: “honestly it’s a mess, I’ve got it half in a notebook and half in my texts.” That’s a real pain point talking. A polite one-liner usually means the problem isn’t top-of-mind enough yet to be worth solving, at least for that person.

The mistake founders make here is asking the hypothetical question because it feels safer than asking the real one. That’s less useful, and it’s the fastest way to talk yourself into believing something that isn’t true.

3. The Concept Test

Concept testing evaluates the appeal and projected successful landing of a new product before it’s built. It involves the user in the formative stages of your startup, using research methods like preference testing in surveys. Concept testing tells you whether the idea itself still makes sense once it’s slightly more real than a sentence, before you’ve decided on a single feature or screen. It takes fifteen minutes and needs nothing more than paper, a pen, and one person. By concept testing you are validating that your customers actually want the product and if you have variations in mind, which variation is more appealing.

Digital innovation experts at MIT, J. Ross and N. Fig. said “The purpose of hypothesis-driven concept testing is to limit risk, and, where possible, preempt failure.” 

They argue to use disciplined hypothesis testing to uncover assumptions and avoid costly mistakes early in the innovation cycle.

Draw one rough picture of the idea, how it works for the user and top level description of user benefit and how it works, how it fits in their life. You do not have to include a screen, or a flowchart, just a sketch of the thing itself on a Slide downloaded as a PNG. Show it to someone who’s never heard your pitch, and ask a single open question: “what do you think this is?” or “what would you use this for?” Then stay quiet and let them talk.

You’re not testing screens or navigation here – there is no task to do on your future product. You’re testing the same thing as the pitch you wrote in one sentence, just carried by a picture instead of words: does the idea survive translation without you standing next to it explaining what everything means?

A good result sounds like this: they land somewhere close to your actual idea, in their own words, maybe with a detail you hadn’t even mentioned. A bad result is silence followed by “I’m not sure, is this like a banking thing?” That’s not a bad drawing problem. That’s the idea itself not coming through yet.

The mistake founders make here is narrating while the person looks at the sketch, “so this part is the dashboard, and this is where you’d see your balance.” The second you do that, you’ve stopped testing whether the idea communicates itself and started testing whether your narration works. Hand it over, and let the silence do the work.

4. The Fake-Door Click Test

This one tells you whether demand is real, and it’s the only experiment here where you have to be honest about the timeline. Setup takes fifteen minutes. Results take a few days, once traffic actually reaches the page. Anyone who tells you this one works the same day is skipping a step.

Build a single page: the problem, your one-sentence pitch, and one button. “Reserve your spot” or “Join the waitlist” both work fine. There’s nothing behind that button when someone clicks it, and that’s the entire point of the exercise, you’re measuring intent, not building a product yet.

Point a small, honest amount of traffic at it. A few relevant communities, your own network, a tiny ad spend if you’ve got one to spare. Then watch the click-through rate. Ignore how you feel about the page.

A click-through rate that genuinely surprises you, in either direction, is a real result. A page almost nobody has seen yet isn’t a result at all, it’s a traffic problem wearing a demand problem’s clothes. Fix distribution before you draw any conclusion from a flat number.

The mistake founders make here is reading a quiet page as a “no.” Most of the time it’s just an empty room. Nobody walked in, so nobody said anything, and that’s a very different thing from everyone walking in and saying no.

5. The Price Gut-Check

This one tells you whether people are actually sold on the problem, before you’ve built anything resembling a pricing page. It takes fifteen minutes and needs nothing more than two real numbers and five people.

Pick two specific prices, not a range. “$4.99 a month or $9 a month” works. Ask five people which one they’d pay for the problem you’re solving, and pay as much attention to how fast they answer as to which number they pick. Then ask a follow-up: what would need to be true for the higher number to feel obviously worth it.

A quick, fairly confident pick is a good sign. Long hesitation, or “I’d need to try it first,” usually means they’re not sold on the problem yet. That’s a different issue than your price being wrong, and it’s worth not confusing the two.

The mistake founders make here is asking “how much would you pay,” a question nobody can answer honestly because there’s nothing to react to. Two real numbers give people something concrete to weigh. An open-ended question just gives them room to guess at what you want to hear.

Which one do I run today?

• Nothing built yet, not even a sketch. Start with #1 or #2.
• You’ve got a sketch. OK do #3.
• You’ve got a landing page. Do #4.
• You’ve already talked to 7+ people who confirmed the problem is real. Do #5.

The point of all this

None of these five need permission, a budget, a researcher or a designer. If you run just one of them this week, you’ll know more about whether you’re building the right thing than you do right now.

And this doesn’t stop mattering once you can afford to hire it out. You don’t graduate out of doing this yourself, you graduate into doing more of it, more often, at higher stakes. Once you’ve actually built something and have real users, the habit doesn’t change, only the questions do. That’s what [5 Ways to Validate a Live MVP Before You Spend Another Dollar] covers. And if you want the full shape of testing across a startup’s whole first year, from idea to live product, that’s in From Sketch to Scale: A Founder’s Playbook for Testing What You Build.

Questions founders ask about this