How To Create A Kick-Ass Product: Cull Your MVP Ruthlessly
This is part 2 in a series about how to create kick-ass software products. You should probably read part 1: Use an Inter-disciplinary process.
During the past 3 years, Konsult has worked with over a dozen startups. The one piece of advice we give the most often is:
Your MVP has too many features.
Everyone says they understand the Minimum Viable Product. But when it comes to killing off your own extraneous ideas on something that is the passion of your life, few founders do so willingly. Here’s how we help them focus on the big picture:
When you’re new, nobody remembers your mistakes. Imagine that you’re trying a new app, and it just sucks. Are you going to start an angry rant on Twitter about something no one’s heard of? No. You’re probably going to think “that was a waste of my time.” (Unless the app is leaking confidential information, that’s different.) You’ll delete the useless app, and go on with your life.
So go ahead, make some risky decisions. The worst case of shipping an incomplete product is that you will have very few users. Shipping a product late (or running out of money) is that you will have no users. The better bet is on shipping early with fewer features.
It’s harder to remove a feature than to add a feature. I was at Apple for more than 3 years. That entire time, our team was fighting to remove a useless feature: something very few people used that was costing a lot of time to maintain. Why did it take more than 3 years to remove such a costly and useless feature? Because some high-ranking people in the company used it.
The same happened when we tried to completely redesign the Safari UI. Over the years, Safari has collected many buttons and views, each with their own style congruent with when they were released. These features are still useful, but they were using a design language from years ago and they were making Safari look clunky. I started exploring the idea in 2010, formally working on concepts in 2011. I interviewed my colleagues, I created concept sketches, I interviewed more people for feedback, I created high-fidelity mockups, I pitched them to directors, I created interactive prototypes, I pitched them to directors some more… Everyone loved the idea of removing less-used features from the main UI, but every feature had a user that loved it. Eventually, because there was no agreement on which features can be removed, the designs were not approved…
Then, when Safari 8 was released in 2014, it was updated to the new, simpler look I was working on. I was no longer at Apple, so it was bittersweet to see my designs finally become reality.
The fact that the Safari UI “clean-up” took almost 4 years is just another example of how hard it is to remove features.
Many large legacy softwares suffer from being stuck with features that don’t provide value. Some are due to poor insight on user needs in the beginning, some are simply due to the shift in user needs and the passage of time.
When you add a feature due to user demand, users celebrate. When you remove a feature due to cost of maintenance, users — however few — complain. Loudly. So unless there is a clear business or usability case for a feature idea, it’s better to devote your resources to the core features.
Mistakenly not doing something takes less time than mistakenly doing something. That was a mouthful. If you’re working on a new product, you’re probably limited in time and budget. And when a feature has questionable ROI, you should side with the more frugal side.
If you didn’t build a feature you need… and need to add it on later, you incur a little bit of overhead in project management, but spend about the same design and engineering time as building the feature before the user feedback.
If you didn’t build a feature you didn’t need… then you saved more time for the really important features!
When Konsult was building an internal tool for our client, SilentPartner, we always opted for less features and earlier feedback. For example, this software was used by clients, vendors, and employees, and we weren’t sure how many levels of user permissions we needed due to different . We decided to try the most basic option: a user can edit everything or edit nothing. When we tested this permissions system with SilentPartner, it turns out this basic system works for everyone (for an MVP). We were able to ship the product earlier and cheaper by building the most basic permissions system.
Most founders love their work. They strive for perfection in what they create, but perfection is the achilles heel to getting a product out the door. Your MVP should serve your core business goal — be it generating revenue, collecting user feedback, or just garnering public attention — and it should do so in the cheapest and fastest way possible. Polish should be saved for later iterations. If you’re not a little embarassed about quality of your MVP, you’ve spent too much time working on it.
This was part 2 in a series about how to create kick-ass products. Here are the other parts: