Building Products & Saying NO

 

Learn to say NO to the good and the advantageous, in order to receive the best!

― Sunday Adelaja

SayNo

If your Product Management team is responsible for building products, features/ideas get thrown at you – by your product team members, sales/marketing/support groups, competitive analysts, customers, partners, executives, etc. On one hand, you have the responsibility to ship a well-rounded and a well-balanced product that serves the needs of your customers. On the other hand, you have the wish list fire-hose pointed at you.

Arguably the toughest decision a Product Management team makes is – what features to include and what features to exclude. What do you build now and what do you postpone? If the goal is to offer a well-rounded product experience to your customers, I would argue that what you say NO to is more important than what you say YES to.

Rather than making ad-hoc YES/NO or NOW/LATER decisions, here is an objective framework that mitigates the subjectivity in this decision-making process using 5 vectors of evaluation:

 

1. Utility Value & Breadth of Impact: This one is fairly straightforward. For the feature in question, ask yourself (from a customer perspective) 2 questions – (1) how useful is this feature (2) what % of my user-base will find this genuinely useful. Where possible use data to support your decisions – e.g. you could analyze your Google Analytics stats to understand how often a similar feature is being used in your existing product. These questions will help you weed out “pet projects” or cool sounding features that have little or no utility in real world.

 

2. Table Stakes: In late 90’s, much before Bluetooth and USB became popular, some computers offered IR (infrared) ports so that devices like PDAs could wirelessly connect to computers. In reality, these IR ports were rarely ever used. However, because an IR port was a common requirement in the corporate purchase checklist, most laptop manufacturers would include the IR port in their corporate class laptops even though they were rarely ever used – i.e. the IR port became table-stakes in the corporate laptop market.

Another contemporary example is the phablet product.When Samsung launched their Note phablet in 2011, it became a runaway success. Apple on the other hand, stayed away from phablets given Steve Jobs’ disdain for the large devices. Samsung Note was capturing so much market share (especially in Asia), after 3 years of resisting, Apple capitulated and launched their iPhone 6 Plus phablet in 2014 – they needed a phablet in the product lineup to stay competitive.

In your market, is the feature under consideration table-stakes based on customer requirements or competitive positioning? If so, you may no choice but to offer that feature sooner or later.

 

3. Basic VS Advanced: A few months ago I upgraded my audio receiver to a Sony DN1050 – I needed a receiver with AirPlay support. The DN1050 is a pretty sophisticated receiver that supports AirPlay, NFC, multiple zones, 4K scaling, Bluetooth, Wifi, DLNA, Pandora, Spotify, etc. BUT… it only supports 2.4Ghz wifi – no cigar with 5Ghz wifi support. Arrrgh. Why would a world class company like Sony build a sophisticated $600 consumer electronics product that relies on wifi and yet exclude 5Ghz support. My $50 Echo Dot supports 5Ghz!

This is a classic example of a somewhat disjointed product that supports sophisticated features and yet misses the basics (5Ghz wifi channel support) – that’s a head scratcher.

When building products, it’s important to cover the basics before you start considering advanced/complex features. This is a fairly simple principle and yet it eludes so many products!

 

4. ROI (effort vs benefit): Every so often you come across a feature that sounds useful – but expensive to build (in terms of time & resources). If that feature is applicable broadly, benefits a wide swath of your user-base, or gives your product a strategic edge, it may warrant making that investment. Otherwise punt it for later!

 

5. Strategic Importance: When Apple launched Siri in 2011, it was labeled as a beta. As far as I know that was the first time Apple released a feature labeled as beta (while embedded within a mainstream product) to general public. Apple knew that Siri was not fully ready for prime-time and yet they released it early on because of its strategic importance. By releasing it early and collecting anonymized voice samples, Apple was able to iterate and improve Siri over time. Now Siri is an integral part of their iOS, macOS, watchOS and tvOS.

 

Summary: For every feature/capability on the product roadmap, it’s important for Product Management teams to consciously deliberate on the YES/NO decision based on objective criteria that suit your needs (market requirements, competitive situation, strategic importance, product maturity stage, etc.). Without this deliberation, if every idea gets a YES rubber-stamp, products runs the risk of becoming a disjointed mishmash that could earn your customers wrath!

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s