You’re staring at a long list of features. You can’t possibly build them all and meet your deadlines. Sound familiar? It doesn’t matter if you’re a Product Manager at Facebook, a founder in a start-up defining the Minimal Viable product or anywhere in between. Everyone has a list, everyone has to make hard choices on whether a feature belongs and how important it is to the product. Regardless of company size, planning processes, data points for analysis and methodology, the fundamentals of making good product choices are the same.
At a megacorp like Facebook there is a defined roadmap that looks ahead 3 or 4 years out. They can survey millions of customers to gauge adoption of any addition. A start-up or early stage company defining its first product’s feature set doesn’t have the resources or time to do such an in-depth analysis. They may be driven only by a high level vision and a handful of customers or prospects.
A good way to get started is to use this four question filter that guides your priorities: what goes in now, what can wait and what can be eliminated. With each feature addition, ask yourself the following:
- Does it add to your product’s core value?
- Does it target the primary user of the product?
- Do you have to build it yourself?
- Will the feature place you in a new market?
Does it feed or extend your product’s core value proposition?
Every product has a core value proposition; it’s the key reason your customers will pay for the product in the first place. (If you aren’t sure what that is, read Geoffrey Moore’s classic book on Product Management “Crossing the Chasm”. It includes some exercises to help you identify it. It focuses on how early-stage high tech companies move from innovation to obtaining early adopters and beyond. Watch this video for a quick overview of key concepts.)
As an example, let’s look at Facebook because it is so familiar. (If you have some strong opinions about their business model or other issues, put them aside for the exercise.) Information about you, your preferences and your relationships are the core of the product. Any feature that makes it easier to get that personal data into the system “feeds” the core. It adds value to both the user and Facebook. These might include:
- Any feature or enhancement that makes it easy (or fun) to add information
- APIs that partner sites or products that add personal information, for example a restaurant reservation App that adds to your food preferences.
- Supporting interfaces and platforms that facilitate adoption by as many people as possible, such as Web, Mobile, SmartTVs, etc.
Functions that “feed” the core make your product more valuable and sticky. Facebook began collecting that data before their current strategy was clear. They knew the “social graph” would have strategic value before they executed on “exploiting” the core. So, if you’re a newer company, prioritize and build out functions that “feed” over those that “exploit” core. Facebook started with things like:
- Finding friends and interests
- Alerts and notifications that tempt you to come back frequently
- Adding content easily
- APIs to outside partners whose sites or products add to gathering information
Facebook prioritized “feeding” the core for years before moving on to the “exploiting” the core; adding the profitable advertising platform. Initially, the only feature that “exploited” the core was sharing statuses with your friends on the feed and “poking” them. This led to more engagement and use; their primary mission at the time.
A totally different “people” platform is an Enterprise Learning Management system that tracks corporate training. (As founder of the Pathlore LMS, this was near and dear to me.) The main reason large companies implemented an LMS is to ensure that employees complete required training, especially those with regulatory requirements, like OSHA or HIPPA. The “core” of an LMS is employee’s training records. Any feature that gathers training records is key.
When looking at your list of features, there will be “which comes first” decisions. Prioritize “feeding the core” in the early stages. Functions that “exploit” the core, though may be of higher value to the customer, are meaningless without a well fed core.
Does the feature target the primary user?
When you build a product there should be a primary user in mind that “feeds” the core. (If you’re using Agile, it will be one of the defined Personas.) Facebook’s initial users were college students; initial features were designed to engage them and no one else. It was a singular focus; make it simple for the primary user to share more and more about themselves.
It had to be so easy that the user could do it quickly and reflexively. The next step was to go beyond a text status; images, videos, links. Make a user’s interests and preferences known in a simple click. (More feeding.) In other words, a lot of work went into simplicity and reducing “friction” of sharing.
Facebook made a mistake when they ignored that their target users moved to smartphones and apps for communicating with friends. That created a new “friction” point; going out of a user’s normal “workflow” to add content. They were getting competitive resistance from new companies that started as Apps. Facebook was fortunate to have enough funding, resources and discipline to correct that. Most emerging companies don’t have all 3 or even 2 of those.
As another example, in an Enterprise Customer Relationship Management System, there are multiple users “feeding” the core. It starts with sales and gathering information about leads and new customers. A busy salesperson won’t learn a complex interface and is on the go; functions that are simple and mobile go to the top. Getting them to enter data at the end of a long day on the road must be primary.
In the Learning Management System example, the primary user was the person, usually in the training department, who had to maintain the records. If it wasn’t easy for them, the system might not be used.
Don’t confuse the primary user with the buyer. With a consumer product, they may be one and the same. In an Enterprise product, the benefits are usually for management. But, the primary user, the one that uses the product day in and day out, that ensures the ongoing success. For example, in analytics software, management benefits from data visualization that data scientists create, test and deploy.
Looking at your product, who is the actual day to day user of your product? (Which Persona is feeding the core?) Can they easily use your product to “feed” the core and is it built into their logical workflow?
Will the feature take on a life of its own?
Let’s continue the Facebook example and use a “deceptively simple” feature request that an early product manager may have received: “I want to post a picture.” Photos are important data points for knowing about people and their connections. Who is in the photo? Where was the photo taken? Are the people, place or event in the photo popular? All of this information “feeds” the core, so they had to tackle the feature.
When looking at a deceptively simple feature, don’t succumb to the “reverse telescope” effect. Looking through the wrong end of a telescope makes objects appear smaller and narrows your field of vision. It’s easy to think: “This is simple, we’ll just let them upload a picture and display it.” So take the time to think ahead at what the customer and your engineers may ask about:
- How will the user add photos and images? (It has to be easy.)
- Where will the business store the images? What format? What size? (Storage and bandwidth costs can grow quickly if you’re successful.)
- Will your user demand a rich set of editing features (A quick review of mature sites like flickr or photobucket would give you a preview of where it’s headed.)
- Will the user demand ways to organize and search photos? (Apple, Android and Facebook all have rich self-organizing and search features).
It’s clear that sticking your toe into accepting a photo can lead to a cycle of more and more feature requests. If you’re clear about your primary user, you can set clear boundaries of how far you’ll go or if you even want to start down the road.
Smaller companies often wear “not invented here syndrome” blinders and believe that they have to build it. Even simple features have ongoing costs of maintaining the a “simple” feature, let alone what it may morph into. If a simple implementation won’t make customers happy and building a complete solution is not strategic, look at partnering, licensing or acquisition. In today’s cloud environment, commonly used functionality is often available through an SaaS API from a vendor who focuses on that particular problem or a major cloud vendor.
For example, Azure, AWS and Google Cloud have native features that support image storage and management; particularly image recognition. Other cloud based services, such as Cloudinary, offer complete photo and video storage, manipulation and delivery services that can turn a minimal solution into a complete one.
Facebook, when faced with this issue, took the next step of acquiring photo technology with multiple acquisitions. But, even a smaller company can look at possible acquiring core functionality as a goal. (Or even the reverse, can become an acquisition candidate of the company providing that strategic capability.)
In an Enterprise product company, a common problem is reporting and dashboards. No matter what you provide, more reports and flexibility are always requested. In the early stages, implement the minimal high value reports.
When adding an important feature that has potential to grow and isn’t strategic, prioritize only a minimal approach to test the water. As you get customer feedback, determine if a more complete solution is required. If you can partner, license or acquire the capability, then integration rather than building will rise in priorities.
Will the complete feature take you into a new market?
Finally, when adding a new major feature, consider if you may be moving your product and business into an entire new market with larger competitors or those with an entrenched solution.
In the Learning Management System example, customers would ask us for a testing module; the ability to author and deliver online tests. Employees have to pass these tests and quizzes to demonstrate content mastery. We did build a very basic engine. But, we also knew that the “Online Testing” market had mature competitors with a rich, feature set that weren’t strategic to our mission of getting training records. Rather than build it out, we partnered with those with a complete solution via standards-based API integration.
A familiar consumer example is Fitbit, an early leader in the IoT wearable health and fitness category. Their founders original vision was to have a wearable “smart” tracker that can clip on to your clothes. The idea stemmed from seeing women putting bulky phones in their exercise gear… aha! a small unnoticeable clip is missing from the market. Their strategic decision was making exercise a social activity; people “feeding” the core information of pedometer activity was initially “exploited” through sharing and gamification! They added badges and sharing of accomplishments to make owning a Fitbit viral. (They fed Facebook’s core, too.)
They were amazed when customers asked for badges above 25k steps per day. They had targeted the casual fitness buff/weekend warrior, but also acquired performance athletes.
Likely the performance users requested heart rate monitoring. But, that could not be measured with a clip on tracker. So, they decided to add wrist worn trackers to their line. They did a lot of R&D and refinement of algorithms to get trackers on the wrist to be as accurate. Of course, by moving into a wrist worn tracker, they dipped their toes into the watch market. The timing was just as the smart watch category was emerging.
Fitibit now has a whole line of wrist worn smart trackers and watches at various price points (6 in total). They placed themselves in competition with watches that people already own AND tech giants like Apple and Google; not an enviable position. Add to that, their 6 or 7 wrist products compete against each other. They eliminated the clip-on tracker, which was the original vision. It remains to be seen if their strategy is successful in the long run.
One thing is certain, the heart rate feature took on a life of its own, brought on new competitors and transformed the company. It remains to be seen if this strategy will work out in the long run.
When adding a new major feature, don’t accidentally pivot your product or business into a new category with new competitors. Deprioritize or even eliminate these potentially hazardous features.
When reviewing the feature list of your MVP or a newer product:
Prioritize features that “feed” the core. They will attract your primary user and help make your product “sticky”.
Prioritize features that target your primary user. Make it easy for them.
Deprioritize features users won’t consider “complete”. Don’t overbuild before you get feedback. Look for licensing, partnering or acquisition opportunities.
Deprioritize features that will place you into a new market. Don’t accidentally move your product into a whole new category with new competitors.