5.7 Pocket Test

At a Glance
Other names Pocket Demo · In-Person Demo · Pocket Smoke Test
In Brief
A pocket test means carrying a rough prototype and pulling it out mid-conversation with a prospect to get an unrehearsed first reaction. You watch how they try to use it and ask follow-up questions. The output is feedback on whether the concept makes sense, what features matter, and how people expect to interact with it. It fits products with a tangible form factor — physical goods, hardware, or anything someone can pick up or tap on a screen.
Common Use Case
You have a rough version of what you want to build — a physical prototype, a mobile app mockup, or a clickable demo — and want honest reactions before investing further. During a casual conversation with someone in your target market, you pull it out and watch how they react to it.
Helps Answer
- Am I building the right product?
- Do people understand what the product is and how it works?
- How do people expect to interact with this kind of solution?
- What limitations or concerns surface when someone holds it?
Description
A pocket test is a rough prototype you carry with you and surface in a live conversation, so a prospect reacts to it on the spot rather than to a description of it. They handle it, try to use it, and tell you what they think while you watch — the prototype does the explaining, and their reaction signals fit or rejection. It is a generative product-research method, and a natural next step after a Solution Interview or Customer Discovery Interviews: once an interview surfaces a problem, the pocket test puts a rough solution in front of the same kind of person so you can watch how they expect to use it.
Treat the prototype as a conversation piece, not a finished product. You are testing the main case: is this something the prospect wants, and could it believably address a problem they have voiced? An ugly prototype is fine as long as it teaches you something you did not already know. Because you are showing a specific solution to a stated problem, you learn more than an interview gives you — you watch how the prospect expects to use the product instead of asking them to describe it.
The method depends on getting in front of people outside your own team, where real reactions rather than internal opinions decide what to build next. Carrying the prototype with you is the lowest-overhead way to do that.
How to
Prep
1. Build the minimum viable prototype.
Only build enough to start a conversation:
- Physical products: Foam, cardboard, 3D-printed, or assembled from off-the-shelf parts. Ugly is fine — you’re testing the concept, not the finish.
- Software/apps: A clickable design prototype, a few screens in a slideshow, or a live demo on your phone or laptop. It doesn’t need to work end-to-end — just enough to show the core flow.
- Services: A one-page description, a mock invoice, or a sample deliverable.
Deliberately dial back the fidelity so the value proposition does the work, not the finish — AI tools can generate realistic-looking mockups very quickly, so resist the default and keep the prototype rough enough to signal “this is a concept.”
2. Identify 10–15 people to demo to.
They should have the problem you’re solving. Sources: existing users, prospects from interviews, conference attendees, coworking space contacts. Avoid friends and family unless they are actually in your target market.
3. Prepare your observation checklist.
Decide what you’re watching for before you demo:
- Do they understand what it does without you explaining?
- Do they try to interact with it in the way you intended?
- Do they ask about price, availability, or next steps? (Strong buying signal.)
- Do they compare it to something they already use? (Tells you your competition.)
Execution
1. Start a conversation about the problem, not the solution.
Don’t lead with “check out what I built.” Ask about their experience with the problem first. Once they’ve described the pain, then show the prototype: “I’ve been working on something — want to take a look?”
2. Show the prototype and observe.
Hand it to them (physically or screen-share). Watch how they interact with it. Don’t explain how it works unless they ask. Silence is data — if they stare at it confused, that’s a usability signal.
3. Ask follow-up questions.
- “What do you think this does?”
- “Would this be useful to you? Why or why not?”
- “What would you expect to happen next?”
- “How does this compare to how you handle this today?”
4. Record your observations immediately after.
Note their reaction (excited, confused, polite, skeptical), key quotes, and whether they asked about price or next steps. Don’t take notes during the conversation — it changes the dynamic.
Analysis
1. Tally reactions across demos.
After 10+ demos, categorize responses: How many understood it without explanation? How many asked about price or next steps? How many compared it to something they already use? Look for patterns, not individual reactions.
2. Identify the dominant failure mode.
- If most people don’t understand what it does → the concept needs clearer framing, not a better prototype.
- If they understand it but aren’t interested → the problem may not be painful enough for this audience.
- If they’re interested but point out the same missing feature → you’ve found your build priority.
3. For small samples (under 10 demos): Focus on qualitative signals. Two people who ask “can I buy this?” is a stronger signal than eight people who say “that’s interesting.”
- Confirmation bias Don’t explain, correct, or coach the prospect on how to use the prototype. If you catch yourself saying “no, you’re supposed to…” you’ve stopped testing and started selling.
- Social-desirability (politeness) bias People will say “that’s cool” to avoid awkwardness. Only concrete follow-up actions (asking about price, requesting a follow-up meeting, offering to refer someone) count as real interest.
- Selection bias Demoing only to people who are easy to reach — friends, coworkers, your existing users — skews reactions warm. Recruit from your actual target market, and discount enthusiasm from anyone who has a reason to be kind to you.
- Fidelity misdirection When a prototype looks finished, people redirect attention to design details instead of reacting to the core concept. Keep fidelity low enough that the value proposition, not the finish, carries the conversation.
Learn more
Got something to add? Share with the community.