My to-build list currently has 43 items on it. Every single one feels important. Customer requests, competitor features, performance improvements, design updates, new integrations — all of them could plausibly be “the thing that makes the difference.”
But I can only build one thing at a time. Maybe two, if I’m being aggressive. The rest have to wait. The question is: which ones wait and which ones go next?
This is the feature prioritization problem, and it’s where most founders either freeze (building nothing because they can’t decide) or scatter (building a little of everything and finishing nothing). Both are fatal.
After shipping dozens of product versions across my own businesses and advising startups at the accelerator, I’ve settled on a prioritization framework that’s simple enough to use weekly and rigorous enough to prevent emotional decision-making.
The ICE Framework (Modified)
ICE stands for Impact, Confidence, and Ease. For each potential feature, score each dimension on a 1-10 scale, then multiply.
But I modify the standard ICE framework because the standard version has a flaw: it doesn’t account for what the customer needs versus what you want to build.
Impact (1-10): How much will this feature improve the core metric you’re tracking? (Revenue, retention, or customer satisfaction.) Score based on evidence, not gut feel. A feature requested by 10 paying customers gets a higher impact score than one you think is cool.
Confidence (1-10): How sure are you that this feature will achieve the expected impact? A feature validated by customer interviews gets a high confidence score. A feature based on your assumption gets a low one.
Ease (1-10): How quickly can you build and ship this? A feature that takes a day gets a 9 or 10. One that takes three months gets a 1 or 2.
ICE Score = Impact × Confidence × Ease
Build the features with the highest ICE score first. Revisit the scores weekly because new customer data can change Impact and Confidence scores rapidly.
Here’s a real example from a product I was advising:
| Feature | Impact | Confidence | Ease | ICE Score |
|---|---|---|---|---|
| PDF export for reports | 8 | 9 | 7 | 504 |
| Dark mode | 3 | 2 | 6 | 36 |
| Email notifications for deadlines | 7 | 7 | 8 | 392 |
| Custom dashboards | 6 | 4 | 3 | 72 |
| Mobile app | 5 | 3 | 2 | 30 |
The founder wanted to build the mobile app (it sounded impressive) and dark mode (he personally wanted it). The ICE framework showed that PDF export and email notifications should come first — they had the highest combination of validated customer need, confidence in impact, and ease of implementation.
He built the PDF export in three days. Customer retention improved by 15% that month. The mobile app is still on the list. Nobody misses it.
The One-Feature Rule
Beyond the scoring framework, I follow a meta-rule: build one feature at a time, and don’t start the next one until the current one is shipped, measured, and evaluated.
This sounds obvious but it’s remarkably hard to practice. The temptation to work on multiple features simultaneously is strong because it feels efficient. “I’ll build the export feature while I wait for feedback on the notification feature.”
Don’t. Parallel feature development creates three problems:
Problem 1: Context switching destroys productivity. Every time you switch between features, you lose 15-30 minutes reloading the context. Over a week, that adds up to hours of lost work.
Problem 2: You can’t measure what’s working. If you ship two features at once and retention improves, which feature caused it? You don’t know. Data-driven decisions require isolated variables.
Problem 3: Nothing feels finished. Having five features in progress and zero shipped is demoralizing. Having one feature shipped and learning from it is energizing.
The one-feature rule forces the question: “What is the single most important thing to build right now?” If you can’t answer that question, your prioritization framework needs work. If you can answer it but feel pulled toward building other things, that’s discipline, not prioritization.
Customer Requests vs. Your Vision
Every founder faces this tension: customers ask for features that solve their immediate problem, while you have a vision for where the product should go. Whose voice do you listen to?
Both. But in a specific order.
In the first 12 months: customers win. You don’t have enough users or data to have a reliable product vision. Your assumptions about what the product should become are just that — assumptions. Customer requests, especially from paying customers, are grounded in real needs. Prioritize them.
After 12 months with consistent growth: vision starts to matter. Now you have patterns in customer behavior, and you can see where the product should go that customers can’t articulate. Henry Ford’s (possibly apocryphal) quote applies: “If I had asked people what they wanted, they’d have said faster horses.” Sometimes the right move is to build the car instead.
But even at this stage, vision should be validated before it’s built. The JTBD framework helps here: if your vision addresses a real job that customers are trying to do, it’s probably right. If it addresses a job you think they should do, it’s probably wrong.
A practical rule: 70% of your development capacity should go to customer-requested improvements. 20% should go to vision-driven features. 10% should go to infrastructure and debt. This ratio shifts toward more vision over time as your customer understanding deepens, but it should never drop below 50% customer-driven.
The Anti-Feature List
Equally important as deciding what to build is deciding what not to build. I maintain an “anti-feature list” — features I’ve explicitly decided not to build, with the reasoning documented.
This list serves three purposes:
1. It prevents re-litigation. Without the list, the same feature request comes up in every planning session, and you spend time re-debating it. With the list, you can say “we decided against this in March because [reason]. Has anything changed?” If yes, re-evaluate. If no, move on.
2. It clarifies positioning. What you choose not to build defines your product as much as what you build. If you’re not building an API, you’re positioning as a simple, self-contained tool. If you’re not building enterprise features, you’re positioning as a product for small teams. These are strategic subtractions, not oversights.
3. It manages customer expectations. When a customer requests something on the anti-feature list, you can respond honestly: “We’ve considered this and decided not to build it because we want to keep the product focused on [core use case]. Here’s what we recommend instead.”
My anti-feature list is longer than my to-build list. And I’m proud of that, because saying no to features is harder and more valuable than saying yes.
The Feature Debt Trap
There’s a specific failure mode I see in founders who ship fast: feature debt.
Feature debt accumulates when you ship features quickly but don’t go back to refine, fix, or remove them. Over time, the product becomes a graveyard of half-finished, half-working features that confuse customers and create support burden.
Signs you’re accumulating feature debt:
- Customers ask “what does this button do?” about features you shipped months ago
- Your support tickets are dominated by questions about features rather than bugs
- New features break old features because the codebase is tangled
- You’re afraid to touch certain parts of the product because you don’t remember how they work
The fix: dedicate 10-20% of every development cycle to feature debt reduction. This means going back to existing features and either improving them, simplifying them, or removing them entirely. The Pixar principle applies — every feature deserves iteration, not just the new ones.
Feature debt is the cost of shipping fast. If you don’t pay it down regularly, it compounds into a product that nobody — including you — can navigate.
Saying No to Good Ideas
The hardest part of feature prioritization isn’t saying no to bad ideas. Bad ideas are easy to reject. The hard part is saying no to good ideas that aren’t the best idea for right now.
Every feature on your list is probably a good idea. PDF export is good. Dark mode is good. The mobile app is good. Custom dashboards are good. They’re all legitimate improvements that would make some customers happier.
But you can’t build them all at once. And trying to build them all eventually — without prioritization — means building them in whatever order feels most urgent on any given Tuesday, which is no prioritization at all.
The ICE framework helps, but the emotional discipline of saying “this is a good idea and we’re not building it” is separate from any framework. It requires accepting that some good ideas will never get built. That some customers will be disappointed. That your product will always have gaps.
This acceptance is the difference between a focused product that excels at its core purpose and a bloated product that’s mediocre at everything. Focus doesn’t mean doing less. It means doing the right things well and letting the wrong things go.
Key Takeaways
- Use the ICE framework (Impact × Confidence × Ease) to score and rank features. Build highest-scoring features first. Revisit weekly.
- Build one feature at a time. Don’t start the next until the current one is shipped and measured. Parallel development destroys productivity and data quality.
- In the first 12 months, customer requests beat your vision. After 12 months with consistent growth, vision can take more weight — but never more than 50% of development capacity.
- Maintain an anti-feature list. What you decide not to build is as strategic as what you build. Document the reasoning.
- Pay down feature debt regularly. Dedicate 10-20% of development time to improving or removing existing features.
