The Simple Feature Prioritisation Framework

Someone I know wanted to talk because they were very confused. They had the problem of being somewhat successful with their side project, and now were getting overwhelmed by the million different directions they could drive things towards.

Should they develop more cool features?

Should they double down and make the existing features even better?

What about fixing some bugs? Maybe improve logging and metrics?

We discussed a bit, and ended up with some tenets to prioritise this work. While they were specific to this person’s case, I think they can be generalised enough.

The Priority Hierarchy

1. Security First

If your system has security issues, you should be up at night. Your user data, transaction, security depends on that. The fastest way to erode trust and lose customers is to have a big gaping security hole you didn’t fix because you were “delivering features.”

2. Availability Second

The more general rule here is, make sure don’t fuck over your existing customers before acquiring new customers. Service down is bad. Service often down is worse. Not having a clue when your service is down is worst.

3. Features Third

Which features? Well, if you’ve got a simple project, with a simple (or one-person) team, what I’d do is the following:

• Take all the possible features you can come up with
• Estimate how beneficial they’ll be
• Estimate how hard, long and complex it will be to implement them
• Prioritize based on value vs. effort

Ok, easy enough. But how do you actually go prioritise all those features?

The Simple Scoring Framework

There are a million and one ways to give a priority score. A well known and effective method is called RICE. It works well for large teams and complex endeavours, for smaller or personal projects I’d go with something a lot simpler.

Step 1: Score the Value (1-5 scale)

5 - Critical: Without this, users can’t complete core workflows. Revenue directly impacted. Unless that’s done, you don’t have a proper functional product.

4 - High Value: Significantly improves user experience or directly drives revenue.

3 - Medium Value: Nice improvement that users will notice and appreciate.

2 - Low Value: Small improvement, few users affected.

1 - Minimal Value: Nice to have but doesn’t move the needle.

Step 2: Score the Effort (1-5 scale)

1 - Trivial: Easy peasy, no dependencies, zero risk.

2 - Easy: A few days, minimal risk, well-understood work.

3 - Medium: A week or two, basically a sprint if you do 2 week sprints like most people. Some complexity or dependencies.

4 - Hard: A few months. This is a major feature. Typically, large projects fall here. Significant complexity, multiple systems.

5 - Very Hard: More than a quarter. High risk, major technical challenges. These are “Big Bets”, typically.

Step 3: Calculate Priority Score

Priority Score = Value Score / Effort Score

This gives you a simple ranking system:

• 5.0 - 2.5: Do these immediately (high value, low effort)
• 2.4 - 1.0: Do these next (good ratio of value to effort)
• 0.9 - 0.5: Consider these later (questionable return on investment)
• < 0.5: Don’t do these (low value, high effort)

Putting It Into Practice

Let’s say you’re prioritizing these features:

Clear priorities emerge immediately.

Real-World Adjustments

The framework gives you a starting point, but use your judgment:

Business Context Matters: A feature that helps close a big customer deal might jump the priority queue, even with a lower score.

Technical Debt: Sometimes you need to do unglamorous work to enable future high-value features.

Team Morale: Occasionally doing something fun (even if low business value) can be worth it for team motivation.

Market Timing: A competitive feature might be urgent even if the math says otherwise.

Common Prioritization Mistakes

Building what’s easy instead of what’s valuable

Don’t just pick all the 1-effort items because they’re quick wins. Sometimes the 4-effort, 5-value item is exactly what you need.

Not involving users

Your value estimates should come from user feedback, not just internal hunches. Ask your users what they actually need. This might not be always straightforward but it is a useful exercise to at least find reasonable proxies.

Analysis paralysis

Don’t spend more time scoring than building. This should take minutes per feature, not hours. Remember not to make perfect the enemy of the good: priorities after all are just a way to do what’s more valuable first. There is no vallue in scoring, except for the clarity gained.

The Weekly Priority Review

Every week, spend 30 minutes:

1. Review your current priorities - are they still accurate?
2. Add new items that came up during the week
3. Re-score items if you learned something new
4. Pick next week’s work from the highest scores

The beauty of this system is its simplicity. You’re not building complex spreadsheets or arguing in endless meetings about priorities. You score, you rank, you build.

And if you can’t figure out how to score something? That’s probably a sign you need to understand the problem better before building anything.