By Toon Timbermont in demand validation — 20 Dec 2025

Two Types of Lightbulb Moments: Solution vs Demand Thinking

Learn why solution-focused thinking drains budgets while demand-focused thinking builds sustainable products.

A few newsletters ago, I shared how a technically brilliant project—top-notch security, innovative architecture, ready for massive scale—saw usage stay far below expectations. We'd built something genuinely impressive. The problem? We never properly validated whether enough people would actually use it.

I keep seeing this pattern. In startups. In corporate initiatives. In my own work... People and Teams get so excited about what they could build that they skip over whether anyone would use it (and in commercial settings, pay for it).

In this issue, I'll make the difference crystal clear, explain the impact on your bottom line, and offer a systematic way to channel your team's builder energy towards early demand validation.

The Two Types of Lightbulb Moments 💡

When a new idea sparks, the room fills with energy. Whiteboards get covered. Slack channels buzz. Everyone's excited.

But not all lightbulb moments are created equal.

Moment 1: Solution Thinking

Listen to the statements flying around:

"We can build this solution"
"People will love this feature"
"Technology XYZ is great for this!"
"The architecture looks like..."
"We can do a marketing campaign on channel ABC"
"We can collaborate with..."

This is solution thinking. It's creative, energising, and feels like progress.

Moment 2: Demand Thinking

Now compare that to a different set of statements:

"I have problem XYZ"
"It really annoys me"
"I want to pay to solve it"
"I am not alone—there is an entire market of people like me"
"We are reachable"
"At a reasonable cost"

This is demand thinking. It's all about finding evidence about what (future) users actually need (and will pay for).

Both types of lightbulb moments generate excitement. Both feel like you're making progress. But they have very different financial consequences.

The Direction of Money 💸

Here's the critical difference: which way is money flowing?

Solution thinking = Money OUT

Every "we can..." statement becomes an expense line:

Defining the architecture → €€
Building the solution → €€€
Running marketing campaigns → €€
Establishing partnerships → €€€

Each brilliant solution thought is a cost waiting to happen. An outflow of money.

Demand thinking = Money IN

Validating demand reverses the arrows:

Customers with real problems → €€
Willingness to pay → €€€
Reachable market → €€
Sustainable unit economics → €€€

This is about money flowing toward your idea. Because you're searching for people who will actually pay for what you are (or will be) building.

The Financial Trajectory

The difference becomes painfully clear when you look at the financial trajectory over time.

Without demand validation:

Implementing your solutions will start burning your budget.

To cover up, you’ll spend time on finding budgets or organising external funding rounds. But there is a harsh reality. You're still burning through resources proving you can deliver a solution (output)—rather than very deliberately searching for proof someone will buy it (the outcome you really want).

You (as a smart reader ;) will of course notice there is no revenue on this diagram!! True. In your version, you’ll certainly have a revenue projection.

The Uncertainty Asymmetry 🎯

But there's a reality that is too often ignored: the uncertainty on each side is wildly different.

Think about it. For solution-focused output, your cost estimates are relatively predictable. If you have a mature, experienced team or proper advice, you can estimate architecture work, development sprints, and marketing campaigns with reasonable accuracy. You've done it before. The variables are known. Your confidence level is fairly high.

But demand and buyer behaviour? That's where the real uncertainty lives. Will customers actually pay? How many of them are there? Can you convert them cost-effectively?

Only real and targeted validation will raise the confidence level on the demand side to a level that will justify showing the revenue curve.

Not acknowledging this means making almost certain expenses while chasing low-confidence revenue.

With demand validation:

The thing is, you absolutely need the revenue side to get to a net-positive result, and only use the investments for what they are meant for: bridging the time lag between the cost of your work (creating output) and its effect on users' behaviour (the outcome you want).

So you’ll need to focus consistently on validating demand. To make the green line real, with a decent level of confidence in its future upward slope.

The difference isn't the initial investment. It's about how much time and money you spend building things without validated demand.

The Builder's Energy: A Strength, Not a Weakness 🔧

Now, here's an important nuance I don't want you to miss.

Solution thinking is not bad.

For many teams—engineers, delivery people, project managers—solution brainstorming is the motivator. It's why they got into this type of work in the first place. It's what gives them appetite on their next work day. The creative energy that flows when imagining architectures, debating technologies, and designing features is genuinely valuable.

I'm not suggesting you kill that energy. Please don't.

The problem isn't the solution thinking itself. The problem is sequencing.

When your team gets excited about solutions, do you have a systematic way to validate the demand upfront and select the solutions that will really move the needle?

If not, all that brilliant builder energy becomes organised spending without a clear path to desired outcomes. And if the budget that took you so much work to collect is gone without finding traction, (years of) your effort is down the drain…

A Systematic Approach 🎯

So before giving solutions all your energy and brainpower, put these demand-side questions at the top of your to-do list:

What specific problem are we solving? (Not "users will love this"—but the actual pain)
How painful is this problem? (Evidence, not assumption)
Are people willing to pay to solve it? (Reliable signals, not hopes)
How big is the market of people with this problem?
Can we reach them cost-effectively?
Can we solve it at a price they'll accept?

The good news is that this is exactly what you need to keep builder energy high in the long run.

Because better validated demand will create stronger traction once you put the right solution out there. And nothing is more motivating for builders than seeing their products being used.

And it goes on: a growing user base will give plenty of opportunity for architecture improvements, technology debates energising the team, new markets to be conquered and so forth.

The Lesson I Learned the Hard Way

Every "we can build..." moment feels like progress. The energy is real. The excitement is genuine. The technical challenges are intellectually satisfying.

But features without traction are just organised spending.

The point is not to have less builder energy—it is to channel it differently. To get just as excited about solutions. Once you have asked the demand questions first.

So - Are you spending money proving you can build, or proving people will pay?