What do you do with your feature audit? For any given feature with limited adoption, you have four choices:
Kill it: admit defeat, and start to remove it from your product.
Increase the adoption rate: get more people to use it.
Increase the frequency: get people to use it more often.
Deliberately improve it: make it quantifiably better for those who use it.
You can improve an existing feature in three different ways:
The product manager’s challenge is two-fold;
firstly, finding improvements that will benefit the business and its customers, and
secondly, ensuring that these improvements don’t get lost on a whiteboard somewhere, and actually make it out the door.
Asking your customers “Would you rather that we made the product much faster, or that we added more labelling features?” and you’ll get a different answer. Everyone values speed. So when planning new features it’s important to understand the trade-offs at play.
When you are focusing on improving your product, a great question to ask is “Where do we suck, and where does it matter?” Address your product’s shortcomings, or someone else will.
Building a great product isn’t about creating tons of tactically useful features which are tangentially related. It’s about delivering a cohesive product within well defined parameters.
Delivering extra value to one customer comes at the cost of taking value away from many others.
Idle time is best used fixing bugs, cleaning up test suites, refactoring, etc. rather than derailing a product vision just to “keep the team productive”.
It’s a mistake to assume that your competitors are in any way smarter or more tactical than you. Obsessing about your competitor’s features relegates you to permanently delivering “yesterday’s technology tomorrow”.
Strong understanding of the outcome customers want, and how they currently get it, is essential for you to succeed in product management.
Sidenote: If you can’t find what product they’re currently using, the chances are that it’s a fictitious outcome (“Wouldn’t it be cool if I could get all my social media files in one place?”) or an aspirational one (“Of course I want to lose weight”). Espoused behavior never reflects reality.
Making things people want involves understanding a long standing human or business need and then using technology to: take out steps, make it possible for more people, make it possible in more situations.
Jeff Bezos is famous for saying “focus on the things that don’t change”. The problems that people and businesses encounter don’t change often. The ways they can be solved changes almost yearly. So it stands to reason that making things people want should start with the “what people want” bit, and not the more tempting “things we can make”.
Remember: It’s easier to make things people want, than it is to make people want things.
An Acid Test for New Features
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?
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 matter in 5 years?
Will everyone benefit from it?
Beware the “fre-cently” bias. You never doubt the things you hear frequently or recently should be road-mapped. It’s a natural reaction caused by your inbuilt empathy for customers.
The danger of the fre-cently bias is that it gives you the illusion of analysis, the sense that you’ve done your homework and this is a rational conclusion you’ve come to. In reality you’ve made a lazy decision to satisfy the whims of a small sample of vocal users without taking a second to investigate how many people really want or need the feature.
“Will more people use it? Will people use it more? If neither, then will it definitely be better for those who do use it?”
Will it improve, complement or innovate on the existing workflow?
Does it grow the business?
Will it generate new meaningful engagement?
If it succeeds, can we support and afford it?
Can we design it so that reward is greater than effort?
Can we design it so that reward is greater than effort? As my colleague Paul Adams previously wrote, for any feature to be used the perceived benefit has to be greater than the perceived effort.
Product design is about cost-benefit analysis. How useful is something vs how hard is it to do.
Can we do it well?
To build a feature well, you have to understand the job it does intimately. As a corollary to the old saying: if you can’t do it well, it ain’t worth doing.
Badly scoped features meet no one’s requirements, ship late, if at all, and add nothing to the product but confusion.
Products get bloated one lazy decision at a time.
You can schedule these quick wins to cover time periods where it would otherwise appear that nothing is happening. This way you’re constantly delivering value to your customers, whilst still tackling the larger features or back end problems.
Remember the only thing worse than an app in constant flux, is one where users can see cobwebs forming.
Rolling Out New Features
Team testing: The first step is to deploy it live with real data, but only visible to the team that built it.
Company testing: When a team believes their feature is complete, it is released it to the entire company who immediately use it in their workflow.
Restricted beta: The first public release is to a single digit percentage of users. We maintain a “Trusted Testers” group for this purpose. We communicate it as a beta, and specifically ask for feedback later, once they have used it.
Jake Knapp wrote that “Reactions > Feedback”, citing how when people are trying to be helpful they’ll make up things in an effort to offer you improvements.
Speculation and espoused behavior have no place in product design.
What you’re looking for here is:
Discoverability – are people finding this feature?
Engagement – are people using this feature?
Adoption – is it now being used as part of a workflow?
Use Cases – how is it being used? what use-cases are popular?
Barriers – who isn’t using it? why? what’s preventing them?
During restricted beta you can ensure it’s discoverable for all users, refine your marketing to focus on pitching the true value as your customers see it, and you can resolve barriers to usage and adoption.
Full roll out: This is when it’s available to everyone who is eligible for it and you need to think about how you are going to tell them.
Those eligible for the feature should be sold on it. Feature announcements are often very inward looking, focusing much more on “what we did”, rather than “what you can do”. If you want people to use your product, encourage them by showing them what they can use it to achieve.
Those ineligible should be sold on the feature as a reason to upgrade. Often you can achieve this with a free trial (e.g. Try our premium plan for one month free).
Features without engagement are the seeds of bloatware.
For any significant feature, you need to have plans for those who use it, and those who don’t.
When people are using it well, you want to gather use cases, and marketing collateral from them for future use. Depending on your plans you may also want feedback.
When people aren’t using it, you want to encourage them, educate them, and engage them, the only acceptable outcome here is they’ll start using it, or they’ll tell you why not.
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.
Before you ship that next feature, ask yourself:
Will everyone see and understand it?
Are you showing users what you did, or what they can do?
Are you announcing it in context?
How will tomorrow’s sign ups hear about it?
Do you plan to follow up with users & non-users?
Once a feature is live, you should follow up with those who use it to understand how, why, and when it’s used. Look for ways to increase usage of it. Here’s some questions I’ve asked customers about a new feature:
Increase User Engagement
Make a strong first impression
Gradually expose the depth of your product
Announce features and improvements in-app
Be comfortable killing a feature