Minimizing unnecessary feature development
My one year old has quite a few toys, (thanks to the generous love showered by family and many good friends) but the toys that she always goes back to are the really simple ones. Her favorite toy is this Maraca that a friend got us from South Africa. She loves this thing. Once she finds it she will leave everything else to show us her skills with the toy.
At first glance, there is not much you can do with it — shaking it to create sounds ? But it’s genius lies in the fact that there are innumerable ways that you can shake it and create a different sound each time! That’s pretty simple, yet extremely impactful.
The idea of creating a product people love AND keeping it simple at the same time is a hard thing to do in modern product management. This is because in product organizations (especially under a corporate umbrella with specialized departments) several teams come together to bring a product to market. However, in the quest for building the perfect product, and setting it up for the perfect launch, teams end up adding too much unnecessary complexity to the final product.
This is a common trap, based on the premise that a “feature rich” product addresses all your customers’ needs. It provide a false sense of fulfillment to teams, a confidence of having covered all bases and having solved every single use case for the customer.
The reality however, is quite different.
How feature complexity creeps in..
No matter how feature rich a product might be, it is rarely possible to satisfy every last unmet need of every single customer out there. Still, we see product managers and builders striving to add features mindlessly, to attain some sort of feature moksha. Such a scenario is often symptomatic of poorly defined target markets and/or fictitious problem statements.
When teams try to solve world problems (instead of the ones that their target customer cares about ) they lose focus — and the first victim of this feature proliferation is simplicity.
Distributor power or Channel pressure is another common scenario why teams might spend time adding features that may or may not be what the end ‘user’ of the product needs/wants. This is especially true in B2B business settings where a distribution channel partner has massive influence over a vendor’s product development roadmaps, in return for much coveted shelf-space and distributing the product to the masses.
..and what to do about it.
Discipline is key. Wether or not to add a certain feature should be looked at from several different angles.
From a problem-solution fit standpoint — Will adding a new feature demonstrably solve a problem that customers face and demonstrably care about ?
(I emphasize “demonstrably” — but you know why).
From a product strategy standpoint — before developing a new feature product managers must ask if it will be a stepping stone, or a step forward towards the ultimate vision for the product? What other pieces have to fall into place to make that vision a reality? how likely are those outcomes?
And finally, from a business case standpoint — one must only add new features based on solid business cases. Will this feature unlock a revenue stream for your company immediately, or in the foreseeable future? Will it result in a sustainable competitive advantage over your competitor products? Is there enough (reliable) data that supports the above hypotheses?
When the results to the above analyses are positive and are well supported by data, a feature addition might be a good strategy. If either one is negative, i.e if adding a feature will not result in any incremental revenues or it doesn’t fit in the over all product vision/game plan then would be a sub optimal use of valuable resources AND will only make the product complicated for users.
For product teams, minimizing unnecessary feature work helps embrace simplicity and paves the way to build impactful products. For organizations, this ensures that limited resources are invested optimally and aligned towards overall value creation.