Building Products for the Vocal Minority… or the Silent Majority?

Originally posted 4/3/2015

Congratulations. You did it! You successfully launched your product and now, among other new and exciting challenges, you have customers and users to listen to, keep happy, and to worry about. For most of us, these customers usually shake out into two buckets:

  • An enthusiastic, vocal minority. These are the customers you hear from frequently and effortlessly- they post to your help forums and support sites, email your founding team directly, and enthusiastically push the product team for new functionality and product changes.
  • The silent majority. This is everyone else, enjoying your product and services or suffering in silence. They’re not invested or empowered enough to give feedback.

For product managers deciding which features and fixes to prioritize, things have suddenly become a lot more complicated. It may be easiest to listen to the vocal minority, but if you do, you risk alienating the majority of your customers and taking the product in a direction that has limited usefulness and limited market. However, ignoring the minority entirely is rarely a winning strategy. Frequently, this bucket contains many of your most influential (and highest paying) customers. Their continued satisfaction is important — and their investment in your product’s success can be leveraged for ongoing benefit.

So, how do you proceed and set yourself up to make quick and accurate decisions about what to build and when? I recommend keeping 3 simple principles in mind as you grow your product and your business:

Invest in analysis.
Validate before you build.
Build for the right audience.

Invest in analysis

The first people who use — or pay for — your product will likely be the most enthusiastic and invested and, as a result, are frequently the ones who push for more features and functionality. This group also rewards new features with praise and adoption. If they are your only source of input and product validation, their feedback is likely to push you further and further down a path towards bloat and complexity. Rather than rely exclusively on easy-to-get feedback from these customers, it is essential to take steps to ensure your silent majority has a voice, too. Make an early investment in product analytics and other methods to capture feedback from the rest of your customers. It may be the most important investment you make.

Fortunately, the cost of this investment is usually quite small compared to the reward. In the past several years, a sea of options have popped up to help track and analyze user behavior. Tools like Google Analytics, KISSmetrics, Mixpanel and more are easy to implement, inexpensive and essential, so take the time to track what your users are doing (and not doing) within your product in order to help influence prioritization of any new features and fixes.

Often times, of course, data analysis leads to even more questions — many of them beginning with “why”. Questions like “Why is no one using a particular feature?” and “Whyare users abandoning the service?” Compliment your analysis with other methods like user surveys and usability testing until you know exactly who your silent majority is. Even in my early days with Box, we were finding low-cost, high impact ways to hear from our users — recognizing that buyers and administrators had an outsized voice within our organization. We ran ad-hoc user studies, sent an endless stream of surveys to various customer segments, and instrumented and analyzed key activities ad nauseum.

Since you’re going to need to advocate for your silent majority as you continue to grow your product and your business, you need to do the hard work to understand them completely. It’s tough work, but it might just ensure that your product has a future.

Validate before you build

Product complexity is one of the biggest risks to your company’s success. Before you add one more feature or one more option for users to choose between, you need to be certain it is benefitting your customers and your business in the ways you expect. Again, you’ll find you can take one of two paths here, the easy path or the hard. On the easy path, you’ll almost certainly face the temptation to make your product configurable. The logic goes something like this: “Customer X really wants feature Y, but I’m not sure anyone else wants it. Let’s just give our customers the ability to turn the feature on if they want it.” Don’t give in to this temptation. Validate that you’re building something that’s needed by a large enough cross-section of your customers before you build, because complexity can kill your product and waste your time.

Remember, configurability…

  • is impossible for engineering to maintain.
  • is impossible for user services to support.
  • is frustrating for customers to use.

The more variables you introduce, the harder your product becomes for QA to test, leaving your customers exposed to unnecessary and annoying bugs. With many distinct paths from A-Z, your support teams cease to have a clear picture of how any one account is configured. As a result, your help content becomes unmanageable and your support staff can’t provide quality support without several rounds of back-and-forth with the customer. Finally, the abundance of choice will ultimately begin to overwhelm and frustrate your customers, causing them to leave for an easier-to-use competitor.

So, whether you decide to add functionality because you feel it solves a problem voiced by your vocal minority or your silent majority, make sure you look to both customer segments for validation that you’re making good product and design choices. Capture feedback through surveys, A/B tests and in-person conversations. Put design prototypes in front of users every chance you get — and never be afraid to change the scope of a feature in order to deliver value to a broader set of customers.

Build for the right audience

Of course, it’s not always the wrong decision to build a feature for a small segment of your user base. Let’s be realistic, some features are clearly built to deliver outsized benefit to — and capture outsized revenues from — a small fraction of users. But every feature needs to know its audience in order to be successful.

If a feature is built with mass appeal and adoption in mind, be bold and take a stand. Get your feature in the face of your users and set your expectations high. If users aren’t adopting the feature, you’ll know it’s due to a flaw in your hypothesis (which you should have caught earlier) or a gap in functionality — not due to lack of discoverability. Take Box Notes as an example: it has top billing alongside Upload on every folder in Box.

Similarly, if a feature is designed to appeal to just a few, keep it quiet. Without naming specific products that drive me nuts, let me ask, how frustrating is it to need to page through an endless set of options in a menu or toolbar every time you try to get work done? Often times, my needs are quite basic, but in many products, I’m frequently stumbling over too many options and configurations, leaving me eager to find a simpler alternative to help me work faster and more efficiently. When building additional complexity that is designed to only be useful to a small percentage of customers, be sure to consider the following tools:

  • Default behaviors
  • Progressive disclosure of information and options
  • Pricing model

Default behaviors. Default to the behavior that benefits the most customers in order to provide the majority of users with a frictionless path through your product. Decisions are hard, and being confronted with too many decisions can be overwhelming and frustrating to users, so if you know that 80% of users or more are going to take one path through your product, go ahead and choose their defaults for them.

Progressive disclosure of information and options. In many successful products a world of functionality is hidden just below the surface. These are the features that give a product like Box its power — things like shared link permissions and expiration dates, access statistics and upload options — but are only ever expected to be used by a fraction of power users, or users in specific industries. They don’t disrupt the productivity of the majority of users, but are easy to access if you know where to look.

Pricing model. One of my favorite options is to make customers pay for additional functionality. If your product can support it, consider putting advanced functionality for the vocal minority behind a paywall, thereby ensuring that only the customers who need a feature are seeing it. This keeps the experience for the majority of customers clean and friction-free.

Don’t lose the urgency

Congratulations again on your launch and the new set of challenges that will persist as you grow your product and your business. But just because you’ve made it this far is no excuse to lose the urgency that got you here in the first place. Analyze, validate and build rapidly… then repeat — because each day brings new inputs and new conflicts between the needs of the vocal minority and those of the silent majority. This tension — and the perpetual balancing of the needs of your customers — is key to the long-term viability of your product. By adhering to principles that keep the needs of all users part of your prioritization process, you are able to grow your product’s usefulness and use cases while avoiding detrimental product complexity.

Show your support

Clapping shows how much you appreciated Brandon Savage’s story.