A founder's framework

Most startups don’t fail because the product is hard to build or because of competition. Instead, they fail because the problem they try to solve isn’t painful enough.

None of this should be new. Anyone serious about building a company has already heard that. A startup is about solving a customer’s problem, talking to users and validating before building.

But here’s the thing, from my experience, most founders pretend to know all of that. But in practice, very few apply these rules.

Even worse, for me the problem is deeper. YOU are lying to yourself because you don’t really know what you want from your life yet, and that’s okay.

Every criterion listed below comes from a mistake I’ve made.

Over four ventures, I’ve shipped 5 applications to 3,000 different users and built multiple open-source packages downloaded more than 80k times in total.

Impressive or not, building and shipping was the easiest part. For me, the hardest part was understanding the customer’s problem and getting them to pay for my solution.

So, if you are about to start a company, use this as a checklist of the traps to avoid. It can save you the months I’ve spent building before validating.

Note that this is a living document, updated as I learn. So come back sometimes to see if things have changed :)

Getting the definition right

Everything developed below starts from one definition of what building a startup really is:

Solving a painful problem, experienced by people you understand deeply, in a big enough market, where your team has an unusually strong founder-market fit and a credible path to product-market fit.

Everything else in this framework unpacks it, phrase by phrase.

A cool technology, an interesting product, a trendy market or an idea that sounds impressive is not a startup.

If you don’t agree with this definition, then one of two things is true.

Either you can define it better, and your definition is worth sharing. Or you don’t really want to build a startup. You want something else, and that’s fine.

Journey to build a startup

Here’s the list of everything we’re going to cover.

  1. A painful problem
  2. A customer you understand
  3. A big enough market
  4. A team built to last
  5. A path to product-market fit

The checklist at the end sums it all up.

I. A painful problem

Problem before product

You should be able to describe the problem without mentioning the solution.

This is called a problem statement.

You may have seen this in entrepreneurial courses and thought it was bullshit. I thought so too. But then I understood its job was much deeper. The goal is to force you to name the pain before you picture the solution.

That shift changes what you do, who you talk to, and how you know you are going in the right direction.

To write a good statement, you need five answers about the problem:

Always remember that your goal is not to build a product. It is to prove the problem is painful enough that people will change their behavior to solve it.

And changing people’s behavior is very hard. People stick with the bad spreadsheet they know over the better tool they would have to learn.

To justify that, listen to Harvard professor John Gourville, who found that users overvalue what they already have by about three times. Even worse, people building a new product overvalue it by about three times.

Thus, a new solution has to be roughly ten times better to make people switch.

At this point, there’s no need to continue reading if what you want isn’t solving a painful problem, because being a founder is exactly this. If you prefer coding or building a product, join a startup that inspires you instead.

The pain must be real

As we say, a product is either a vitamin or a painkiller.

In short, a vitamin is something nice to take but easy to skip. On the other hand, a painkiller is something people go looking for and, more importantly, pay for the moment it hurts.

But how do we define pain? I’d say pain comes on a scale of five.

  1. nice-to-have
  2. useful
  3. painful
  4. urgent
  5. existential

Aim for painful or urgent. The others are often bad for startups:

As you can see, painful or urgent is the sweet spot. People run into the pain often enough to look for a solution, and are willing to try a new one.

A good test is to be able to answer the following question:

What does the user currently do because the product doesn’t exist?

If the answer is “nothing,” that’s a warning. But if they spend 10 hours a week on it manually, lose money over it, or pay someone to handle it, it starts to look like a real problem.

Dogfood and abuse doing it

Use your own product every day.

This is so important that a term even exists for it, it’s called dogfooding.

Living with the problem gives you instant feedback and an intuition about what matters that no interview can replace.

Always prefer businesses where you understand the problem yourself over ones where you need to keep asking users what they want.

This is the same as asking your friends at school to do the job for you because you can’t do anything. It works until you’re alone facing your fate.

Don’t get me wrong, customers are essential because they make the business generate profits. But ultimately, you have to make decisions to thrive in the long term.

II. A customer you understand

Founder-market fit

Founder-market fit means you are the right person for a specific market you chose.

I can think of three levels for a good fit:

Always prefer markets you are part of. This makes you credible from day one, without months of research, allowing you to go even faster.

For me, the strongest signal is having lived the problem many times and already built your own workaround. That beats anyone saying “I think this would be useful” or people pretending to know everything, which is just Dunning-Kruger doing its job.

Find 20 users in two weeks

Understanding the problem means nothing if you can’t reach the people who have it. Before building anything, you should ask yourself:

With zero product today, could I find 20 relevant users to interview within two weeks?

Prefer markets where users are reachable through professional networks, events, existing relationships, companies, search, partnerships, or physical locations.

Be cautious about markets where reaching users first requires building a community, an audience, or a new ecosystem. I’ve made that mistake multiple times.

So why shouldn’t you build an audience at first? Because building the audience becomes the job, and the REAL job, which is understanding and solving a painful problem, waits.

Even worse, most people it attracts come for the content, the community or the hype. Their feedback looks like validation, but believe me, it really is not.

Keep access to users

Finding users once isn’t enough either. Ten great interviews at the start get you a thesis, not a product. You need to reach the same kind of user again and again.

You will want to test your first draft with them, watch them use it, and ask why they stopped using it after a week.

Every step of building raises a new question, and only those users can answer it. If you lose access after the first round, you end up guessing, and guessing is how you build something nobody asked for.

So before you commit, ask yourself whether you will still be able to talk to these people in six months and preferably every week if possible.

The ideal market gives an ongoing loop: problem, hypothesis, interview, new hypothesis, experiment, feedback, iteration.

The opposite is building, launching, hoping users show up, and only then trying to understand them.

III. A big enough market

Size it bottom-up

The market sets the ceiling on what great execution can reach. For example, the best fisherman in the world still can’t catch more fish than the lake holds.

And also, “big market” doesn’t mean a big TAM slide.

The question is deeper:

If you execute extremely well, can this become a very large company without changing markets completely?

For a venture-scale company, the minimum bar is a credible $1B+ TAM with a realistic path toward $100M+ in annual revenue.

Don’t trust big claims like “the restaurant industry is worth hundreds of billions.”

Count it yourself, customer by customer: number of customers × what each one pays per year

Take the restaurant example:

The $1B goes on the pitch deck. The $100M is the real size of your lake.

A small lake can still be worth fishing if it is filling up fast, flows into a much bigger one, or holds more fish than everyone thinks. If you make that bet, write down why you believe it.

Oh, and replace the lake with the market. I’m talking about market growth of course.

The market must grow

Look for a market where the underlying need is becoming more important. That can come from new technology, new regulation, demographic shifts, new behaviors, or people willing to pay more for any reason.

But you should be able to answer this question and justify it:

Why is this problem going to become more important over the next 5 to 10 years?

Answering this question will help you and make raising funds from investors easier, as they will ask you this.

And remember what path you chose. A stagnant market requires stealing customers. A growing market creates new ones.

Never depend on one platform

If the business depends on a single platform, or the market carries too much regulatory uncertainty, don’t go.

Thank me later. For one of my startups, a single clause in a platform’s terms of service was enough to kill our company.

IV. A team built to last

Every founder talks to users

You and every founder should take part in interviews, user calls and observations. Basically, everyone should hear the problem from users firsthand.

This prevents one person from becoming the sole source of “customer truth.”

No technical black box

The same goes for tech. It shouldn’t rely on one person.

Some teams love to rely on one technical co-founder. The famous commercial + tech incredible teams.

Teams where the technical co-founder masters the details.

But I strongly disagree with this. EVERYONE should understand how the system works, the critical parts of the architecture, what’s hard vs what’s easy, and where the technical risks are.

Otherwise, people making decisions can’t see the risk coming, and these people are all the founders.

Take the example of Friendster. As the site grew, pages became painfully slow, but the board kept pushing new features and deals instead of fixing the infrastructure. Thus, users left for MySpace, and Friendster never recovered.

For deeply technical products, like an API or infrastructure, this is even more non-negotiable since the product is mostly the technology.

If that’s not enough, look at who runs the biggest tech companies. Many of their CEOs are technical experts too: Patrick Collison (Stripe), Tobi Lütke (Shopify) and Drew Houston (Dropbox) all started as programmers.

So if you are not technical, start learning now. It matters even more now that we have AI tools. When anyone can generate a product in a weekend, the edge goes to people who master complex things others don’t understand.

My take is that the best CEOs will be the ones who see what others can’t, and being technical is one pillar of that.

Agree before starting

Before starting, you and your co-founders should explicitly agree on:

Have the difficult conversations now. “We’ll figure it out later” usually means fighting about it later, under pressure.

Ask any AI to generate a checklist from this paragraph and it should one-shot something sufficient, but just do it.

Complementary, not siloed

A good founding team covers different ground.

One of you is strong in product, another in engineering, another in sales or in the domain itself. Great, but not sufficient.

Of course, the worst case is two engineers alone who will build a great product nobody hears about. Or, two salespeople alone will sell something they can’t build.

But different strengths should not become separate worlds. In a siloed team, the engineer never hears a customer, the salesperson promises features without knowing what they cost, and each side blames the other when things slip.

To avoid it, share the work that matters. Join customer calls together, review the product together, and explain your decisions to each other until everyone could defend them.

Protect health and learning

I can’t insist enough on this one. Keep a sane baseline of sleep, physical activity, nutrition, relationships and time away from work.

Don’t fall for the FOMO of founders bragging about 100-hour weeks. The pragmatic choice is to stay healthy to perform better.

Working less is often working better on more important tasks.

If you can’t and find yourself working more and more, it means one of two things:

Never try to beat this by pushing harder. Accept it, and adjust.

Knowing all this is not enough. It has to be protected by structure because it’s hard to stay pragmatic.

One solution worth trying is an hours model close to a salaried job, with a start and an end to the day. A bounded schedule protects sleep and sports by default, and forces you to work better, not more.

There is no point in being wealthy or building a great company if you lose your health, or die young, on the way.

Another important topic is to always keep learning. It can feel like time taken away from the company, but it makes you better every day.

It helps you rethink your priorities in business and personal life, and more importantly, it compounds. In the long term, it is what lets you work less, not more.

Warren Buffett spends most of his day reading. Bill Gates disappears twice a year for Think Weeks, alone with a pile of books.

Finally, rest. Most of what people call rest is not rest. An hour of doomscrolling leaves you more tired than before.

Positive entertainment is different. Books, manga, webtoons, movies, good YouTube videos, art and music leave something behind, a story, an idea, a skill.

Even video games count, as long as they are great ones. Not the games designed to keep you hooked, but paid games made by people who care.

If I showed you my screen time, you would see almost no social media, and hours of books, webtoons and YouTube videos. Change your habits.

V. A path to product-market fit

Follow the stages

Think of the old master in martial arts films who makes his student repeat boring chores for days.

The student wants to learn the flashy moves right away. Only later does he realize every chore was building the skills he needed to fight.

A startup works the same way. Each stage builds what the next one depends on. And skipping one leaves a gap you pay for later, like a debt.

Remember, in the early stages, your job is not to build a company or a product. Your job is to learn whether the problem is real and craft the best solution to fix it.

That is the core idea of the Lean Startup philosophy. Everything you believe about your business is a guess until the market proves it.

So you build the smallest thing that can test a guess, measure how users react, and learn whether to keep going or change course. Then you repeat that loop, and you only invest more once the evidence says yes.

Skipping a stage almost always means investing money and time in something you haven’t validated. Six months of development on a problem nobody confirmed is six months you don’t get back. Competitors may take the market before you within that time.

However, there are rare exceptions. This is what we call “fat startups”. They raise big money early and build heavily before validating, like hardware or deep tech companies that can’t test cheaply. But, if you are reading this, you are most likely not one of them.

At any moment, you should know which stage you are in and what must be proven before moving on. The Lean Startup path has three:

  1. Problem-solution fit. Pick a specific customer segment, validate the problem through interviews, understand the existing alternatives, and test whether people would pay for your idea. You are done when customers describe the problem without prompting and commit to trying your solution, with a preorder, a pilot or a letter of intent.
  2. Product-market fit. Build the smallest possible solution and put it in real hands. You are done when users come back on their own, pay, and would be upset if it disappeared.
  3. Scale. Build a repeatable sales and acquisition process, then grow. You are done when each new customer brings in more than they cost, and growth becomes predictable.

More importantly, each stage is a learning process, not a box to tick.

Finally, if you feel like skipping a stage, it usually means you don’t see its purpose yet. Stop and ask yourself why it exists before moving on.

Roles should come late

Titles like CEO, CTO or CMO mean little at the beginning. And anyway, most early teams don’t have the experience to fill them yet, and that’s perfectly normal.

The needs also change constantly. In the first month, the company needs interviews, the next month a prototype, and the month after that its first sales.

A role fixed on day one describes a company that doesn’t exist yet. Titles only start to mean something once the company grows and the work becomes stable enough to DIVIDE.

So, instead of handing out titles, focus on solving the problem. Let roles emerge from what the company actually needs, and from what each of you turns out to be good at.

The best startup cultures work this way. A problem belongs to whoever can solve it, not to whoever holds the title.

To convince you, take a look at Tesla. Elon Musk told employees that anyone can and should talk to anyone else, skipping the chain of command, if that is the fastest way to solve a problem.

At Stripe, the Collison brothers didn’t wait for a sales team. When someone agreed to try Stripe, they would say “Right then, give me your laptop” and set it up themselves.

Everyone should help, not only engineers. The CTO joins sales calls, the CEO answers support tickets, and nobody says “that’s not my job.” Put your ego aside. The company doesn’t need your title. It needs the problem solved.

So you may ask, why give titles at all? My reason is that it’s mostly cultural and convenient. A title is a shortcut that tells people roughly what you do in one word.

Explaining your actual week to your friends would take ten minutes. Saying “I’m a full-stack developer” takes two seconds.

A checklist to apply the framework

Do it with your co-founders before starting. Tick a box only if you all honestly say “yes.”

A painful problem

A customer you understand

A big enough market

A team built to last

A path to product-market fit

If you cannot confidently answer these questions, try to understand the issues and fix them.

The goal is not to predict that a company will succeed. It’s to make sure you avoid the traps that can cost you years of your life and make you fail the goals you set for yourself.