Prioritizing Your Product Features

Because Uncover is a bootstrapped company, our resources are limited and we constantly need to prioritize what we work on. We don't have the luxury of having raised hundreds of thousands of dollars or more to try a hundred things and hope that something sticks. For most products, there are a lot of plausible ideas that you could implement at any given time, and often you see that happening. Great products, however, are built one great feature at a time, with a focus on either increasing signups or improving engagement. Nothing else.

Prioritizing Your Product Features

As a bootstrapped company, we choose features to implement that are for the most part targeted towards increasing signups. If it doesn't grow revenue, then we can't afford the time to work on it.

Well and good, but how do you know whether something is going to grow revenue or not? The simple answer is that you don't, yet it's still true that when you prioritize the potential for revenue growth in thinking about a new feature, the essential importance of that feature will become clearer to you.

The side effect of building features that grow revenue is that they tend also to improve the product and improve engagement. If a new user is more likely to sign up because of features you've offered, it follows that current users will be happier too, and more committed, owing to those same features.

New features come from everywhere. They come from the minds of the people working on the product. They come from users suggesting new things that they'd like to see. They come from bug reports, support emails, and even from people who have never used the product before.

Having new ideas about what to build has never been a problem for us because we are inundated with new feature requests. Founders and product people naturally want to make everyone happy, but the shrewd ones know that just isn't possible, and realize that they have to prioritize.

Users typically submit new feature suggestions that apply to specific sorts of use. They'd like to do X because it'd help them with the way they use your product. These suggestions β€” when it's not a case of a help to one person being a hindrance to others β€” might be worthwhile in a perfect world. I tend to file them away in a β€œuser idea list,” but seldom have the luxury to refer to them. For the most part such suggestions aren't broad enough to apply to your entire user base β€” and, more importantly, they don't increase revenue.

Bugs and support emails are seldom feature requests in and of themselves, but they often supply prompts for one's own thinking about better ways to implement product features that will prevent user confusion. While reducing confusion does not quantifiably increase revenue, it may fend off a decrease in revenue when users leave because they can't make the product work right. A solid base for increasing revenue that SaaS product owners learn to respect very quickly is to decrease churn (i.e. customers leaving). Any sort of broad improvement that can do that may well take priority over everything else. After all, how can you build new features on top of a broken product?

More often than not the best source for new features is your own mind. Because you have the best understanding of everything taken together, you can intuit what to prioritize: You know what features users are requesting. You know what's broken in your product. You have a sense about what your product is missing that comes from your analysis of failed signups. You went in with a vision of what your product should be – you're not quite there yet – but you know what it'll take to get there.

What to build and in what order

Now it's time to gather what you know and prioritize what to build. You may know immediately what the next step is and won't have to go through this process, but you may also be stuck on what to do. When I'm stuck on what to do, I separate my short list of ideas into three buckets: easy, medium and hard. Easy are quick features that can be implemented in less than a day, medium are less than a week, and hard is anything that will take more than a week.

Then I look at each bucket and prioritize the features based entirely on what will increase revenue or decrease churn. Then I look at the top feature in each bucket and think critically about which will have the greatest impact. If a feature in the easy bucket will have the greatest impact, then your problem is solved for the moment. Go implement that feature. If it's something in medium or hard, then you have to think whether it makes sense to spend over a week on a hard feature if two easy features will add up to an anticipated greater revenue increase than one hard feature.

It can get trickier, though, as often you need to implement a feature to lay the groundwork for another feature. That's where experience and knowing your product well comes into play. Often it's important to lay the foundation first even if taking those steps will delay a revenue-generating feature.

Lastly, there are sometimes worthwhile features that are marketing related rather than product related. These features, such as updating your homepage or marketing pages, won't make your current users happier, but they may help increase signups, which is the ultimate goal. These are features that you can implement once your product is in a somewhat stable state. Churn is low. Current users are happy.

After releasing a major update to Uncover on April 30th, 2014, we've been spending a lot of our time updating our marketing materials rather than implementing new features, as our product is in a stable state. Doing this is often overlooked because entrepreneurs often assume that it's their product that needs improving to sign more people up rather than their marketing materials and message.

Whether it's working on new product features or updates to your marketing website, if you view new features through the lens of increasing revenue your product will improve far more quickly than it would when you add shiny new bells and whistles or cater to one user at a time.


comments powered by Disqus