Logo

A founder's framework

After killing my company, I decided to define the criteria I will hold myself to so I do not repeat the mistakes I made: the market, the product development, and the team. I will keep it up to date as I learn.

It is a kind of summary of what we did well and what we did bad, and from these experiences I build my own framework.

I also think what I learn may serve other founders who wish to launch their own company. This is of course based on my own experience, but I doubt I'm the only one experiencing this.

The philosophy

I am not looking for:

I am looking for:

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

The parts

The framework is organized in nine parts:

I. Market

1. Strong founder-market fit

Ideally, all founders should have a founder-market fit with the market:

The ideal situation is when the founders are themselves members of the target market, able to understand the user's problem without months of research to become credible.

A strong signal is when most of the founders have personally experienced the problem, ideally all of them. An exceptional signal is when they have experienced the problem repeatedly and already built their own workaround. That is stronger than someone saying "I think this would be useful."

2. The market size should be big enough

"Big market" should not mean a big TAM slide. The question is:

If the team executes extremely well, can this become a very large company without changing markets completely?

For a venture-scale company, my minimum bar is a credible $1B+ TAM with a realistic path toward $100M+ in annual revenue. But the calculation I trust more is bottom-up:

potential customers × realistic annual revenue per customer

For example, 500,000 potential customers each paying $2,000/year is a $1B market on paper. That is the TAM: everyone who could theoretically buy. The next step is to shrink it to the SAM, the portion of that market the company can realistically serve and reach. This is where small markets get exposed. If the reachable market is only $100M, then even winning an unrealistic 50% of it produces just a $50M business. Too small.

TAMs are too easy to inflate. Forcing myself to model customers × price × achievable penetration makes the discussion concrete.

One exception. A smaller market can still be attractive if growth is extremely fast, the market is structurally expanding, the initial market is a wedge into a much larger adjacent one, or the market is underestimated. But then I should write down why I believe the market will become much larger.

I should also take the risks into account. If the business depends on one platform only, or if the market carries too much regulatory uncertainty, don't go. We learned this one the hard way: a single clause in a terms of service was enough to kill our company.

3. Market growth matters

I don't only want a large market. I want a market where the underlying need is becoming more important: secular growth, technological change, regulatory change, demographic change, new behaviors, increasing willingness to pay, increasing urgency.

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

A stagnant market requires stealing customers. A growing market creates new ones.

II. The problem

4. Start with a problem, not a product

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

Bad: "We should build an AI platform for X."

Good: "People who do X struggle with Y because Z."

Before talking about features, technology or architecture, I want to know:

The initial objective is not to build a product. It is to prove the problem is painful enough that people will change their behavior to solve it.

5. Dogfooding should be possible

Dogfooding is the best way to make a successful company for me. Ideally, all founders are users of the product.

Why? Because dogfooding gives:

I am suspicious of businesses where the founders need to repeatedly ask users what they want because they don't understand the problem themselves.

6. The pain must be real

There is a scale: nice-to-have, useful, painful, urgent, existential. I strongly prefer painful or urgent. A good test:

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

If the answer is "nothing," that's a warning. If the answer is:

then it starts to look like a real problem.

7. Users must be easy to find

This one comes directly from our experience. We came from a web3-like market. Getting users from Discord and into interviews was difficult, so we iterated the bad way: building a product to attract users, and getting lost in building a product rather than finding product-market fit and answering a problem.

So I should be able to identify and reach potential users before building the product.

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

And ideally, 100+ people with the problem, without having to build an audience first.

I prefer markets where users are reachable through existing professional networks, communities, companies, industry events, existing relationships, search, partnerships, or physical locations.

I am cautious about markets where acquisition depends on creating a community first, building an audience, going viral, convincing people to join a new ecosystem, or building a product solely to attract the people I want to interview.

Why? Because it wastes time on something that is not solving the problem. Building the audience becomes the job, and the real job, understanding and solving a painful problem, waits. And the people it attracts are not necessarily people with a painful problem. They come for the content, the community or the hype, and their feedback looks like validation when it isn't.

I should be able to talk to users without building the product first.

8. Users should be reachable repeatedly

Finding users once isn't enough.

Can I keep continuous access to the same category of users through the entire product-development process?

The ideal market gives an ongoing loop: problem, interview, hypothesis, experiment, feedback, iteration. Not: build, launch, hope users appear, try to understand them. We lived the second one. Never again.

III. Product development

9. Follow the stages

Have a well defined process and follow carefully the classic stages of a startup. The team is answering a user's pain, not making a company or building a product at first. For example, following Disciplined Entrepreneurship, Lean Startup, Customer Development, or Jobs-to-be-Done. The exact framework matters less than the discipline.

At any moment I should know what stage the company is in and what must be proven before moving to the next one. For example:

  1. Identify a problem
  2. Identify a specific customer segment
  3. Validate the problem
  4. Understand existing alternatives
  5. Formulate hypotheses
  6. Test willingness to pay and behavior
  7. Build the smallest possible solution
  8. Validate product-market fit
  9. Build a repeatable sales and acquisition process
  10. Scale

Founders should always try to understand the stage they are in and what they are trying to do in it. Each stage is a learning process, not a box to tick. Wanting to skip a stage is a signal in itself: it could mean the team doesn't understand its purpose, and in that case the work is to go back and rework why this stage is necessary after all.

When the team blocks, it should ask whether the blocker is critical, meaning it invalidates the whole business idea, or whether it can be avoided. And to answer that, the focus should be on solving the stage, not on advancing to the following one.

10. Roles come late

I am talking about the role of each team member. Titles like CEO, CTO, CFO or CMO don't mean anything at the beginning, especially when most of the members don't have much experience. A team of fresh graduates won't have deep expertise yet, and that is perfectly normal.

So instead of trying to divide tasks and hand out titles, focus on executing and solving the problem. The role of each member should emerge from what the company actually needs, not from a title decided on day one.

IV. Founder involvement

11. All founders talk to users

All founders should take part in user interviews and discussions: interviews, user calls, observations, customer discussions, product decisions. No founder should be separated from users. Every founder should personally hear the problem from users. This prevents one founder from becoming the sole source of "customer truth."

12. Tech should not rely on only one founder

Tech shouldn't rely on only one founder, in the sense that the others should have a minimum intuition and know how to build the thing.

This does not mean mastering every implementation detail. Everyone should understand how the system works, the major technical constraints, the critical architecture, what is difficult vs easy, what can be outsourced, what creates technical risk, and what the major trade-offs are. The technical founder should be substantially stronger and master the details.

How strict to be depends on the market and the product. For deeply technical products, like an API or infrastructure, this is non-negotiable: the product is the technology, and a founder who cannot reason about it cannot make good decisions. For less technical products, the bar can be more relaxed.

The best CEOs prove this is possible. Patrick Collison runs Stripe and is a programmer. Tobi Lütke runs Shopify and contributed to Ruby on Rails. Jensen Huang runs NVIDIA and is an electrical engineer. Drew Houston wrote the first lines of Dropbox himself. Being CEO doesn't mean giving up technical depth. It means using it to make better decisions.

13. Founders should be capable of building, not merely managing

A right founder should excel everywhere but not have the time to focus on everything. Think of Bill Gates, Elon Musk, Mark Zuckerberg having a profound understanding of their product and users. The ideal founder isn't the person doing every task. They understand enough about users, technology, product, business, distribution and economics to make excellent decisions across the company.

Specialization should determine where founders spend their time, not what they are capable of understanding.

A founder can say "I don't have time to do this." They shouldn't say "I don't understand this part of our company."

V. Founder quality

14. Never stop learning

Founders should never stop learning. Executing and producing is good, but on the long term what pays is what a founder still learns. The best entrepreneurs read a lot and still learn a lot. Warren Buffett spends most of his day reading, and Charlie Munger called him a learning machine. Bill Gates disappears twice a year for Think Weeks, alone with a pile of books. It's like building wealth: investing money at the beginning of the month builds wealth over time, and the same goes for knowledge and skills.

Every founder should protect time for their own long-term growth. For example, reading, technical learning, talking to experts, studying markets and competitors, learning new tools, improving leadership and communication, developing domain expertise.

But learning is not the only input that matters. Positive entertainment counts too: reading mangas, watching movies, going to an art exposition, making music. These activities feed curiosity, creativity and taste, and they recharge the mind in a way pure work never does.

Don't get me wrong: scrolling on TikTok or Instagram is not positive entertainment. It is passive consumption designed to capture attention, and it will never be productive. The difference is simple. Positive entertainment leaves something behind: a story, an idea, an emotion, a skill. Doomscrolling leaves nothing.

The goal isn't consuming content for its own sake. The goal is increasing the capability and the richness of the founder over time. Capabilities should compound just like capital does.

15. Keep the execution quality

Learning cannot become an excuse for low execution. Every founder should hold a sustainable rhythm: learn, decide, execute, measure, learn again.

If someone consistently cannot follow the rhythm or keep up with the day to day job, the way of working is not good, and the team should find out why. The answer shouldn't automatically be "work more." First look at prioritization, focus, working methods, communication, delegation, organization, health, energy, unnecessary work.

Optimize productivity before optimizing hours.

VI. Life and sustainability

16. Founder health is part of the company

Having a good life hygiene is extremely important. A founder should keep a sane baseline of sleep, physical activity, nutrition, mental health, relationships, and time away from work. Doing sports is strongly preferred, but at least work in a sane environment, for mental health and quality of work.

I say this because I failed at it. I stopped taking time for sports and good sleep, even though I understood the necessity of it. Understanding is not enough. It has to be protected by structure.

One solution I want to try: following an hours model close to a salaried job, with a start and an end to the day. It sounds counterintuitive for a founder, but a bounded schedule protects sleep and sports by default, and it also forces a founder to work better, not more.

A company that destroys its founders is not a successful company.

Founders are choosing to spend years together. The working environment should let them remain effective for years, not just survive six months of intense effort.

VII. Team dynamics

17. Agree on the philosophy before starting

Before starting, all founders should explicitly agree on:

Do not postpone difficult conversations because "we'll figure it out later."

18. Complementarity without silos

Complementary strengths: product, engineering, sales, distribution, domain expertise, operations. But complementarity should not mean silos. Everyone should understand the whole company.

Different areas of excellence, shared understanding of everything.

19. Genuinely enjoy working together

This sounds less analytical, but it matters enormously. The questions I ask myself:

Would I willingly choose these people again if I were starting from zero?
Do I trust their judgment when I strongly disagree with them?
Can I have difficult conversations with them without damaging the relationship?

A startup amplifies existing founder dynamics. If something is mildly annoying before starting, it may become unbearable under pressure.

VIII. My requirements

Based on my previous companies, I explicitly want to avoid:

  1. Building before finding users. If I cannot identify and speak with users, I don't build.
  2. Building to attract users. Never create a product merely because I don't know how to reach users.
  3. Mistaking engagement for pain. People joining a Discord, liking something, or saying something is "cool" is not evidence of a painful problem.
  4. Falling in love with technology. Technology is an enabler. It isn't the problem.
  5. Premature product definition. Don't spend months defining the product before proving the underlying problem.
  6. Founder silos. No founder disconnected from users, product or technology.
  7. Skipping validation because I can build quickly. Being able to build something quickly makes it more important, not less, to validate before building.
  8. Confusing activity with progress. Shipping code is not necessarily progress. Progress means reducing uncertainty.

IX. The ultimate checklist

Before committing to a new company, I want the whole founding team to be able to answer "yes" to most of these.

Market

Problem

Product

Founders

Long-term

If I cannot confidently answer these questions, I shouldn't start building yet.

The goal is not to predict that a company will succeed. The goal is to make sure that, before committing years of my life, I have earned the right to take the next step.

Sources

I can't list everything. Many, many books and readings shaped my current philosophy. But these are the essential reads: