What You Can Do to Simplify Your Products
I came across a Tweetstorm from Mark Suster last weekend that got me thinking.
After reading Mark’s Tweetstorm, I was reminded of an excellent blog post by Paul Buchheit (one of the creators of Gmail): “If your product is Great, it doesn’t need to be Good.”
Two of the key passages from Paul’s post are:
Pick three key attributes or features, get those things very, very right, and then forget about everything else. Those three attributes define the fundamental essence and value of the product — the rest is noise. For example, the original iPod was: 1) small enough to fit in your pocket, 2) had enough storage to hold many hours of music and 3) easy to sync with your Mac (most hardware companies can’t make software, so I bet the others got this wrong). That’s it — no wireless, no ability to edit playlists on the device, no support for Ogg — nothing but the essentials, well executed.
And:
By focusing on only a few core features in the first version, you are forced to find the true essence and value of the product. If your product needs “everything” in order to be good, then it’s probably not very innovative (though it might be a nice upgrade to an existing product). Put another way, if your product is great, it doesn’t need to be good.
I completely agree with the sentiments expressed by Mark and Paul. In many ways, less is more and simplifying products can make them so much more powerful. But what makes simplifying products hard in practice? I recently had a conversation with a group of PMs, and we identified three challenges to simplifying products:
- Adapting to an existing product category
- Biasing too much towards power users
- Relying too much on what customers tell you they want
Adapting to an existing product category
When you enter an existing product category, your customers may have expectations for what the “basics” are for any product in that category. You therefore may need continuity with what is already out there, which drives you in the direction of building “parity” features that already exist. The critical question is: “Which parity features are truly a hard requirement for the existing category? Are there any we can live without?”
Biasing too much towards power users
When you introduce a new product, sometimes the early adopters are “power users.” These users may therefore ask for a ton of features. But when you hear a long list of requirements from power users, it’s hard to distinguish between what’s really a hard requirement vs. what is nice to have. It’s hard to know which power user features will really apply to your product’s mainstream users. As a result, you may end up building too many features than you need initially.
Relying too much on what customers tell you they want
When talk to customers, one risk is relying too much on what they tell you that they want. Customers will typically compare you to what else is already out there, because that’s their frame of reference. “Well, XYZ has this, why don’t you?” This input will help you uncover competitive parity gap features — but many of these features may not really be must-have features. If you over-rely on this input, you end up building products that have long lists of features that try to address every single competitive parity gap. And if you try to please all of your customers, you may end up building one-off (niche) features that only apply to a small number of customers.
So what can product managers do to address these challenges?
- Get to know the “why” more than the “what”
- Be skeptical. Don’t take input at face value. Ask critical questions.
- Be clear on the purpose of your product
Get to know the “why” more than the “what”
The best advice I’ve heard about building products is what Steve Blank often says: “There are no answers inside the building.” He’s referring to getting out of the building to talk to customers.
When talking to customers, go beyond explicit needs (“what customers tell you that they need”) to uncover implicit needs (“what customers need, but that they don’t tell you”).
Focusing on implicit needs will uncover the underlying problems customers are facing, and then you can propose solutions. This is much better than relying on customers to tell you what they want.
Customers may default to pointing out competitive parity gaps, because that’s what they already know. They may also not know what is possible for you to provide.
Big bets are profoundly better, radically different, and intrinsically surprising. Customers will not tell you to create a big bet. They won’t be able to tell you to build things that are radically different and intrinsically surprising.
Your job is to uncover the implicit needs, and think about how you can uniquely solve their problems.
Be skeptical. Don’t take input at face value. Ask critical questions.
When someone (a customer, an internal stakeholder, anyone) suggests a feature request, try to understand a lot more about the “why” before you accept the request.
“Why do you need this? What problem does this solve for you? How often do you do this activity?” etc. Ask lots of questions to understand the “why” before committing to building the feature.
Maintain a high bar for deciding to include a feature in your product. One suggestion is to “start with no.” In that spirit, the Basecamp team, authors of “Getting Real,” have written:
Make each feature work hard to be implemented. Make each feature prove itself and show that it’s a survivor. It’s like “Fight Club.” You should only consider features if they’re willing to stand on the porch for three days waiting to be let in. That’s why you start with no. Every new feature request that comes to us — or from us — meets a no. We listen but don’t act.
The initial response is “not now.” If a request for a feature keeps coming back, that’s when we know it’s time to take a deeper look. Then, and only then, do we start considering the feature for real.
Be clear on the purpose of your product.
If your product has a singular vision and purpose, it becomes easier to say no to extraneous features and requests. This applies not only to the overall product, but also to each subsequent release.
Products that have a singular vision and purpose include Uber (“Tap the app, get a ride”) and WhatsApp (“Exchange messages without having to pay for SMS”). There’s of course a lot of value and depth behind the top-level vision and purpose. But having a singular purpose makes it easier to say “no” to potential distractions.
You can apply the same logic to a product release. Each product release should have a singular purpose — “this release is all about ‘X.’ ” The singular purpose could be improving usability, increasing performance, introducing a new innovation. If you keep the release focused on a single thing, it makes it easier to decline adding extraneous features.
If you want to build innovative, delightful products — you need to simplify them. As Mark Tweeted, one of the hardest parts of product management is saying no. And as Paul wrote, if your product is excellent at a few important things, that’s a lot better than slightly good at many things. But simplifying products is hard — when you’re adapting to a known category, or because you’re over-relying on what customers tell you to do. To get better at simplifying your products, go deeper to understand the “why” from your customers; be skeptical and ask critical questions; and have a singular purpose for your product or feature.
If you enjoyed this article, please click “recommend” and check out additional posts in my publication PM Insights: Lessons from Being a Product Manager.
