How Do You Know What Your Product or Service Needs to Be?

To answer this you need to consider both the customer and the business needs. As the best product from the customer’s perspective without a viable business model is all waste. And without customers it is hard to have a viable business model.

From the business perspective you need to figure out:

• If you can make money.
• If you can design it.
• If you can build it.
• If you can distribute it.

Though without a customer for the product it doesn’t matter how well you do any of that. Without diminishing the importance of the business needs, how can we understand what the product needs to be for the customer?

You could ask your customers what they value, but that has limitations as this quote attributed to Henry Ford^[i] points out:

“If I had asked people what they wanted, they would have said faster horses.”

So if you can’t just ask your customers, what can you do to understand what your product or service needs to be?

At Toyota, and other companies that have embraced it, the chief engineer immersion process is used to understand how current and potential customers will use the product. For example, Yuji Yokoya the 2004 Sienna chief engineer drove in every U.S. state, all provinces and territories in Canada, and throughout Mexico to understand the North American market, which led to many design changes^[ii]. In addition to experiencing the North American market, he also observed how vehicles were used including Americans loading 4’ x 8′ sheets of plywood into competitors’ vehicles^[iii]. This deep understanding of what the product needs to be for the customer is used throughout the development project and captured in the chief engineer concept paper. The concept paper outlines the chief engineer’s vision for the product and gives the marching orders for the development program.^[iv]  

Design Thinking, as practiced at IDEO^[v] and elsewhere, uses direct observation to understand what people want, need, like, and dislike about products^[vi]. When using design thinking project teams work in three spaces: inspiration, ideation, and implementation. Inspiration is the circumstances that motivate the search for a solution. Ideation is the process of developing and testing ideas. Implementation is the path to bring the project to market^[vii]. Projects will loop back and forth through these spaces as the team is learning what the product needs to be through observation. As the team learns they update the project brief, which provides the framework to design, objectives to be realized, and benchmarks to measure progress.^[viii]

Menlo Innovations uses High-Tech Anthropology where potential end users are studied and observed in their native environment including understanding differences between users^[ix]. What they learn is captured as user personas. The client then selects the primary persona to drive the product design. Primary, secondary, and tertiary users are captured on a persona map with the primary persona in the middle.  As the product is being developed the high-tech anthropologists use low fidelity mock-ups to get the product in the primary user’s hands to observe their interactions^[x]. These observations enable the product to be further improved to better meet the user needs.

And then there is Clayton Christensen’s “Jobs to Be Done” theory developed over two decades and triggered by the realization that knowing more about customers doesn’t translate into knowing what people need from products. More important than knowing about your customers is knowing what your customer or potential customer is trying to accomplish in a specific circumstance – their “job to be done.” ^[xi] Or said another way:

“What problem is your product or service solving for your customers?”

What is learned about the circumstances and job to be done is translated into a job spec with the functional, emotional, social aspects and any tradeoffs customers are willing to make to provide guidance for the innovation process.^[xii]

The project that started this thinking was how to sell more milkshakes for a fast-food chain. They originally took the traditional approach of asking customers what they wanted. Many experiments were run to give the customers what they said they wanted and there was no change in milkshake sales. At this point the question was reframed as: “I wonder what job arises in people’s lives that causes them to come to this restaurant to “hire” a milkshake?” Through observation and directed questioning around the circumstances of the purchase the team discovered that a lot of milkshakes were purchased in the morning to “help me stay awake and occupied while I make my morning commute more fun.” And that milkshakes sold in the afternoon had a very different purpose.  They figured out that unique solutions were needed to sell more milkshakes in each situation.

All of these approaches can be effective to understand what products and services need to be. Consistent across them is the role of observation in real environments and synthesizing that knowledge into something tangible to guide the product and process development process.

How do you understand what your product or service needs to be?

How do you translate what the product or service needs to be to provide guidance to your product and process development process?