Minimal To The Max

It sounds counter-intuitive, but building less will help you create a better app experience

I was speaking with a friend who was looking for advice about building a new direct to consumer service. Specifically, he was wondering:  with the crazy number of options available, how do you figure out which are the right features or services to start with? My advice: as few as possible.

If you know my work, that’s nothing new. I’ve been trumpeting a minimalist approach to product development since I started. But why is that a good strategy?

Let me go back to the beginning. After a career as a journalist and later evolving into a product manager for content, my work had caught the attention of senior management, who tasked me with rebuilding the Rhapsody product team after another one of house cleanings that commonly occur in the tech industry.

Before being thrown in the deep end of the job, I got some training from Marty Cagan which was incredibly instructive about how to approach the product management process. But I also got even better practical advice from two of the smartest people I know in the product game.

First, I met with Tom Andrus, who gave me tons of amazing practical tips on building teams. Tom was product lead and held a bunch other roles at Earthlink and has since run numerous product and management teams, including AXS where he’s currently president of the company. He imparted a great philosophical framework for making decisions on what to build.

Tom said that when he thought about building a product roadmap, he wanted to make the smallest number of features possible. He suggested that the more features you build, the more opportunity there is to screw something up and, even more importantly, for users to get confused about the purpose and the aim of the product. ‘Why build three features when you could build two, or just one? Or even better, how about removing a feature that is underperforming instead of launching more stuff?’

The second person who led me down the minimalist product path was Anu Kirk, an amazing product manager who had my job before me. Anu told me he I liked to practice what I call the Lazy Product Manager approach. Much like Tom, Anu thought that less was best when it came to features, so he tried to build and prioritize only a few features.

I took this advice to heart and tried to fight the good minimalist fight at Rhapsody. Only to end up launching a fair number of stupid apps and features in my time. Why? Well, the reality is that it is much harder to put this into practice than it would seem. It starts with the psychology of work. Product managers and software engineers are hard wired to ‘do stuff.’ Ninety percent of the time this means adding that one feature that will attempt to address a nagging problem for the company.

But as you add on more features, widgets and instructions, you end up asking the user to deploy more and more of their brain power to figure out how your service works, frustrating them to the point where you get in the way of why someone is using your product in the first place. Outside of the cost to the user experience, my experience is that most features do little to address the inherent issue it was meant to solve.

This was my experience at Rhapsody. We didn’t make great progress in solving the company’s problems, which admittedly existed outside the realm of what any product team could solve. Some of the features we built and rolled out were tactically smart but strategically akin to powering a rowboat with a single oar. For example, it’s great if you improve your app’s active rate by 25 percent. But if the real problem is you’re getting killed by a new competitor with app downloads by the millions, why even bother improving that KPI. Our entire small industry was about to get wiped out by Spotify, and that required drastically different strategic thinking. Tactical improvements really were just busy work.

After a new regime came in it was my turn to leave the company. The new product managers didn’t quite have the same approach to product and the number of features exploded to the point of the Rhapsody app becoming a “Swiss Army Knife of features and pet projects,” as one developer at Rhapsody described the app to me.

After a couple more gigs, I really thought about problem more coherently when my co-founders and I started Gimme Radio and we were able to put the minimalist product strategy thesis into practice. By focusing on a small number of features, we had much better control of the success of the business. And it made it a lot easier to diagnose and address problems that pop up.

For example, we launched Gimme first as a desktop and mobile web service to get it out the door as soon as we could. Soon afterwards we launched mobile apps for the service. After about year we found that mobile web was drastically underperforming as an engagement product and quickly pivoted it to a user acquisition tool. Having only a couple features allowed our team to focus all our efforts on growth performance instead of chasing the next hot thing that was getting all the buzz. And maybe even more importantly, what we launched worked extremely well leading to very high customer ratings in the app stores.

Never Stop Asking Why

Whenever I’m running a product development team, I look at the benefits of new features and products with intense skepticism.  The first order of business is to make sure you’ve done the work in verifying the thesis of the benefits of what you’re proposing. The process I follow is to build the case for the feature in a product brief. Far from being a PRD, which most of the industry now eschews, the product brief serves as your Bible for the product. Someone should be able to read the six to 10 pages of the brief and clearly understand why you’re building the feature and what the justification is for doing so.

I have a section in my product brief that asks: ‘What evidence is there that this is the right product/feature?’ When I give it to junior product managers to fill out, I generally get a one-line response, often based on their opinion or worse, how they personally use the product. It glosses over how much thinking really goes into getting the answers. Of course, it should be informed by subject matter expertise and personal experience but must be supported by copious amounts of research, competitive teardowns, data analysis, customer surveys and feedback sessions, and technical validation studies. It should take weeks if not a month to properly answer the question appropriately. 

And while the business owners might push back and complain about needing it built yesterday, without this knowledge, chances are you’ll find yourself in one of those rowboats with a single oar.