Daniel McKenzie

digital product design

MUSINGS ON DESIGN, TECHNOLOGY AND CULTURE {STUDIO NOTES}

Selecting the right features for your product is a tough topic that defies any clear explanation. The fact is, you could read a hundred books on innovation and play brainstorming games until you’re blue in the face and still launch with the wrong features. The hard truth about deciding on the right product features is that formulas and methodologies can only take you so far and that the rest requires a bit of magic. If this weren’t true, we would have more people like Thomas Edison, Henry Ford and Steve Jobs.

The problem is there are simply too many angles to assess when deciding on a product’s feature set. Some of those angles include the messiness we call human emotions which have a tendency to be fickle and be influenced by social forces we only notice after it’s too late.

Why does it require magic? Because magic is what it takes to predict the future and innovate after you’ve done everything humanly possible to understand the issues. The magic comes from a team or individual who has a vision—who can immerse themselves in the issues, fly above them for a bird’s eye view and come out the other side with the “right” solution.

Having a vision is a special and rare talent that just because you’ve earned a Harvard MBA doesn’t qualify you to possess it. It’s why we celebrate people like Steve Jobs and his accomplishments. Sure, Mark Zuckerberg created Facebook (perhaps, a little by accident) but it’s Jobs who hits it out of the park over and over again and it’s only Jobs who has enough credibility to call his latest creation the “post-PC device.”

Many CEOs of startups already sense and envy this magic. Where they get in trouble is when they naively believe all it takes is gut instinct to arrive at the right product. They skip the homework and go right to the exam, failing terribly. Not only do they lose by not understanding their customers, but they may not possess that special ability which allows some to make keen observations, feel empathy for their users and stitch together conventional elements to invent something different and delightful.

So, arriving at the right set of features for a product is a combination of both process and magic where one is a tool for learning and the other for predicting a future state. Fortunately for us, the first part is something that can be learned and put into practice. The other one involves genius and maybe more luck than we’d like to admit. (After all, who could have guessed that a micro-blogging tool with a 140 character limit would be such a hit.)

The following covers the part we can learn and outlines a method for arriving at an initial set of product features that can then be designed and tested for perceived value. Each phase builds from the previous one and while it may seem like a lot and take a few days to get through, it’s a necessary process for approaching the problem at many angles. To complicate things further, every product and situation is unique but by covering a multi-vector research plan (looking at customers, trends, technology, competition, etc.) we begin to strategically narrow down the list of possible features for our product and find room for innovation.

Immersion

Before we can begin to talk about our product’s feature set, we need to envelop ourselves in what we’re about to examine. An immersion phase provides the knowledge foundation for making educated guesses that we can then test, revise or throw out. Immersion give us insight into what the issues are in the first place and exposes the different angles to the problem. As you can imagine, skipping this important phase is just like showing up to the exam without studying. Do your homework!

According to Adam Richardson, creative director at Frog, immersion brings together a multitude of factors:

  • Competitors (direct and adjacent)
  • Comparative companies and products who can provide useful lessons
  • Your company’s own business, capabilities, brand and values
  • Broad cultural and economic trends
  • Technology enablers available internally and externally

It may be added that the tools for arriving at these factors include:

  • Competitive and comparative analysis
  • Surveys
  • Customer/partner interviews
  • Ethnographic studies
  • Persona creation
  • Scenario/task exploration
  • Usability testing (current product or competitors’ products)
  • Researching new and available technology

A competitive/comparative analysis helps us understand where there’s room for differentiation, what conventions already exist, and what available technology there is. While our user research and documentation helps us understand who we’re selecting the features for and in what context they may be used.

Setting Product Goals

Once we’ve set up our knowledge base we take a day or two to educate all the stakeholders and next, begin the ideation phase. But before we dive into a brainstorm session we need to discuss and list the goals surrounding the product. This will help us not waste time on ideas or concepts that are not in the current interest of the business.

Some examples of project goals include:

Business Goals
e.g. drive foot traffic to locations, educate, register users

Product Goals
e.g. longer user engagement time, provide online support, ease of use

User Goals
These typically come from the created personas which in turn, come from research

Short-Term Goals
e.g. launch for upcoming event, register users, mobile presence

Long-Term Goals
e.g. make money, launch enterprise version, charge for business services

Non-Goals
e.g. maximize revenue, provide full-featured app, satisfy all customer types

Ideation

To begin the ideation phase, we place on a wall or whiteboard four labels. A moderator will use sticky notes to write down any proposed features and place it under a label. Some areas will already be filled with product feature ideas gathered from our Immersion Phase (i.e. business requirements, user goals, features most competitors already have, etc.)

The four designated areas act as catalysts for product feature brainstorming and put both the “known” (gathered from research) and “unknown” (future-predicting innovation) side by side.

The objective isn’t to restrict ideation to confined containers, but to ensure we’re considering all the major product angles. To keep the session free-flowing, ideas may be duplicated under one or more areas and/or combined. Using sticky notes makes it easy to swap ideas from one category to another. Participants then add to the existing pre-populated ideas and debate and discuss additional ways to innovate.

The four areas include:

Features based on business requirements
This area includes pre-populated features (sticky notes) based on stakeholder interviews from the immersion phase. However, additional requirements may be added as the product discussion widens. This typically includes features like user registration, optimization, login, etc.

Features based on best practices
Includes pre-populated features based on competitive and comparative analysis. Features may include the ability to upload images, search, offline support, sync between multiple devices, etc.

Features based on user goals
Includes pre-populated features based on customer research and personas. This essentially shows what users are wishing for but also leaves room for brainstorming unmet user/customer needs and desires.

Features based on innovation
This is the only area without any pre-populated feature ideas. The previous three areas help ensure we’re covering the essentials. The ideas generated for the innovation area come from discussion surrounding competitive differentiation, market opportunity and emerging technologies and typically make room for any ‘blue sky’ thinking.

To capture what was gained from the brainstorm session, pictures are taken of the whiteboard display, summarized in a document and shared among participants.

Narrowing the Feature Set

Brainstorm sessions are for idea generation, not for deciding feature sets. This is sometimes difficult to communicate to impatient CEOs who wish to walk out of a four-hour brainstorm session with a fixed feature set they can hand off to their engineers. One of the objectives of a brainstorm session is to shoot for quantity and so it’s the nature of these sessions to produce more ideas than you need. For that reason, we need a process for narrowing the number of ideas or run the risk of feature bloat (producing a product with too many features). All experienced product managers know the problems associated with feature bloat:

  • Unrealistic product schedules that stress team members
  • A focus on quantity over quality of experience
  • A user experience made cumbersome and complex by too many options
  • The burden of providing support for every new feature
  • Wasting resources, time and money

In an effort to provide an elegant solution for your users and customers, you need to decide which features really provide value to them. And for first version launches, it’s best to plan for a minimal viable product. That is, the balance point where a product fulfills the necessary user goals with the least amount of features.

This is where you begin to ask questions like “Is it important we provide offline support out of the gate?” or “Is a chat widget something our users can live without?”. An MVP is a good, lean strategy that allows a startup or company to safely maintain costs while they confirm interest in their product.

In addition to thinking about an MVP, a checklist helps to narrow the feature list and cut some of the fat. Every feature idea should be examined by asking:

  • Does the feature solve a problem?
  • Is the feature feasible? In other words, can it be technically done now (not 5 years from now)?
  • Would the feature create more value for the customer or is it driven by selfish interests (e.g., using technology as an end rather than a means)?
  • Can it be done within certain amount of time?
  • Are there the resources?
  • What’s the risk of not completing it in time?

After putting your ideas through this rigor, it’s good to ask which ideas we should pursue immediately and which can can be deferred for later.

Often times, brainstorm sessions result in some brilliant ideas ahead of their time. Don’t throw these out! Save them for when the timing is right. For example, it took over 10 years for Wi-Fi to catch on with the public. In 2000, some of us had only one device connected to our home Wi-Fi. Now we have multiple devices that include everything from printers to cameras. Wi-Fi is now considered a standard feature with most electronic devices. Was 2000 a good time to introduce a Wi-Fi printer? Probably not, not enough people had Wi-Fi set up in their home yet. The point is providing a printer with Wi-Fi was a good idea, just not back in 2000.

Now that we’ve narrowed our feature scope based on business goals, knowledge and perceived customer value, we have a starting point for beginning to build a prototype. With the prototype we will layout the features to see if they make sense within the user flow and then, test the prototype to see if the features make sense to our users and customers. From there it’s an iterative cycle of design-test-refine until we have some certainty that the features we’ve chosen are the right ones.

The Magic

“Where does the magic come in?” you might be asking. The magic comes in deciding which features have the potential to be innovative. Innovation is the introduction of an invention to the broader public that improves the current state or condition of something. Just because you’ve launched a feature that nobody has doesn’t mean it’s innovative—it must be adopted by the public first! That’s why focusing on the right features is so important. Miss an upcoming trend or market insight and you could be toast. The visionary is the one who can take in all the information and predict the next thing—not because everyone says so, but because they see it coming from a mile away. That takes talent, not a learned process.

May you have both process and talent!



 

1 Comment


  1. 1 Vishal

    Absolutely great!! Thanks for sharing. What you have said about feature scoping is so true. This is a challenge that not only Product Manager face, but lot of Project/Program managers face on daily basis. The insights in the article helps those PMs, see the bigger picture on what effect their decision will have on the over all product and its vision.

 
Leave a comment

Leave a Comment Here

Email address required (others will not be able to see it)