How To Prioritize Product Feature Development: Create Software, Not Bloatware
8 MIN READ
|
Updated on September 1, 2017
Having received three Michelin stars, and having been regularly voted as the “Best Restaurant in the World” by a panel of around 500 experts, El Bulli in Spain was the frontrunner in the culinary world.
In 2010, El Bulli was closed at the peak of its popularity, and was reopened in 2014 as El Bulli Foundation, a not-for-profit culinary academy for innovating new cooking techniques and flavors.
So what made them so special?
The restaurant served only for six months in a year and only at nights, while the chef Ferran Adrià and his team would spend the remaining six months in creating a set of completely new dishes, only to inspire millions of taste buds in the next season once again.
Then, there’s Sukiyabashi Jiro in Japan, another restaurant that received the coveted three stars from the Michelin guide (the first sushi-only restaurant to get them), and which, Barack Obama claims, serves the best sushi that he’s ever had in his life.
Their winning formula?
Over six decades of relentless pursuit to make the perfect piece of sushi. The chef, Jiro Ono (declared as Japan’s national treasure), who’s been doing just that since he was 9, personally creates the masterpieces and serves them to the customers. Make one thing, and make it perfect.
Whether it gets replaced by a completely new one every six months or the same one gets perfected over a span of sixty odd years, for every restaurant out there, the effort that goes into creating and delivering a menu is pivotal; the latter defines the former’s purpose of existence.
And what dishes are to a restaurant, features are to a SaaS. You focus on those dishes/features that strengthen your restaurant’s/product’s vision and discard the others that aren’t helping your main goals. Adding a new dish or a new feature demands a lot of planning and thinking through, andone tiny misstep can cost a lot.
Distractions literally kill startups. They may do it slowly, you may not even notice it’s happening, but it happens all the time. Feature development in and of itself can be a distraction if it’s not being done in a prioritized way. Building stuff for the sake of building it is startup suicide. So having a rigorous and honest prioritization process for feature development is critical to controlling distraction and eliminating waste.
So how did Jiro Ono and Ferran Adrià pull it off? What is the thought process they went through? What does it take to build an El Bulli or a Sukiyabashi Jiro in SaaS?
How to Prioritize Features the Restaurateur’s Way
1. Sticking to your vision
In the West, where the problem of hunger has been solved, where obesity is now the issue, the trend has to be more and more about the pleasure of eating, the fun, rather than seeing it as simply a way of satisfying our appetites. At El Bulli we try and take this idea to the nth degree.
Ferran Adrià could’ve easily opened the gates to customers throughout the year and served easily-recognisable dishes. The cash registers would’ve been on a roll, and planning and cooking dishes would’ve been a breeze. But he didn’t. And that’s precisely what made El Bulli what it was.
It might seem easy to carry out, but having conviction to your core values can get tricky. You have to resist the ever-so-persistent temptation of becoming a Yes-Man.
By saying “Yes!” to every other feature request and by having your finger in too many pies, you’ll only take your product further and further away from what it was meant to solve in the first place. Only include those features that fit your vision. Get rid of the clutter and noise.
The difference between successful people and very successful people is that very successful people say “no” to almost everything.
In spite of users calling them as being “blinded by ideology”, Basecamp firmly refused to provide GANTT charts in their product.
Why? They believed that GANTT charts are not required for good project management, and they committed to that ideology. They’ve stood by that philosophy till date. In fact, they recommend companies to read their feature requests, and then simply forget about them.
The Basecamp team says that if a feature is crucial, the team just couldn’t miss it, as they’d be reminded about it almost every single day; there was no need to list down and analyse the feature requests. Outrageous, yet insightful.
It’s the era of instant gratification, and every prospect or customer wants what they want as soon as possible. And in such situations, companies succumb to the short-term goals of satisfying a customer or converting a lead, while losing sight of the long-term objectives.
Before nodding yes, ask yourself if the feature will still carry weight after five years.
Nathan Kontny from Highrise says that feature requests from individual customers are in fact symptoms of the underlying generic problem causing them.
So instead of solving one-off favors, dig deeper into the request, figure out the root cause, and then tackle that. Make a trade-off by disappointing a single user initially, to create a much larger impact for all your customers in general.
2. Looking at the other side of the kitchen
Some like sushi, some don’t. And Jiro Ono doesn’t cook for the latter. He knows that his customers visit his restaurant for good sushi. Nothing more, nothing less.
One of the major product management misconceptions is assuming that a product’s features and it users’ needs match perfectly. This notion almost always leads to overloading the product with too many features, most of which won’t make the slightest difference to the customer. In short, Feature Creep.
To evaluate the significance of feature requests, the Intercom team plots the features on a graph that compares the number of users and the frequency of usage.
And yes, they focus on the top right corner – the stars. And the top left corner? That’s the danger zone for you. If you find yourself building features that only have a handful of users, then your product is alarmingly close to becoming a bloatware.
When you’re drawing the line around your software, be sure you’re not leaving in marginal utility features in an attempt to add more value. These little wannabe-features hang around unloved, bloating your app, hogging the UI and adding to maintenance costs. These things can be fatal to start-ups.
3. Playing the hands right
You only have so many cooks, so many ingredients, and so many resources. Jiro Ono makes all the sushi by himself, and he serves 20 pieces for each customer. Ferran Adrià’s team had six months to set up a new menu, and they offer about 30 dishes each season. Both never crossed that limit. And it makes sense.
Don’t bite more than you can chew. Which feature is worth the limited time and energy that you have? Which can wait?
In terms of resources, there are two main aspects to consider:
- Cost (coding, UI, reusability of existing codes or designs, testing, documentation)
- Risk (technical complexities, requirement of new/unfamiliar tools/technologies)
Apart from those obvious constraints, there’s another major constraint that causes hiccups in feature prioritization, and that’s the conflict of ideas between the developers and the non-developers.
This is where the concept of “magical thinking” comes into play, where everyone with a feature request poses an AND mindset (every new request is monumentally important, and can be squeezed into the already packed to-do list); while on the other hand, the ones receiving the requests, have an EXCLUSIVE-OR world (it’s either this feature or that, not both). And thus, the mismatch ensues.
The keyword here is Communication. Just by changing the way in which a feature is requested, you can improve the thought process of evaluating its importance.
Rather than posing rhetorical (“Is building this feature possible?”) or vague (“Will building this feature be easy?”) questions to your developers, try out this straightforward approach instead: I would like to have this and I’m willing to pay up to that.
The catch with framing the request like that is it requires the person asking to make the hard analysis. How much is my request really worth? What other things would I give up to have this thing instead? It forces them to bargain with reality, which is much less appealing than charming the developer fairy into just giving them want they want, no sacrifices needed.
Effective and transparent communication leads to clear prioritization. At Chargebee, the feature requests are listed down in one place, along with their corresponding customer support tickets, and comments from the team members.
The product team then grades the difficulty level of each feature, matches it with the available skill set, and upvotes it depending on the results. And like a trending blog post, a feature moves up the priority list as it receives more and more upvotes. This way, we ensure that everyone in the team are on the same page.
Conclusion
Research shows that consumers love a truckload of features while buying a product, and once they become users, they get overwhelmed by the same. As soon as they’re onboard, they experience “feature fatigue”, which invariably shortens their LTV.
A smarter approach is to offer specialized products with a limited number of features that actually matter, instead of stuffing a hoard of features in a single product.
At Hubspot, they maintain a document called an MSPOT (Mission, Strategy, Projects, Omissions, Tracking), which is regularly reviewed in their management team meetings.
And according to Brian Halligan, the CEO, the most important section of the document is the “Omissions” part, which consists of the projects that weren’t taken up by the company that year. It helps in limiting his appetite so that he doesn’t overstuff the organization, he says.
As Dave Packard famously stated, be it a restaurant or a SaaS firm, more companies die of indigestion than starvation.
Remember: A product isn’t a collection of features; it’s an experience from the first touchpoint to the very end.
