Dog Toy vs Plastic Bottle: What My Dog Taught Me About Product Discovery
A few months ago I watched my dog spend forty minutes playing with an empty plastic water bottle.
Not a toy. Not something I bought or designed or tested. A bottle I'd finished and dropped on the floor. She batted it across the room. She chased it. She picked it up, shook it, dropped it, and started again. She was completely absorbed.
Meanwhile, the actual dog toy I'd spent $18 on — the one with the crinkle material and the squeaker and the colorful design — sat in her basket, untouched.
I didn't think much of it at the time. But later it became the clearest way I know to explain the single most common mistake founders make before they build anything.
The Toy That Nobody Asked For
The toy was well-made. It was designed by people who know dogs. It was marketed to people who love dogs. It sat in a basket next to a dog. And still — nothing.
The plastic bottle was an accident. Nobody researched it. Nobody prototyped it. Nobody A/B tested the shape. It just happened to be exactly the right weight, the right texture, the right noise, the right resistance when she bit down on it. It solved something real. Something her body already wanted.
This is the difference between a product someone thought would work and a product that solves a problem that already exists.
The toy was built around assumptions. The bottle was discovered.
The Mistake Most Founders Make
Most founders start with the toy. They have an idea. They think it through. They talk to a few people who say "yes, that sounds useful." They build.
Months later, they launch — and the product sits in the basket, untouched.
The problem wasn't the execution — it was that they never confirmed the underlying problem was real. Real enough, painful enough, and common enough that people were already doing something about it, even badly.
The bottle was a workaround. My dog had a problem — something to bite, something that made noise, something she could chase — and she solved it with whatever was available. That workaround is the demand signal.
When people are already solving a problem with something inadequate, that's evidence. That's the market telling you the problem is real and that the existing solutions aren't good enough.
This applies whether you're a first-time founder sitting on a list of unique business ideas or someone who's shipped before and is testing a new angle. The question is always the same: is there already a plastic bottle somewhere? Is someone already solving this badly?
Want to map the real demand signals around your idea before you build? Run it through Scoutr's discovery flow →
What Product Discovery Actually Is
Product discovery is not a phase in a sprint cycle. It's not one of those product discovery tools you add to your stack and forget. At its core, it's asking one question:
Is this problem real enough that people are already suffering through it?
Not "would you use this?" — that's the survey version, and it gets you friendly yeses from people who don't want to disappoint you.
The real question is behavioral: what are people doing right now to solve this problem? What spreadsheet are they maintaining that they hate? What process are they running manually that should be automated? What tool are they hacking to do something it wasn't designed for?
Those workarounds are plastic bottles. They're ugly, imperfect solutions to real problems. And they're one of the most reliable signals available to you before you write a single line of code.
If you want to know how to validate product ideas without burning months, start there — not with a survey, not with a landing page, but with the workaround.
The Customer Discovery Process Most People Skip
There's a version of customer discovery that looks like this: you write a list of customer discovery questions, you book ten calls, you take notes, you build a summary. That process is useful, but it's easy to game — including by yourself.
The version that actually works is simpler. You're not trying to get people to tell you the problem exists. You're trying to find evidence that they're already living with it.
That means looking at what people are doing, not what they're saying. A Reddit thread where someone asks "does anyone else manage X in a spreadsheet because nothing else works?" is more valuable than twenty interviews where people say "yeah, I'd probably use something like that."
The customer discovery process isn't a research phase you complete once. It's a habit — the practice of staying curious about what the gap actually looks like from the outside, before and after you start building.
The Discovery Error That's Easy to Miss
Here's the subtle version of the same mistake.
Sometimes you find the plastic bottle. You see the workaround. You understand the problem. You build the product. And then you build the $18 toy instead of the plastic bottle.
What I mean: you solve the real problem, but you solve it for slightly the wrong person, at slightly the wrong price, with slightly the wrong packaging. The core insight was right, but somewhere in the translation from problem to product, you optimized for what seemed polished rather than what the actual user needed.
This is why product idea validation doesn't end when you start building. It continues — through every design decision, every feature choice, every pricing conversation. You're always asking: does this still reflect the real problem, or am I drifting toward the thing I imagine the user wants?
A Product Discovery Framework That Doesn't Require a Spreadsheet
When I'm running an idea test, I use three questions. This is the product discovery framework I keep coming back to — not because it's sophisticated, but because it's fast and honest.
1. What are people doing right now to solve this problem? If the answer is "nothing" — either the problem isn't real, or it isn't painful enough. Real problems get solved, even badly. Find the workaround.
2. Why is the workaround painful? This is where you find the gap your product can fill. The workaround works, but at what cost? Time? Money? Embarrassment? Fragility? The more specific you can get about the pain, the more clearly you can see what "better" actually means.
3. Who has this problem badly enough to pay to fix it? Not everyone with a problem will pay to fix it. Some problems are annoying but tolerable. Others are blocking — work can't continue, revenue is at risk, something important breaks. You want the blocking ones. That's where willingness to pay lives.
Three questions. No slides. Just enough to run your product validation process before you spend months building a solution.
Whether you're evaluating business ideas for college students or stress-testing a B2B tool for a niche industry, the bottleneck is almost never creativity. It's this: is there a real, painful, already-being-worked-around problem underneath the idea?
The Bottle Is Already There
The thing that makes product discovery feel hard is that it seems like you're looking for something that might not exist. What if there's no demand? What if the problem isn't real?
But here's what I've learned: if the problem is real, the bottle is already there. Someone is already solving it badly. You just have to find it.
The communities where people complain about the problem. The Reddit threads where people share workarounds. The Hacker News comment sections where people describe how they're managing. The job postings that hint at what a company is struggling with. The spreadsheets people share in Slack channels because the "real" solution costs too much.
The signals are everywhere. The hard part isn't finding them — it's being honest about what they tell you.
scoutr analyzes real signals across Reddit, Hacker News, and competitor data to tell you whether your idea is solving a real problem before you build anything. Try it free →