The Anti Launch Product Roadmap: Remove Features, Reduce Complexity, Gain Agility

Perfection is achieved when there is nothing left to take away. ~Antoine de Saint-Exupery

Via Peta Pixel

The most often cited (sometimes wrongly) example (exhibit above) of “perfection by taking away” is Apple. Why wrongly? The goal is not to have more or less features or product but to be simple. As noted in the book, “Insanely Simple: The Obsession That Drives Apple’s Success”, Simplicity isn’t just a design principle at Apple—it’s a value that permeates every level of the organization. The obsession with Simplicity is what separates Apple from other technology companies. Simplicity reflects in everything from product lines to features (in 1997, Steven Jobs slashed the number of devices that Apple would work on to 4 using a simple 2*2 grid - and as they say, the rest is history).

There are various ways to achieve simplicity and is a topic in itself. In addition to Insanely Simple, it is also useful to read John Maeda’s book Laws of Simplicity. One of the means of achieving simplicity is reduction i.e. removing features or product lines (the second example from Apple - cutting the product lines to four - resonates more here). John Maeda’s first law states, “The simplest way to achieve simplicity is through thoughtful reduction.” Reduction is also a part of iteration and progr. Unfortunately, this is a topic scantily covered in product strategy and product roadmaps. However, two frameworks centered on ‘reduction’ or what I call “anti-launch product roadmaps” are getting some visibility. They are Unlaunching and Anti Product Roadmaps.

Hardik Pandya, a Design Lead with Google writes in his post Unlaunch Manifesto:

“One of the most valuable product culture traits I’ve observed and seen bear fruit is to evaluate critically our past launches and work. When a certain feature doesn’t feel right for the current time and the state of the product, we’ve grown to not be afraid of unlaunching it.”

He also speaks about how to unlaunch (Isolate, Experiment, Unlaunch, Communicate). I found the post pretty good, especially some of the reasons he cites for unlaunching your products. The three that resonated the most with me are dangerous false precedence for creating similar mistakes again, opportunity cost often goes unmeasured and people shipped features that the users didn’t need, to get promoted. One additional reason I have seen in my experience is letting go of the opportunity to solve real problems the right way. The reason a feature was prioritised, develop and shipped to customers was that there was a real need. If the feature is on the axe table, then, it may not be solving it correctly. It is also likely that we have perhaps not understood the problem. As Albert Einstein said, “We cannot solve our problems with the same thinking we used when we created them.” Starting afresh is better than carrying on the feature - a bit like how you scrap your in-draft posts if they are not shaping up.

Harshjit Sethi from Sequoia, writes about this in his post on Anti-Product Roadmaps as well. In addition to the reasons that Hardik Pandya spoke about, he also mentions the culture of experimentation. This resonated with me. Without a strong culture of retiring features, you end up maintaining marginal utility features and perhaps also spend ‘more’ time on alignment and discussions, thereby compromising the speed and velocity of decision making. Organizations like Google and Facebook have shelved plenty of products (Google Reader is one I miss even today)!

Karthik Vaidyanath mentions that they maintain an anti-product roadmap at Indeed.com. The line that got me really excited is, “We have Tech OKRs around reducing operational maintenance by X%. That leads to teams automatically prioritizing some work around removing redundant features or improving push-on-green or other tech-operational improvements.”

Varinder Saini from Adobe mentions, “We have retired a few features for Adobe Acrobat. Framework Summary - Why does the feature exist in first place, what was our hypothesis, why we want to retire, what’s our hypothesis now, what has changed over time, how will it impact users, what’s our rollout/migration plan, messaging, support plan etc.”

If you feel this should happen anyway with a strong culture of experimentation, welcome to the club. Experiments also include a no-go decision and if we follow the spirit of Null Hypothesis, no-go should be the default answer. However, experimentation often leads to feature bloat (eg: YouTube video page which is clutter but apparently ‘metrics’ are not impacted ‘yet’). This is not what experimentation is about. Experiments should also help us decide on features that should be axed while still at an experiment stage and before they become more entrenched across the product.

Why do we keep iterating upon features despite experiments indicating a no-go decision? This is due to the age old question -> should we try harder on the feature instead of killing the feature?

The earlier the feature in its development stage, the more likely such a discussion. It is easier to continue to spend one more sprint on top of 3 months we already spent on a feature.

Experiments should also include hypotheses around removing features altogether and testing the impact (do customers really care?).

It is easier to say teams should be empowered and have courage but without the adequate structures and frameworks, it is tough to action this. That’s why I like the idea of reducing operational maintenance and anti-launch product roadmaps. I am also excited by the use of data science in tying up relationships between long term and short term metrics (example from Google) which can help take calls on stopping work on features and relook at problem areas that a feature or solution addressed.

Do you use anti-launch roadmaps or data science models to predict long-term metrics from short-term metrics? If yes, I’d love to Buy Your Coffee. Please reach out @vikramadhiman.