If you’re taking a look at your features chart and seeing that one of your features has a much-much bigger usage than all the other ones, you are vulnerable to disruption, in the true Clay Christensen sense of the phrase. Someone can build a simple product, focussing on that one key feature that’s superior in just one way (cheaper, faster, collaborative, easier to use, mobile etc.), and you’ll struggle to compete, because you’re carrying all those other junk features around too.
Use deliberate improvements when: there is a feature that all your customers use and like, and you see opportunity to add significant value to it.
Because if there’s one thing that’s true for startup web products, it’s this: if you’re not shipping, you’re dead.
Ask your customers “Would you like a (Calendar/TimeTracker/Gantt Chart)?” and they’ll reply “Yes”. It’s a one-way “something for nothing” offer; why wouldn’t they? They haven’t had to make a trade-off between competing priorities. This leads to customers saying they want stuff that they don’t really want. 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.
When you are focusing on improving your product, a great question to ask is “Where do we suck, and where does it matter?
Put simply: a minor improvement on an important task is almost always a larger opportunity than a big improvement on an ancillary one.
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.
The main problem with the “but it will only take a few minutes” argument is that the scope of work should never be a reason to include a feature in a product. Maybe it’s a reason to bump it up the roadmap as a quick win, but that’s a roadmap decision, not a product one.
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”.
There’s a difference between encouraging engineers to build things internally (a good thing) and letting people add features to a product bypassing product management (a bad thing).
Obsessing about your competitor’s features relegates you to permanently delivering “yesterday’s technology tomorrow”.
“But if we don’t build it, someone else will”. Often it’s the logic used to expand a product because you’re not willing to admit your product stops somewhere. You’re afraid to draw the line.
If you can’t find what product customers are 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 behaviour never reflects reality.
It’s easier to make things people want, than it is to make people want things.
The key point in all cases is to understand how any work affects growth, after all everyone works on growth.
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 count-er-metric is “have people stopped doing anything else?”. So if you add a metric to track one area of your product, you must also analyse the other areas that are likely to be impacted.
Roadmaps are incredibly hard and require agonising trade-offs, but regardless, every good product manager needs a firm checklist for when they say yes, and when they say no. And they don’t make exceptions.
“Customers won’t value all the development you do on a project. Some necessary tasks such as back-ups, re-factoring, optimization, improving infrastructure offer little immediate reward. This doesn’t mean you can ignore those issues. The trick is to plan your roadmap so there’s never long periods where customers feel the application has been abandoned.
This is precisely where quick wins are useful. 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.
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.
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.
New features are just code that’s gathering virtual dust unless they are being used by your customers. If a feature is not being used it’s time to make hard decisions about killing it or making it better. Fail to make a decision one way or another and you risk losing customers to a nimbler competitor with a more focused product that does the job more efficiently.
Telling your customers something is a “ground up rewrite”, “HTML5 based”, “responsive” or anything like that will miss the mark unless you’re selling to developers. No one cares what you did, or often even how you did it. Your customers care about what they can do. Focus your message on what your users can now achieve with this feature and you’ll get their attention.
Google+ claims 170,000,000 users, which gets them a few news stories, but ignores a very real problem. Almost none of their users are engaged. They’re just people who clicked a link titled “OK” when faced with Google+. It’s similar to newspapers goosing up their page views using hacks like slideshows or multi- page articles. At some point you have to wonder who you’re really fooling.
Customer support - At best you’ll win yourself more customers, and at worst you learn what’s missing or misunderstood in your application.
When you have any type of long tail of features that have little usage, you’ve gone off course, or your strategy is “build everything that everyone wants”.
Features struggle for adoption for lots of reasons, users don’t see the value in using it, they find it too complicated, it’s hidden somewhere clever in your product, they’re the wrong type of users, and dozens more. This is why it’s important to say no. When you’re faced with a feature that only 8% of your user base are using, you have to make a call: Kill it or Keep it.