Most early products don’t die from a bad idea or a bad competitor. They die quietly, from a founder who stopped: stopped shipping after a flat launch, stopped talking to users after a few awkward calls, or spent four months polishing something nobody had asked for because building felt safer than selling.
That is a mindset problem, but not the kind a quote on a wall fixes. It is fixed with a few concrete habits: a way of framing what you are trying, a way of making decisions without waiting for certainty, a plan for the weeks that go badly, and a rhythm that makes progress the default. This guide gives you each one, with an exercise to do as you go.
What a founder mindset actually is
Strip away the hype and a founder mindset is the ability to act well when you don’t know the answer yet. Employees mostly work on problems someone has already framed. Founders work on problems where nobody knows whether the customer exists, which feature matters or what the price should be, and they have to keep moving anyway.
It comes down to four habits, and the rest of this guide takes them one at a time:
| Habit | Instead of | Looks like |
|---|---|---|
| Think in bets | “This will work” | A written guess, the signal that proves it and a date |
| Decide by reversibility | Waiting until you’re sure | Small calls in minutes, big ones on paper |
| Recover on purpose | Taking every setback personally | Treating silence and rejection as data about the message |
| Build on a rhythm | Working when you feel like it | Something visible shipped every week |
None of these needs you to feel confident. Confidence is what you get after a few months of the habits working, not what you need before you start.
Think in bets, not certainties
“I’m building an invoicing tool for freelancers” is a plan. It has no way to be wrong, so it can’t teach you anything, and it quietly turns every bad week into a referendum on you. A bet is a plan that can be wrong:
We believe [who] will [do what] because [why]. We’ll know we’re right when [a signal you can count] by [a date]. If we don’t see it, we will [narrow / change / stop].
A filled-in one:
We believe freelance designers will pay $12 a month for automatic payment reminders, because chasing clients is awkward and costs them real money. We’ll know we’re right when 5 of the 40 designers on our waitlist pre-pay by 30 November. If we don’t see it, we will interview the 10 most active sign-ups and test agencies instead.
Writing it this way does three things:
- It tells you what to do this week. The bet above means emailing forty designers with a payment link, not redesigning the dashboard.
- It separates you from the outcome. A bet that loses is a result, not a verdict on you. You learnt something for the price of a few weeks.
- It sets the exit before you are attached. Kill criteria are easy to write on day one and almost impossible to write on day ninety, after you have sunk months into the work.
Judge the decision, not just the result
Poker players have a name for judging a decision only by how it turned out: resulting. A good bet can lose and a bad one can win. When a launch goes well, ask whether you made good calls or got lucky; when it goes badly, ask the same question. Only the calls are yours to repeat or fix.
Do the founder’s job, not the comfortable one
Most founders start as makers, and making feels like progress. Code compiles, designs get prettier, the to-do list shrinks. But early on, the work that moves a product is mostly uncomfortable: messaging strangers, asking for money, reading why someone churned. Without noticing, it is easy to spend the whole week on comfort work: real tasks, chosen because they avoid the scary ones.
Run this audit on last week. Put every block of time in one of four columns:
| Column | Counts | Examples |
|---|---|---|
| Learn | Contact with real or likely customers | Interviews, reading support messages, watching someone use it |
| Sell | Putting the product in front of people and asking | Outreach, posts, demos, a launch, a pricing page |
| Build | Work a user asked for or a bet depends on | The feature three customers mentioned, fixing onboarding |
| Comfort | Work nobody is waiting for | Refactoring, a new logo, a fifth settings page, tool shopping |
Before you have paying users, aim for at least a third of your hours in Learn and Sell combined. If Comfort is your biggest column, you haven’t found a productivity problem. You’re avoiding something, and naming it is usually enough to start.
Make better decisions, faster
Founders make hundreds of decisions a week with half the information they would like. Slow decisions are the hidden cost: a week spent choosing a pricing model is a week no customer saw a price. The fix is not to decide everything faster. It is to decide the small things much faster, so you have time to think about the few that matter.
1. Sort by reversibility
Jeff Bezos’s 2015 letter to Amazon shareholders split decisions into two types. One-way doors are hard or impossible to undo, so they deserve slow, careful thought. Two-way doors can be walked back through if you’re wrong, so they should be made quickly, by whoever is closest to the problem. Most early-stage decisions are two-way doors pretending to be one-way doors.
| Decision | Door | How long to spend |
|---|---|---|
| Landing page headline, launch day, a feature’s first version | Two-way | Minutes. Pick one, ship it, watch what happens |
| Price for the first customers, which channel to try first | Two-way, but slower to undo | An hour, plus a date to review it |
| Co-founder split, raising money, quitting your job, a long contract | One-way | Days. Write it down, sleep on it, ask two people |
2. Decide at about 70%
In his 2016 letter, Bezos added that most decisions should be made with around 70% of the information you wish you had; waiting for 90% usually means being slow. For two-way doors, ask: what is the cheapest way to find out? Very often it is to decide, ship and look at the result, which gets you the missing 30% faster than more thinking would.
3. Run a pre-mortem on the big ones
The psychologist Gary Klein’s pre-mortem works because it gives you permission to be pessimistic. Before a one-way decision, imagine it is six months later and it went badly. Write down every reason why, for five minutes, without filtering. Then fix the two most likely causes before you commit, or decide the risk is worth it with your eyes open.
4. Keep a decision log
Memory rewrites itself to make you look smart. A short log makes it honest and lets you see, after a few months, which of your instincts are good. One line per decision that took more than an hour:
Date: 2 November Decision: Launch on LarkLaunch on Monday 9 November, without the team plan Options considered: wait for the team plan (3 weeks) / launch the solo plan now What I expect: 150 visitors, 20 sign-ups, 2 people asking for teams Confidence: 60% Review on: 23 November
When you review it, don’t only ask whether you were right. Ask whether the reasoning was good with what you knew then. That is how judgement improves.
When the hard part is choosing between several good ideas rather than one decision, score them with our free RICE prioritisation calculator so the conversation is about reach and effort, not about which idea you like most.
Seven traps that stall founders
These come up for almost everyone. The aim is not to never feel them; it is to recognise them quickly and have a move ready.
1. “It’s not ready yet”
What’s going on: launching makes the product judgeable, and polishing postpones the judgement. The move: set a launch date now and work backwards from it. The bar for a first launch is “solves one problem end to end for one kind of user”, not “finished”. If you aren’t a little embarrassed by version one, you probably waited too long. Our launch week guide turns the date into a plan.
2. Silence after you put it out
What’s going on: no replies, few upvotes, an empty analytics chart, and it feels personal. The move: silence is data about the message or the channel, not about you. Change one thing at a time (the headline, the audience, the place you posted) and count again. Twenty cold messages with no reply means the message is wrong; it says very little about the product.
3. Rejection
What’s going on: every “no” is filed as proof the idea is bad. The move: ask every no for one sentence of why, then sort the answers. “Not now”, “not for me” and “not at that price” are three different problems with three different fixes. A no with a reason is worth more than a polite yes.
4. Comparing yourself to other launches
What’s going on: you see another founder’s best day next to your average one, and their posts leave out the two years before. The move: compare yourself to your own last month. Track three numbers that you control (see the rhythm below) and judge the trend, not the snapshot.
5. Idea hopping
What’s going on: a new idea always looks better than the current one, because it hasn’t met reality yet. The move: commit to one bet for a fixed cycle, six weeks is a good default, and keep a “later” list. New ideas go on the list, not into the week. At the end of the cycle, the list competes fairly with the current bet.
6. Doubt that you are the right person
What’s going on: you are doing many jobs for the first time, and every one of them feels like faking it. The move: keep an evidence file: screenshots of a kind message, the first payment, a bug you fixed in an hour that once took a day. When the doubt shows up, read the file. Feelings argue badly with facts you wrote down yourself.
7. Ignoring bad news
What’s going on: the more you have put in, the harder it is to see that a bet isn’t working. Economists call it the sunk cost fallacy. The move: go back to the kill criteria you wrote with the bet, and ask one question: “Knowing what I know now, would I start this today?” If the answer is no, the months already spent are not a reason to spend more.
Build consistently: a weekly rhythm
Motivation is unreliable. It is high on launch day and gone by Thursday. A rhythm keeps going when motivation doesn’t, because it turns “what should I do?” into “what does today’s slot say?”. Here is one that works for a solo founder or a small team, on full-time or evening hours:
| When | What | Time |
|---|---|---|
| Monday | Pick the week’s one outcome and at most three tasks that get you there. Check them against the bet. | 30 min |
| Every working day | One protected block on the outcome, before email and chat. Notifications off. | 90 min |
| Every working day | One customer touch: a reply, a message, a call, a support ticket read properly. | 15 min |
| Friday | Ship something visible, then run the weekly review below. | 45 min |
Ship something visible every week
“Visible” means someone outside your head can see it: a changelog entry, a post about what you learnt, an email to your users, a small feature live in production. It does three jobs at once. It forces work into finished pieces, it builds a public record that compounds into an audience, and it gives you a weekly win you can point to on the bad weeks. The LarkLaunch feed is a good place to post it, among other makers doing the same.
Track inputs, not just results
Sign-ups and revenue lag weeks behind the work. Inputs show you whether you are doing the work at all. Track three each week:
- Conversations held with users or likely users
- Things shipped that a user could see
- Asks made: for a sign-up, a payment, a referral, a review
If inputs are high for six weeks and results don’t move, the bet needs to change. If inputs are low, you don’t need a new bet, you need the rhythm back.
The weekly review
Every Friday, after you ship. Copy this into your notes and answer in a sentence or two each:
1. What did I ship that someone could see? 2. Inputs: conversations ___ / shipped ___ / asks ___ 3. What did I learn about users this week? 4. Is the bet on track for its date? What does the evidence say? 5. What took more time than it should have? Was any of it comfort work? 6. Next week’s one outcome:
Planning the weeks around a launch? The free launch planner lays out every task from two weeks before launch to a month after, so the rhythm has something to run on.
The minimum viable week
Some weeks fall apart: you get ill, the day job explodes, a launch flops and you can’t face the product. Consistency doesn’t mean those weeks don’t happen. It means they don’t break the chain. Decide now what the smallest acceptable week looks like, so you don’t have to decide when you are tired:
- One conversation with a user
- One change shipped, however small
- One public update, even if it is “slow week, here’s what I learnt”
That takes about two hours. Doing it keeps your product, your users and your habits warm until normal weeks return, and restarting from a minimum week is far easier than restarting from zero.
A seven-day mindset reset
Do this when you feel stuck, or simply to put everything above in place. Each day takes under an hour.
| Day | Do | Done when |
|---|---|---|
| 1 | Write your current project as a bet, with kill criteria | Signal, date and exit are on paper |
| 2 | Audit last week into Learn, Sell, Build and Comfort | You know your biggest column |
| 3 | Clear the backlog of two-way decisions | Every one is made; one-way ones have dates |
| 4 | Talk to one user or likely user | Notes written, one surprise underlined |
| 5 | Ship something visible and post about it | Someone else can see it |
| 6 | Start the decision log and the evidence file | Both exist with a first entry |
| 7 | Run the weekly review and block next week’s slots | Next week’s outcome is chosen and in your calendar |
If the bet you wrote on day one is a new idea rather than a product you already have, follow the reset with our one-week plan to validate a startup idea, or run it past the free startup idea validator first.
The checklist
Think and decide
- My current project is written as a bet
- The bet has a countable signal and a date
- I wrote what I’ll do if the signal doesn’t show
- Two-way decisions get made the same day
- One-way decisions get a pre-mortem
- I keep a decision log and review it
Build and keep going
- A third of my hours go to Learn and Sell
- I protect a daily block for the week’s outcome
- I touch a customer every working day
- Something visible ships every Friday
- I track conversations, shipped and asks
- I know what my minimum viable week is
Questions founders ask
Can you learn a founder mindset, or are you born with it?
You learn it. Everything in this guide is a habit: writing bets down, sorting decisions by how reversible they are, a weekly review. Habits feel forced for a few weeks and then become how you work. Confidence follows the habits, not the other way round.
How do I stay motivated when nobody is using my product?
Stop relying on motivation and measure inputs instead: conversations held, changes shipped, asks made. Those you control every week, and they are what eventually moves users. If the inputs are high for six weeks and nothing moves, that is a signal to change the bet, not to try harder.
When should I quit or pivot?
Decide before you start. Write the signal you expect and the date you expect it by, and what you will do if it does not show up. When the date comes, ask: knowing what I know now, would I start this today? If not, change the bet. If the answer is yes but the signal is weak, narrow the audience and run the bet again.
How many hours a week should a founder work?
Enough to keep the weekly rhythm going for years, not weeks. Most solo founders get more done with a protected daily block on the one thing that matters than with long unfocused days. If you are building on evenings and weekends, plan for eight to twelve focused hours and protect them.
Is this only for solo founders?
No. Co-founders benefit even more from written bets and a decision log, because they turn arguments about opinions into arguments about evidence. Run the weekly review together and agree in advance who owns which kind of decision.



