How do you want
to work through this?
Six 10-minute exercises. Do them in order, don't overthink them, and see what you learn.
So You Have an Idea.
Now What?
Nothing you type here is sent anywhere. This runs entirely in your browser. We don't see it, store it, or collect it.
You've got something. Maybe it's sharp and clear, maybe it's still a feeling more than a plan. Either way, this is where most people get stuck, spinning between excitement and uncertainty, trying to figure out where to actually start.
This isn't a framework. It's six 10-minute exercises. Do them in order, don't overthink them, and see what you learn.
Tell us about
your idea.
Three quick fields. This is what will appear at the top of your Idea Clarity Snapshot.
Write the problem,
not the solution.
Most business ideas start in the wrong place. "I want to build an app that..." is a solution. Solutions feel exciting, but they're also where founders often get attached to the wrong thing before they've checked if anyone actually has the problem.
The discipline here is separating the two. If your idea is good, there's a real problem underneath it. Let's find that first.
Write one sentence that describes the problem without mentioning your product. No app, no platform, no service, just the problem. It should start with something like "People who do X struggle to Y because Z." If you can't write it without mentioning your solution, keep going until you can.
Reed Hastings reportedly got the idea after a $40 late fee on Apollo 13. The problem wasn't "people need more movies," it was "the rental experience is terrible." DVD by mail was just the first solution. Streaming came 10 years later. Same problem, totally different product.
Who has this problem
the most?
"Everyone has this problem" is almost never true, and even when it is, it's not useful. The question isn't who might eventually care. It's who has this problem so badly that they'd drop whatever they're doing to try something new right now, most importantly, the people who would pay you their hard earned money to solve this problem for them.
These are your early adopters. They're a specific type of person in a specific situation with a specific level of urgency. If you can't describe them in detail, you don't know who you're building for... yet.
Describe the one person for whom this problem is urgent, not just annoying. Where do they work, what's their day like, what does it cost them. Does it cost in time, money, or frustration?
Their first guests weren't "people who travel." They were attendees of a specific design conference in San Francisco, during a week when every hotel in the city was full. Urgent, not just inconvenient.
What are they doing
about it today?
If the problem is real, people are already solving it somehow. Maybe badly, maybe expensively, maybe with spreadsheets and duct tape, but they're doing something. That "something" is your actual competition, not whatever shows up when you Google your idea. Most importantly, the fact that they are doing something, means this problem must be solved.
Understanding the workaround tells you what people are willing to tolerate, what they're willing to pay, and where the real pain points are.
Name three alternatives your target customer uses right now. These can be direct competitors, workarounds, or doing nothing. For each one, write one sentence about what's still broken about it. What doesn't it solve, or what does it cost that it shouldn't?
Before it, teams were using email for updates, texting for urgent things, and scheduling meetings for everything that fell in between. Each one worked for something. None of them worked well enough for actual team communication. Slack didn't come into an empty market, it just looked at how broken the existing options were.
What makes you the right
person to solve this?
Anyone can have a good idea. What matters is why you?. Why your specific background, access, relationships, or way of seeing things, are positioned to solve it better than someone starting from scratch tomorrow.
This isn't about ego. It's about finding where your edge actually is, because that edge shapes what you build and how you build it.
Write your unfair advantage. Something real, specific, and hard to copy or buy. It could be domain expertise, relationships, proprietary data, a technical skill, or a decade of being inside the problem. If you can't identify one, that's useful information too.
The Collison brothers weren't payments experts. They were developers who had personally dealt with how broken payment integration was. Every existing solution was built by bankers, for bankers. They built for developers because they were developers. The industry knowledge, the contacts, the technical skill, that's an unfair advantage.
How do you reach them,
and how do you get paid?
A good idea with no path to customers is a hobby. Hobbies are fun, but before you devout your time and resources into a venture, you want at least a rough sketch of how someone finds you and how money changes hands. It doesn't need to be perfect, but there has to be a plan.
The simplest version of a go-to-market is: I reach this person through [channel], and they pay me [amount] for [thing]. That's it.
Sketch the simplest version of your go-to-market and revenue model. One channel you'd use first to reach your early adopter. One revenue model (subscription, per-use, one-time, services, whatever makes sense). It can pivot later, it doesn't need to be perfect, it just needs to exist on paper.
Didn't pitch to design teams or enterprise buyers first. Gave it away free to individual designers, let the work spread inside companies organically, then sold to the teams that were already using it. The product itself was the go-to-market strategy.
What's the one thing
you'd build to test this?
It is very expensive, time consuming, and inefficient, to build a whole product, before you have validated key ideas. An MVP isn't a small version of the vision. It's the smallest possible thing that tells you if the riskiest assumption you're making is true.
What's the riskiest assumption? It's the one that, if it turns out to be wrong, means the whole idea doesn't work.
Define the smallest experiment that tells you if that assumption is true. It might not be software at all. It could be a landing page, a manual process, a few customer calls, or a prototype vibe coded in a weekend. What are you testing, and what would a "yes" look like?
Before building anything, Drew Houston recorded a three-minute demo video of a product that didn't exist yet. The waitlist went from 5,000 to 75,000 overnight. They knew demand was real before writing a single line of infrastructure code.
Got something? Let's pressure-test it.
If you've done these exercises and you've got something, a problem you believe in, a customer you can describe, some clarity on what to test, then the next step is talking to someone who can help you figure out what to build first.
Book a Conversation →