4
2 Comments

How to Decide What Features to Build Next

I just shared this as a comment elsewhere, but I've been getting this question and sharing my solution often. Figured a post would be a better way to distribute something I hope is helpful. AMA.

  1. Before we begin with the framework, look for patterns. The more customers that ask for it (and the more often a customer asks for it), the higher on the list it goes. I kinda give one point to a request, bucket the requests into the same kind of task, and give a 1/2 or 1/4 point to each time it was asked for again by a customer.
    I'll also move up things on the list if I can charge more for it or drop churn because of it.

  2. From that list, take the top 20% of those features, drop anything that has only one request (for this exercise). Use them in the framework below...

  3. On a spreadsheet, whiteboard, bar napkin, or the back of your friend's neck, create 4 columns: Feature, Impact, Difficulty, Difference. Write each task/feature into the Feature column. (If it's a "Project" type size, then it could be too big. Scale it down. You'll know it when you see something like that.)

  4. For each task, on a scale of 1-10, quickly give it a rating for Impact and Difficulty. Impact = how much will this move the needle (your north star metric)? Difficulty = how hard will it be to implement it (correctly). This is purely a hunch. If you have multiple founders, do this with them. If you have one coder and one no-coder, make the coder rate the difficulty and the no-coder rate the impact. This is purely a hunch and each task shouldn't take more than 1m to rate each column max. If it's taking longer than that to think about, you're taking too long and getting into the weeds. Get out. You're not implementing yet, you're making a decision.

  5. Difference = Impact - Difficulty. Maths. :) Simple as that.

  6. Sort the table by Difference. This will naturally bubble up the things that are easiest to implement with the biggest impact on the business. Do those first.

NOTE 1: Tie breakers usually go to dependencies, but if you don't have a dependency, pick which one you think would be more fun to go first.

NOTE 2: There are cases where you have something that is a dependency that has to come before another task. If that's the case, just move it around as needed to make sure you do the dependency first.

That's it. Hopefully it's helpful. Enjoy. Decide. Build. Ship. Create value.

on January 25, 2020
  1. 2

    This is very similar to the RICE framework for prioritization that Des Traynor of Intercom told me about when he came onto the podcast. RICE stands for:

    • Reach: what percentage of your userbase will this actually reach?
    • Impact: how much will this move the needle?
    • Confidence: how confident are you about these numbers?
    • Effort: how much time is this going to require from you?

    For each feature you can rate each these numbers from 1-10 or 1-100 or whatever you want, then calculate its priority via R × I × C ÷ E.

    What I like most about it is including the reach. It's really easy as a founder to become obsessed with very small corners of your app that only advanced users like yourself care about, while neglecting things that affect 100% of your users, e.g. the onboarding experience.

    Impact is obviously important, and so is effort, both of which you included in your list. Effort is a big one for me as a developer. It's easy to get sucked into working on massive slog projects that, while impactful, aren't nearly as helpful as doing 50 smaller things instead.

    1. 1

      Yes! I love it. Thanks @csallen!

      I also like the Reach part. I use it more as a filter but that’s great too to just put it into the algo. And Confidence is nice as well. The Difficulty and Impact scores are so hard to judge sometimes. With bit long lists, that can become an important factor for tie breaks.

      Thanks for that input. Might need to adjust my own framework a little to adopt some of the RICE framework.

      Cheers!