99 Problems

How to Validate a Problem Before You Build the Solution

“If I had an hour to solve a problem, I’d spend 55 minutes thinking about the problem and 5 minutes thinking about solutions.”

Albert Einstein

Milkshakes

In The Innovator’s Solution, the follow-up to the must-read Innovator’s Dilemma, Clayton Christensen shares a story of a restaurant chain hoping to boost milkshake sales. The company hired a research firm to test features like new flavors, sizes, and thickness. None of it moved the needle.

So, they brought in a second group of consultants who flipped the script: before tweaking features, they asked what job the milkshake was hired to do, and for whom?

Digging into the data, they found most milkshakes were sold during the morning rush and again at lunchtime. Curious, the team observed and interviewed customers. Two main groups emerged: morning commuters and parents with young kids.

For commuters, the shake was a convenient, filling breakfast that kept them occupied on long drives. For parents, it was a special treat to reward their kids after a string of “nos.”

Same product, two different jobs. The very thing that worked for commuters—the shake’s thickness—was annoying for parents, who had to wait while their kids slurped it down. A perfect example of why focusing on solutions before understanding the problem can backfire.

Most of us start with solutions, not problems. But real progress begins with obsessing over the problem.

Christensen’s story offers the start of a framework you can use to test whether an idea is worth pursuing—by first understanding the problem deeply.

So next time you say, “I have a great idea!”—or someone excitedly validates it—pause and ask: “Is this a good problem to solve?”

What makes a good problem? In my experience (and from working with startups), seven characteristics stand out. They won’t guarantee success—nothing does—but they can meaningfully improve your odds. The framework below captures these traits.

And yes, I turned it into an acronym. Some corporate habits die hard. Hopefully the chemistry vibe makes it a little less cringey.

FI2R2ST

Familiar - how well do you understand the problem?

Identifiable - can you describe the person who has the problem?

Independent - does solving the problem create new ones?

Recurring - does the problem occur frequently?

Realized - do solutions for the problem currently exist?

Severe - how much is the problem costing someone?

Testable - how easily can the problem be validated?

Familiar

“Scratch your own itch”

Old adage

The founders of DoorDash knew little about food delivery, but they spent months interviewing restaurant owners before writing a single line of code.

Why all the effort? You’ll often hear, “Build for yourself” or “Solve your own problem.” That’s because when it’s your own, you have morning commuter-level insight—you deeply understand the job to be done. If it’s not your problem, having someone close to you such as friends or family is a bonus.

Whether you are on intimate terms with the problem or are a relative outsider, expect to spend serious time talking to people who live the problem every day.

Identifiable

“The riches are in the niches.”

Unknown

Sure, “Everyone likes milkshakes” might be true. But the level of customer clarity you should aim for is more like “morning commuters with 30+ minute drives.” Why?

First, you avoid wasting time and money building features no one asked for. Second, your customer acquisition costs drop because you know exactly where to find them.

I bet once the restaurant in Christensen’s story identified their customers, milkshake ads popped up all along major highways.

Independent

“The cure must not be worse than the disease.”

Proverb

You might think the iPhone was the first PDA (Personal Digital Assistant), but devices like Apple’s Newton and the Palm Pilot came before it. So why did the iPhone succeed where they didn’t?

Some credit the touchscreen and lack of a keyboard, but BlackBerry had already proved those weren’t dealbreakers. The real shift was wireless internet.

Early PDAs needed a computer to sync data—hardly “information at your fingertips” if you first had to get it there. Syncing was slow, clunky, and frustrating. (I say this as a former Palm Piloteer.)

By the time the iPhone launched, 3G had arrived and made syncing obsolete. The lesson: don’t solve one problem by creating another for your users.

Recurring

“What recurs, compounds.”

Observation

For afternoon parents, the milkshake was a convenient way to say yes after a week of telling their kids no. Every parent knows the relentless persistence of a child’s wants—this was an easy win on any given week.

Your problem doesn’t have to recur for the same customer. Take college test prep: students only face it once or twice, but there’s a fresh wave of them every year.

Solving recurring problems—especially for repeat or replenishing audiences—compounds in value over time.

Realized

“If there’s no competition, there’s probably no market.”

Chris Dixon - VC at Andreessen Horowitz

Most of us have an idea and immediately Google it or ask ChatGPT if it already exists. When we find it does, we move on. That’s a mistake.

Validating an idea or problem is one of the hardest—and most crucial—steps when making the leap. Competitors mean the problem is already validated. Your job is to figure out if your solution tackles it in a new way or serves a different audience.

Severe

“Be an aspirin, not a vitamin.”

Various

I take Vitamin C daily, but if I skip it, I don’t notice. Migraines, on the other hand, stop me in my tracks—and I reach for meds immediately.

The problem your idea solves likely falls somewhere between easy to forget and urgent relief needed. The closer it is to the latter, the better.

Testable

“No business plan survives first contact with customers.”

Steve Blank (startup legend)

In 2011, Color Labs raised $41 million for a photo-sharing app focused on large events. It shut down within a year.

Why? The problem—sharing photos during large events with nearby strangers—couldn’t be validated until the full product launched. Once it did, they discovered users didn’t care.

If you can’t validate the problem relatively quickly and cheaply, pick a different one.

The Next Step

Success doesn’t come from clever ideas—it comes from relentless focus on real problems.

To help you put FI2R2ST into practice, I’ve created a downloadable PDF with detailed problem validation questions you can work through on your own—or with your team.

You can download the FI2R2ST worksheet here.

My goal with The Leap is to provide you each Saturday with the knowledge, tools and lessons learned to help you get started and keep going toward building your future. 

Whether you are making the leap to startups, solo-entrepreneurship, freelancing, side hustles or other creative ventures, the tools and strategies to succeed in each are similar.