What new features to build
Building new features for a product is quite easy as the brain communicates with the hands but coming up with the killer features requires extreme expertise. In my previous write-ups, I talked about improving existing product features and applying 80/20 rule to maximize our business growth with limited resources. We might get it wrong if we don’t know the right features to build.
When it comes to product strategy and determining which new features to build, the Jobs-to-be-Done Framework is extremely useful to determine what we should build as a product manager. Popularized by Harvard Business School professor Clay Christensen, it is a way of looking at the motivations of customers in using a product, rather than the traditional marketing techniques of slicing and dicing customers according to demographics.
People don’t buy a product because they fall into a particular group. But they do buy a product to solve a problem. The features you choose to build should be the ones that will help them do the job that needs to be done. The problems people encounter in their lives rarely change from generation to generation. The products they hire to solve these problems change all the time. A strong understanding of outcomes customers want, and how they currently get it, is essential to build new features for the product.
Let’s walk through how to determine new features to build for your new product.
An Acid Test for New Features
The acid test for new features is not the litmus test we all know in the chemical qualitative analysis but a simple set of YES/NO questions that you can quickly answer before you add a new feature to your product road map. To determine the new features to build, your new features must score straight yes on the following questions.
Does it fit your vision?
What do you believe that no one else does? What do you know about this problem that no one else does? How do you believe it should be solved? Anyone can pull the data, run the focus groups, but only you have your vision.
Product decisions based on vision alone sometimes seem irrational, because they’re tough decisions. Worse than being a hard decision, you’ll never truly know if you got it right. There is no right. There is no wrong. This is art, not science. It’s just you and your vision.
Will it still matters in 5 years?
It’s a hard and boring question to ask but will this still deliver value in five years’ time? You’ll feel like the curmudgeon of product planning. But that app that was so hot in 2015 was gone by 2016. Those slides, fade and fold effects that everyone loved last year look tacky as hell this year. If you’re going to spend the best years of your life on a product eschew the trendy, and focus on the meaningful.
Will it improves, complement, or innovates on the existing work-flow?
Adding a whole new work-flow to your product should be a rare occurrence. The majority of your time should be invested in improving, complementing, or innovating upon existing ones, and for any given project you should know which of these you are doing.
Redesigns are fun, but you can spin your wheels on them. A good way to cut through the bullshit is to simply ask “Will more people use it? Will people use it more? If neither, then will it definitely be better for those who do use it?”
Does it grow the business?
Can you join the dots between the impact this new feature will have and new revenue?
Will it generate new meaningful engagement?
Most metrics ignore the system and focus on the isolated feature being added. Put a new button in your product and people will click it. Get enough clicks and you can call that an increase in engagement. But that’s nonsense. A counter-metric is “have people stopped doing anything else?” So if you add a metric to track one area of your product, you must also analyze the other areas that are likely to be impacted.
If it succeeds, can we support and afford it?
One fallacy of “quick wins” and “easy hacks”, is they usually only evaluate the effort required before shipping e.g. an agency produces a Windows Phone app in record time and low cost, and because the effort was relatively minimal, and the idea makes sense, you ship it. Success!
Then the support requests come in, and it turns out none of your team know XAML, so you’re stuck with a broken build live, and a few hundred customers complaining to support about it. Of course, it’s never that obvious. Good engineers rarely say they don’t know something. They’ll hack at it some evenings, display some initial competency, and then estimate how long until they fix the bug. This is all time that you didn’t plan on spending when you shipped this app. And that estimate is wrong.
Can we design it so that reward is greater than effort?
For any feature to be used the perceived benefit has to be greater than the perceived effort. End users understood the benefits Google Plus could bring, but the overhead of dragging and dropping many copies of your contacts into various boxes, on a regular basis, was simply not worth it. I feel that check-splitting apps habitually fall into this category. Splitting a check can be a pain point, but any solution is seen thus far still costs too much, and we’re not talking about price.
We’re talking about time, overhead, social capital, etc. Product design is about cost-benefit analysis.
Can we do it well?
Every product has its neglected corners, usually areas where the PM dabbled but conceded defeat. Conceding defeat all too rarely results in removing a feature, it usually just means ignoring it, leaving a messy trail and a confused offering.
Can we scope it well?
Starting with the cupcake release for a feature is essential. Early usable releases provide the feedback necessary for an idea to flourish. A good sign that a feature isn’t well-scoped is when it lacks specifics.
Badly scoped features meet no one’s requirements, ship late, if at all, and add nothing to the product but confusion.
There is no pride in having a “big” product with lots of features, only a highly engaged one. The more surface area your product has, the more important it is that you chase engagement and learn from your mistakes. This is most important when you’re young and scrappy. You’re capable of shipping a new feature every week, but you should focus that energy on growing usage of your product, not growing your product.