Biggest-Bottleneck Prioritization
Solve the single biggest problem, then pick the next — don't dream up a long roadmap.
- Difficulty
- Easy
- Time to result
- ~weeks to results
- Steps
- 3
- Confidence
- 85%
A deliberately simple prioritization algorithm: identify the biggest bottleneck or product problem, focus everything on solving that, then repeat. It resists the temptation to overplan and keeps a small fast-moving team pointed at what matters most. Use it when leading a product where speed and focus beat elaborate roadmapping.
Origin
When asked how he decides what to build amid endless requests, Anton described this as his 'very very simple algorithm' and default. He notes the hard part isn't the algorithm but correctly identifying which problem is actually biggest.
Core principles
- 01Always work the biggest bottleneck first
- 02Don't overthink or pre-plan a long roadmap
- 03Finding the true biggest problem is the hard part, not the sequencing
- 04Stay engineering-led when the right solution is tangled in technical detail
How to run it
- 1
Identify the biggest bottleneck
Determine the single biggest product problem or constraint. Draw on talking to users, reading requests, and the feedback board rather than guessing.
Pro tip The biggest problem is often entangled with a larger technical initiative — recognising that changes the solution you pick.
Watch out This step is deceptively hard; the algorithm is simple but the diagnosis rarely is.
- 2
Really solve that one problem
Focus the team's effort on genuinely solving the identified problem rather than spreading thin across many.
Pro tip Stay engineering-led so the solution can absorb the technical realities of the problem.
- 3
Pick the next one
Once solved, repeat the loop on the new biggest bottleneck rather than executing a pre-written long-term plan.
Pro tip Run a weekly planning cadence with a ranked board plus a demo so everyone stays on the same page.
Watch out Avoid dreaming out a long roadmap; at high change velocity it will be wrong within a month.
In the wild
Anton names the current biggest initiative as making Lovable more agentic — a longer-horizon technical bet chosen precisely because it unblocks the biggest cluster of user problems at once.
→ Weekly planning still governs execution even while a multi-week initiative runs underneath.
Common mistakes
Over-roadmapping
Elaborate long-term plans get invalidated fast in a rapidly changing space and slow a small team down.
Non-technical prioritization on a technical product
For a deeply technical product, PMs who aren't engineers can pick solutions that ignore the technical entanglement of the real problem.
Is it for you?
Best for
Founders and eng-led product leaders on small, fast-shipping teams
Not ideal for
Large orgs needing cross-team coordination and predictable long-range commitments
From the transcript
“identifying what is the biggest ball neck what the biggest produ problem and iterating fast”
“not overthinking not like dreaming out the long road map that's my my default it's a very very simple algorithm”
From the episode
Building Lovable: $10M ARR in 60 days with 15 people
Anton Osika (co-founder and CEO)