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!

For corporations, their mantra was different. It was “we already know our customers” (this is good, unless you really don’t know what you think you know!). Ideas were drawn on whiteboards, product teams put together and we were promised a beta before the next board meeting. Four months later, it was doing it all over again—this time with more gusto and shinier graphics.

In both cases, product teams looked good but customers were not impressed. Why? Because there was little or no empathy for the customer. Plans were constructed based on assumptions and gut instincts, and “testing” only meant QA and a beta release. Recently, a new paradigm shift has taken place that challenges our old ways of doing things and brings laser focus to customer needs. This customer-centered approach is accompanied by a no-waste policy and ferocious rapid product iteration.

“Business as usual” is slowing changing with the help of three methodologies: Design Thinking, Customer Development and Lean Startup. They are practices that provide a road map to building successful companies and products on purpose rather than by chance. These three methods have so much in common with each other that after learning about them for the first time, you can’t stop to wonder — “Aren’t they all talking about the same thing?”

Rather than giving a comprehensive review of each discipline, I thought it would be helpful to discuss their similarities, emphasizing this new chorus of ideas coming from academicians, designers, corporations and entrepreneurs.

Design thinking has received the most media coverage in the last year with several books out by well known design industry veterans like Tim Brown of IDEO and b-school revolutionaries like Roger Martin. Customer Development and Lean Startup are the new kids on the block, but are gaining attention quickly as tech startups in particular, strive to be more agile, faster to market and more innovative in a world that is increasingly competitive and hungry for all things tech.

While Design Thinking probably isn’t what entrepreneurs think of first when formulating their company’s plans, many larger companies such as GE and Procter & Gamble, and business schools like UC Berkeley and University of Toronto have adopted it and made it a part of their curriculum. Even non-profits are using Design Thinking in an effort to help local businesses pick up distressed cities hit hard by the recession.

Customer Development is a close cousin to Design Thinking. Customer Development is a business model for early stage companies first introduced by retired serial entrepreneur and UC Berkeley professor, Steve Blank. Customer Development is promoted as a risk reduction methodology for early stage startups. However, Customer Development isn’t only for entrepreneurs. Its four step approach of Customer Discovery, Customer Validation, Customer Creation and Customer Development can just as easily be applied to any product initiative.

Lean Startup is as the name suggests, about eliminating waste. Waste may be defined as “any human activity which absorbs resources but creates no value.” Lean Startup takes Customer Development and Agile development and combines the two to produce low-burning, fast-releasing, iterative product development. The term was first coined by Eric Ries (a student of Steve Blank) and was born out of three trends:

• The use of open source and free software services
• Agile development methodologies
• Rapid customer-focused iterations

Lean Startup can be used by startups as well as product development teams looking for an efficient, low-burn, customer-goal oriented methodology.

The three methodologies can be summarized as follows:

• Design Thinking – Innovate via customer empathy and rapid prototyping
• Customer Development – Test your assumptions
• Lean Startup – Stay quick and agile with low burn

While they might seem to be saying completely different things, the means to arriving at their messages is more or less the same. In fact, all three teach the following:

• Learning and Discovery
  If all three practices have anything in common it’s that they are organized around continuous learning and refinement. Many startups might balk at the idea that their first priority be to learn. After all, who has time to learn when there’s a product to be built! They tend to approach it backwards by building the product or service first, and then learning. Unfortunately, by then they’ve probably burned through all their cash and it’s too late to take advantage of any lessons learned. All three methodologies put emphasis on defining what the issues are and for who, and doing research up-front before any product launch. The idea is to guide product design on the deeply understood needs, behaviors and attitudes of the customer, not on technology, business needs or on gut instinct. Bottom line: before any building begins, it needs to be proven that a product would solve a problem for an identifiable group of users.
• Direct Observation
  Steve Blank calls this “getting out of the building”. You have to talk to and observe real people if you want to get real feedback on your business or product assumptions. While surveys and focus groups are helpful, there’s nothing that matches the benefits of being face-to-face with a complete stranger that matches your target audience. Surveys are helpful, but you’re missing all the hundreds of nuances and ways human beings communicate frustration or delight through body language and verbal cues.
• Failing Fast
  All three practices emphasize failing early and quickly. All three suggest an ideation period where you develop hypotheses and test them rigorously. This enables you to not only fail cheaply, but also to expand and refine ideas via multiple iterations and feedback from your end-users. The idea is to eliminate all the larger issues early while it’s still cheap to do so. Failing isn’t bad as long it’s done quickly and early in the process. In fact, not failing enough in the beginning could be a sign you’re not testing your assumptions well enough.
• Test Your Assumptions
  Always test your assumptions. Why? Because the sooner you realize a hypothesis is wrong, the faster you can pivot. Eric Ries explains “by testing, each failed hypothesis leads to a new pivot, where we change just one element of the business plan (customer segment, feature set, positioning) but don’t abandon everything we’ve learned.” Many entrepreneurs and business leaders don’t like to test their hypotheses out of fear of being wrong, especially after having already committed several weeks of time and money. All three camps ask, “Why build a company or product on myths when it can be built on facts and knowledge? And anyway, what’s the point of building a product that nobody wants?” The lesson: test your assumptions every inch of the way and increase your chances for success exponentially. Any company that doesn’t test their assumptions on a continuous basis is simply rolling the dice. While you’re doing it, also test for customer validation, usability and feasibility.
• Iterative Development
  Lastly, all three methods are in agreement when it comes to iterative development. Iterative development allows you to to improve a concept or product in short correcting cycles. Iterations are done quickly with the idea that a concept gains refinement over several re-designs. An example of an iterative cycle is: ideation-design-test-refine (repeat).

While there are many similarities to all three methods, there are also unique elements to both Customer Development and Lean Startup. In general, Customer Development focuses on providing constant feedback, while Lean Startup takes the feedback and goes a step further by applying it to the actual workings of a startup and their survival (e.g., technology choices and software development practices). With Design Thinking, the emphasis is mostly on innovation, not survival.  Nevertheless, Design Thinking also works well on limited budget and resources and is excellent for solving “wicked problems” (survival being one of them).

Below are some takeaways unique to Customer Development and Lean Startup:

• Product and Customer Development Teams
  Customer Development suggests that startups have two teams: one for customer development and the other for product development. In reality, they both feed each other to influence decisions, but with Customer Development what product people would normally call the “discovery phase” is done by the customer development team on a continuous basis. This frees-up the product team to focus on the user experience and build while the customer development team provides constant end-user feedback.
• MVP (Minimal Viable Product)
  Both Customer Development and Lean Startup methods stress the importance of building a “minimal viable product” or one that fulfills the greatest number of customer needs with the least amount of features. If you’re a software engineer, this is music to your ears. The trick is finding the right balance. Too many features and you run the risk of burning through cash and burning out your product team. Too few features and you run the risk of not finding, disappointing or losing customers.
• Taking Advantage of Free Stuff and Agile Management Practices
  In the past, companies relied on waterfall development practices and licensed software to build their products and services. To counter these time and money burning methods, Lean Startup advocates the use of Agile product development where product builds are done in “sprints” within days or even hours. It also encourages the use of open source technology.

Resources:
The Four Steps to the Epiphany – Successful Strategies for Products that Win by Steve Blank

The Entrepreneur’s Guide to Customer Development by Brant Cooper & Patrick Vlaskovits

The Lean Startup – Low Burn by Design not Crisis by Steve Blank and Eric Ries

The Lean Startup Wiki

Achieving Flow in a Lean Startup by Ash Maurya

What is Lean about the Lean Startup by Eric Ries

The Promise of the Lean Startup by Eric Ries

Lean Thinking by James P. Womack and Daniel T. Jones

Fast Company: Design Thinking… What is That? by Mark Dziersk

Design Observer: What is Design Thinking Anyway? Roger Martin

Harvard Business Publishing: Why Design Thinking Won’t Save You by Peter Merholz

New York Times: Welcoming the New, Improving the Old by Sara Beckman

BusinessWeek: How to Nurture Future Leaders by Venessa Wong

Business Week: How Business is Adopting Design Thinking by Venessa Wong

Business Week: Design Thinking Can Be Learned Interview with IDEO cofounder, David Kelley

Wall Street Journal: Inspired Design is Essential—and All Too Rare by Gary Hamel

Related Posts:
Design Thinking 101

Tips for Startups

Cagan argues that startups work terribly inefficiently in spite of limited funding and time. Not only does this inefficiency cost money and time, it may also cause many startups to never reach it to market!!! According to Cagan, this is why many startups fail. They ”simply don’t have the funding to go to two years before they gain traction in the marketplace. So they hire engineers, take their best shot, and see what happens. Ready, fire, aim.”

Here’s the complete scenario as he describes it:

Someone with an idea get some seed funding, and the first thing he does is hire some engineers to start building something. The founder will have definite ideas on what she wants, and she’ll typically act as product manager and often product designer, and the engineering team will then go from there. The companies are typically operating in “stealth mode” so there’s little customer interaction. It takes much longer than originally thought for the engineering team to build something, because the requirements and the design are being figured out on-the-fly.

After six months or so, engineers have things in sort of an alpha or beta state, and that’s when they first show the product around. This first viewing rarely goes well, and the team starts scrambling. The run rate is high because there’s now an engineering team building this thing as fast as they can, so the money is running out and the product isn’t yet there. Maybe the company gets additional funding and a chance to get the product right, but often it doesn’t. Many startups try to get more time by outsourcing engineering to a low-cost offshore firm, but they’re still left with the same process and the same problems.

So as Cagan states, engineers are typically brought into a project at an early stage and they’re running around like chickens with their heads cut off trying to code and test new ideas at the same time. Sometimes weeks of coding are thrown out the window as the company “feels” itself through the unfolding product. For small startups it’s like pouring a house’s foundation and at the same time, deciding where the walls go.

But Marty Cagan isn’t some cranky product manager trying to wreak havoc on the startup community. He continues to describe what a more efficient process might look like:

Here’s a very different approach to new product creation, one that costs dramatically less and is much more likely to yield the results you want: the founder hires a product manager, an interaction designer, and a prototyper. Sometimes the designer can also serve as prototyper, and sometimes the founder can serve as a product manager, but one way or another, you have these three functions lined up—product management, interaction design, and prototyping—and the team starts a process of very rapid product discovery.

Cagan emphasizes that the focus is on product discovery via a high-fidelity prototype that mimics the desired user experience. But this isn’t enough—you must validate the product design with real users that fit your target audience. Without testing real users, you’re still in the dark when it comes to understanding how your users may respond to your product or service.

What then continues is a refinement process that includes several versions of the prototype in order to get closer to a winning product. The end result is that you have:

(a) identified a product that you have validated with the target market, (b) a very rich prototype that serves as a living spec for the engineering team to build from, and (c) a much greater understanding of what you’re getting into, and what you’ll need to do to succeed.

The engineers are then brought on and they’re able to build something based on a clear vision of the product and a stable spec. Not only does this make the engineers’ job much easier, but the company has reduced the risk of shipping a flop and has also saved a lot of time and money on development. The startup is building a successful product “on purpose”.

Cagan finishes his argument by asking:

So why don’t all startup teams do this? Because we’re such an engineering-driven industry that we just naturally start there. But any startup has to realize everything starts with the right product, so the first order of business is to figure out what that is before burning through $500K or more in seed funding.

…Definitely something to think about for your next startup.