This is the second post in my Customer Research series.
Many people have asked me how persona work leads to product definition. Here is my personal take.
In any new product development effort, we need to ask the following questions:
- What is the market segment I am shooting for, and is it big enough?
- Who am I making this product for?
- What are the problems that customers are trying to solve?
- How may our core competencies be applied to solve these problems?
- What are the product features that may deliver these solutions?
- What is the end user’s mainstream workflow, and what minimum feature set is necessary to service that workflow?
- How would the end user want these features to work for Version 1?
- What would the roadmap look like for future releases?
Item 1 is a market sizing and analysis exercise. It is based on quantitative data from analyst reports and from internal market analysis. It builds the business case for a new product, and helps establish a basis for interest that justifies further effort.
Items 2 and 3 are addressed by persona development. I like to interview prospective customers in the environment they will be using the product in about their thoughts on the problems that the future product may address. I listen between the lines and then derive the needs, wants and expectations of the prospective customers.
The key words are “prospective” and “expectations”. Expectations are set by experiences, which is why you will get a different result if you interview existing customers of a previous-generation product, as opposed to prospective customers that represent your target market.
Item 4 is a cross functional discussion involving the product manager, the engineering lead, and a proxy for an archetypical end user in the sweet spot, representing the primary persona we are trying to target. For instance, if the target user is a 65 year old, there should be an older person in the discussion to represent their point of view.
If the core competencies do not support a viable solution to the customers’ problems, the team would have to go back to Item 1 and rethink the target market and the business case. Developing new core competencies is an engineering research activity that precedes product development.
Item 5 is about envisioning features that will deliver the solutions needed by end users, and Item 6 places them in the context of user workflows. One is meaningless without the other.
At this point is generally a lively discussion with all the possible ways to serve up benefits to customers. Rather than going around in circles in the office, I reach out to customers to get their feedback. I employ a few techniques for this:
- Get customer feedback with paper prototypes. This can be done either as a round-table discussion (2-3 groups of 8-12 participants each) or remotely by phone on a one-on-one basis. This should be done with both prospective customers and existing customers so we can get the full range of perspectives for people in the sweet spot and for early adopters. Results should be interpreted separately, of course.
- Beta testing with hacked prototypes where feasible. This should run for 2-4 weeks with prospects AND existing customers with separated analysis of results for the two constituencies.
- A product concept test for the new product, executed as an on-line survey to prospective customers only.
- A comparative product concept test, pitting the proposed product against a control product, executed as an on-line survey to existing customers and prospective customers.
Once we get through 1-6, we will have a clear idea of what features ought to be included. The next step, Item 7, addresses how those features should work. I like focus groups for this detailed phase, but if budget doesn’t permit, we can cover this with informal round tables or virtual focus groups. I like qualitative techniques for this because it is difficult to get into enough detail with quantitative techniques.
When we wrap up Item 7, we have nailed all the requirements and are ready to develop a Functional Specification for Version 1 of the new product. This should represent a minimum set of features that service the mainstream workflows of end users in the primary persona. The product team can now execute on the new product.
The learnings from 1-7 will also feed Item 8 – roadmapping. We will have a ready list of features that deliver secondary benefits, and we can tentatively bracket those into future releases.
This process can sound like a drag. It is not. It is simply a practical way to frame the challenge of understanding customer problems. The whole thing can take anywhere from a few days to a few months, depending on how much the product team already knows about the market and the product, and the scope for the new product development effort. A little thinking goes a long way here – much better to invest time up front than start development without a clear understanding of what one’s doing and why.
