Building the Product

What is a sane way to prioritise between fixing bugs, paying customer promises, and building the exciting new thing?

A starting point

Founders default to the exciting new thing and let bugs and promises rot, which quietly churns the customers you already have. As a starting point: protect a fixed slice of each week for reliability and honouring commitments (say a third of your time), spend the rest on the one bet that could move the business, and treat 'exciting' as a warning sign to double-check, not a reason to build. The customers you already have are cheaper to keep than the ones the shiny feature might win.

Go deeper

Hand-picked from around the web, each with a note on why it earns your time.

2 resources 2 link-checked

Read

✍️ Essay
✓ Link checked Free Intermediate

Why we picked it This is the cleanest answer we have found to your exact question: it names five buckets a roadmap actually pulls from (new ideas, iteration on what you shipped, customer problems, quality and bugs, and scale) and argues the whole job is balancing across them rather than picking one. It gives you honest language for why an all new features roadmap ships half finished buggy work, and why an all customer requests roadmap quietly stalls. Treat it as a starting point for a healthy mix, not a fixed percentage split.

Where do product roadmaps come from?

From Intercom by Paul Adams

  • The exciting new thing, paying down what you shipped, honouring customer promises, and fixing bugs are separate buckets, and a sane roadmap deliberately draws from each rather than letting one crowd the others out.
  • Over indexing on new features leaves you with half useless, half finished, buggy product, while over indexing on customer requests optimises locally and never moves the market.
  • A visible backlog with the honest admission that some items may never ship is part of the system, so saying no stays explicit instead of piling up silently.
Open intercom.com →
📄 Article
✓ Link checked Free Beginner

Why we picked it Once you accept that not every bug earns roadmap time, you need a repeatable way to decide which ones do, and this piece lays out a concrete triage process for exactly that. Its most useful move is separating severity (how badly it breaks the system) from priority (how urgently the business needs it fixed), which is the distinction that stops a scary sounding but harmless bug from jumping the queue ahead of a real customer promise. Use it as a starting checklist and trim the steps to fit a small team.

Bug triage process: How to run it and what to prioritise

From Plane by Sneha Kanojia

  • Severity and priority are not the same: a critical bug hitting five internal users can wait, while a cosmetic bug on the checkout page every customer sees may need fixing first.
  • Every bug gets an explicit decision, an owner, and a next step, even when that decision is defer or will not fix, so nothing rots silently in the backlog.
  • A short recurring triage rhythm (a few fifteen minute passes a week) is far cheaper than a quarterly backlog bankruptcy where the pile has grown unmanageable.
Open plane.so →

People also ask

How do I decide what to build next? Prioritize outcomes, not output, and use a simple scoring frame like RICE, Reach x Impact x Confidence, divided by Effort, to compare ideas honestl... Intermediate 2 resources → How often should an early-stage startup ship? Ship weekly, at least, cadence is a competitive advantage because faster loops mean faster learning. You haven't really started until you launch, a... Beginner 2 resources → How do I build a roadmap without over-planning? Work in short fixed cycles with variable scope, Basecamp's Shape Up runs on six-week bets, not a rigid multi-quarter Gantt chart. Make a few bets y... Intermediate 2 resources → How do I keep talking to users while I'm heads-down building? Make discovery continuous, not a one-time phase: interview a customer or two every single week, even in a build sprint. Teresa Torres's opportunity... Intermediate 2 resources → How do product teams keep a consistent shipping rhythm as they grow? Separate your planning cadence from your execution cadence and lean on async updates instead of endless meetings. A predictable operating rhythm, w... Advanced 2 resources → How do I say no to feature requests without losing customers? Anchor every 'no' to the outcome you're chasing and the customers you're building for, most requests are solutions in disguise, so dig for the unde... Intermediate 3 resources →