"Am I building the right thing?"

In this post I'm going to introduce a very simple yet powerful framework that, I believe, separates products that grow from products that struggle. So stick with me here.

"Am I building the right thing?"

This question came up few days ago in a convo with a solo founder.

He's still in the early stages, his app is getting traction and very positive reviews from very enthusiastic early adopters. All good, right?

Yet he keeps doubting because he is in a very niche market with established, dominant players that are here from ages. And his vision is to "de-dustize" the industry with an app that's much more well designed, offering a much more efficient and reliable way of doing the main job it's designed around. He also takes a new "emotional, story-driven" approach to how he builds his features.

This strongly differentiates his product, but that's as good as it's tricky.

This vision (i'm staying elusive on purpose) drives the features he ships. Because he ships quick and often, he sees what resonates and what doesn't. But he only gets feedback from his current user base. And because his product has a big part of innovation, he's unsure whether he'll be able to conquer the hearts of many more users.

I call this the "researcher vs visionary" dilemma.

When you want to innovate, I believe you have to be willing to take some risks, and draw the map as you navigate. You're not safe from hitting big rocks during your exploration (i picture a boat on a nasty ocean, do you?).

And to answer the "am I building the right thing?" question, the safest playbook here is to ship -> learn -> iterate as frequently as possible.

The biggest risk is spending a lot of time (and money) into building something following your vision, in your cave, without testing the waters early on (to stay with the ocean metaphor). I've fallen into this trap more than once, and I know founders who are in it... as I'm writing these lines. And I sincerely hope when they ship, they don't hear crickets.

Which leads us to the second type, the researcher type, which I tend to prefer much more as it feels less innovative, less visionary, but more likely to succeed.

In the end, a successful SaaS product has much more chances of succeeding if it solves a real problem than if it tries to bring something new to people... but something they don't really need.

But looking for problems — a very common playbook — isn't enough. And this was a BIG unlock for me.

You actually have to find problems people are actively looking to solve. That is the difference between building a product that may be great and immensely valuable, but nobody will care about, vs building a product that people will "rip out of your hands".

Rip. Out. Of. Your. Hands.

This language is not from me. It's from Rob Snyder, one of the people who influenced me the most in the past years.

Rob is a founder and advisor, and he has helped 30+ startups go from $0-$1M+ ARR, including $0-$25M ARR in 2 years and $0-$6M ARR in 8 weeks. That's worth considering, don't you think?!

There's 2 things I hugely recommend to you:

1. his newsletter The Physics of Startups (brilliant)
2. the deceptively simple but so powerful framework he came up with: "PULL"

Introducing Rob Snyder's PULL framework

Rob's thesis is simple:

What we call user goals and needs is demand.

And the products they hire to achieve these goals and fulfil those needs are supply.

Rob says demand and supply are actually independant from each other. Demand exists on its own, and isn't influenced by supply. And the products who win are the ones who provide a supply that fits the existing demand of users.

Put simply (but I strongly recommend you dig deeper on Rob's newsletter), if you want to build a product people will rip out of your hands, you have to first obsess on the demand side, and infer what you need to build to fit that demand, instead of starting from the supply side and trying to make the demand fit it.

So the playbook is:

1. you craft a PULL hypothesis
2. you validate it in target user interviews
3. you build your product based on it, not your vision

Let's break the PULL framework down, shall we?

P = project: the potential user has a project in their mental todo list. Something precise they want to accomplish

U = urgent: and that project is urgent/unavoidable right now, because X,Y or Z.

L = list of options: they have already tried or considered solutions to accomplish their urgent/unavoidable project...

L = limitations: but those options have limitations that make them not good enough (even sometimes, painful).

Here are 2 visuals from Rob himself (Rob I'm giving you full credit here, and am only using these because they're publicly available on your Substack):

I'll stop here and let you dig deeper on Rob's Substack, but this framework literally exploded my brain. 🤯

(I still have goosebumps)

Because when you know a specific user persona has a specific goal (Y) they want to achieve, and that this goal is urgent, and when you also know why what they already tried didn't work or wasn't good enough because of (Z)...

and you say to them: "So if we offered X that helps you accomplish Y without Z..."

How likely do you think they would be to NOT pull out their credit card and ask you "where do I sign up?"

In conclusion,

As a product designer I believe innovation matters A LOT.

People like Steve Jobs were visionaries who had the thing. They saw the future and knew what to build before people even realize they needed it. But I believe that's rare. And for the rest of us, a much more humble yet probing way is to obsess over the people we want to serve with our products, and have a clear picture of what their demand is, so we can infer what the supply should look like.

And innovation still has its place in this process. Studying demand tells us what to build. Creativity and innovation can help us find how to build it.

I hope this was helpful, and I hope it sparked some thinking.

And if you'd like to debate on this, please reach out!

PS_

Editing this post as Rob just wrote a post + few slides on LinkedIn that encapsulates his entire approach. A great way to get introduced to his universe.