The Amara’s law of product features
And how building and killing functionalities have less impact than you imagine
Unfortunately, PMs view product management more around building than managing. But the “little” managing that is done, is generally centred around planning. And planning, in this scenario, focuses more in “forecasting” than “designing”.
Forecasting. The socially accepted word for futurology (read this with John Oliver’s voice). PMs spend a ridiculous amount of time reading the tea leaves. How much time is this going to take? How many story points do you estimate? When would we have the v1? How much revenue is this going to add? And then you add to the roadmap slide deck. And you feel happy. You feel like you have seen the future.
And then you’re wrong.
I love to ask PM’s: how often have your predictions been wrong? How often did you take longer to scope some story or epic for your team? How often were V1 launch dates delayed? How often were features underestimated? How often did the impact of your released feature underwhelmed? (Brackets of 20% make it easier.)
It’s not new that humans suffer from a planning fallacy, as Daniel Kahnemen studied, which resumes as “a phenomenon in which predictions about how much time will be needed to complete a future task display an optimism bias and underestimate the time needed.” If you’ve done more than one roadmap, you’ll notice this happens in every single one.
But there is another bias. A bias of impact estimation in product planning. And it’s recurrent in seemingly every startup.
One way or another I’m gonna get ya’…
In 2006 Roy Amara, a futurist (pun intended) and former president of the Institute for the Future described what would later become known as Amara’s Law:
We tend to overestimate the effect of a technology in the short run and underestimate the effect in the long run.
It’s a simplified description of a hype cycle, where there is a “peak of inflated expectations” followed by the the “trough of disillusionment”.
Hype cycles are common in multiple fields, especially when speaking of industries (eg: VR, chatbots…) but not so much regarding “everyday” events.
I believe one cycle to which PM’s are often exposed (and which deeply hampers decisions) is an impact hype. First you get super excited. Then you realise it’s not what you expected. Then you adjust your reality and realise you’ve probably done the same mistake in the past. And it seems this works both for building as for killing product! And following Roy’s fashion, I summarise as:
Product managers overestimate the impact of building a new feature and non-product managers overestimate the impact of killing an existing feature
Product managers overestimate the impact of building a new feature…
PM’s are naturally optimistic and often hype the forecasted impact of that new product or feature. And over and over again, it doesn’t meet the expectations. Silver bullets don’t exist. But… “customer research is clear, we ran our models, it has to work!”.
But it likely won’t; and that is ok. As Paul Adams brilliantly put it “shipping is the beginning”. In the end, it looks a bit like this:
… non-product managers overestimate the impact of killing an existing feature.
On the other hand, “killing” a feature, a product or an initiative, is a mostly overlooked action in the product process. “Builders gonna build” right? Who wants to destroy something we worked so hard to develop? “Sunk cost” is the biggest fallacy of our time.
But when you actually assess the option, (especially when you need to simplify because a) feature creep really sucks and b) your conversion rate is really low) and you get your stakeholders together (aka the non-product people in the company who contribute towards road mapping), and explain what your going to “kill”, the reaction tends to be: “You can’t!!! The company is going to dieeee! Without this feature we can’t work!!! EVERYONE NEEDS IT (even though data says only Jack B. from Hooli used it in the last 24 months…)”. So you think killing this feature is going to lead you to complete and utter failure.
But it likely won’t; and that is ok. This is a common judgmental bias called law of small numbers where people see a small volume of interactions, extrapolate impact and deeply overvalue the importance (and consequently overvalue the effect of restricting access). Again, it goes a bit like this:
So, as a PM, what can I do?
Show them this medium post. 😬
But seriously, first: adjust your own hype. Realise product is a construct of iterations, not a single release of awesomeness. Manage everyone’s expectations, especially your own. Regarding “killing” a feature, besides people experiencing that sunsetting a feature won’t affect that much (assuming you’re looking at stuff you have preemptive data on usage, not your key functionality) there is little you can do as “haters gonna hate”.
Take a breath and carry on, knowing, in general, whatever you do, will have less impact than you believe. Sike. 😶
