Logo

A founder's framework

This is not an essay. This is a living document. We killed our company with my 2 co-founders, and before making a new one, I want to define what is important to me when choosing the market, the project, 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 product and the company come later.

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 being ourselves members of the target market. I should be 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 we have experienced the problem repeatedly and already built our 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 we execute 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 at $2,000/year is a $1B theoretical market. Then go from TAM to SAM to the realistically reachable market. If the realistic SAM is $100M and I would need 50% market share to build a $50M business, it is 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 gives you customers.

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 you need to repeatedly ask users what they want because you don't understand the problem yourself.

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. We are answering a user's pain. We are 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 we are 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. Establish repeatability
  10. Scale

We should always try to understand the stage we are in and what we 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 we don't understand its purpose, and in that case the work is to go back and rework why this stage is necessary after all.

If we block, we 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. Scope comes late

I am talking about the scope 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 scope of each member should emerge from what the company actually needs, not from a role we 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. My rough target: each founder should have at least 75% of the skills needed to build the product technically.

Not 75% of 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 substantially be stronger and master every details.

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 we spend our time, not what we 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 you still learn. 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.

My baseline: 10% of the time dedicated to the long-term growth of the individual. Reading, technical learning, talking to experts, studying markets and competitors, learning new tools, improving leadership and communication, developing domain expertise.

The goal isn't consuming content. The goal is increasing the capability 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 we 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 you to work better, not more.

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

We are choosing to spend years together. The working environment should let us 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 we were starting from zero?
Do I trust their judgment when I strongly disagree with them?
Can we have difficult conversations 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 scope. 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 we 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 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: