Which Customer Interaction, When?
When the conversation turns to interacting with customers before a product is "finished", most product developers I've talked to are enthusiastic. But they have very different opinions about when to interact with customers, how to interact with them, and for what purpose.
I believe there is a way of thinking that helps resolve these questions, with answers that vary depending on the details of the company, and the stage of product development they are at. This article is to share it. The article focuses on Products for Seniors, but this approach is just as relevant to other customer groups.
More Customer Interaction. But for What Purpose, and When?
If you have read the first part of this series (Products for Seniors: Could Do Better), you will know that I am excited about the numerous opportunities I see for clever products and services to address the unmet needs of older adults. But that I am disappointed about the actuality of what one can presently buy.
My thesis is that a big part of the answer to how to change this situation is increased interaction between product developers and older adults themselves.
Our Longevity Explorers are keen to find a way to help improve this aspect of developing products for older adults, so I spent the last few months talking with product developers to find out whether the explorers could help them and how.
What I learned was a bit surprising, although in retrospect maybe it should not have been. The vast majority of developers I talked to were enthusiastic about a deeper engagement with older adults during their product development activities. But, there were a lot of different views about what form they wanted those interactions to take, and why they wanted them. Quite often, the people I talked to liked the idea of more interaction with the older adults who they hoped would be the ultimate beneficiaries of their development work — but were very unclear how to make that happen, or even exactly why they thought it would help.
As I digested what I was learning, it became clear that the companies I was talking to needed different types of customer interaction, depending on where they were on the path from idea to finished product, and on what type of company they were.
And as I thought about this, I realized that the type of customer engagement that is likely to be most useful maps quite nicely onto a model I use in my advisor / angel investing life to help me think about what stage a company is at — based on the idea of Value Milestones.
I started to play this back to people, and found that laying it all out helped the discussion, so I decided to capture in this article the interaction between value milestones and customer interaction. Think of it as a sort of "How to guide" to help answer the question of "Which Customer Interaction, When?".
Value Milestone Framework
I like to think of the path from idea to successful product as passing through a series of what I call Value Milestones. These are milestones at which one can see a clear step change in the value of what one has created thus far — as a result of having accomplished certain key things.
In my "other life" as an occasional angel investor, I find this an especially useful way to decide where a company is in its growth, what the key questions are to ask, and what types of proof-points about "success" should exist.
There are a number of Value Milestones, and some are dependent on the specific industry, but the big ones relevant to product development, and the ones that are relevant to this article, are in the figure below.
There is quite a lot to say about this Value Milestone approach, and you can read more about it and related techniques in the references section.
For this article, there are a handful of things to bear in mind for now.
- The ideal way to develop a product is to move systematically from the bottom milestone to the top one. Quite frequently people jump straight to a "Solution" without stopping to be sure they understand the problem they are solving (the Unmet Need). Or even worse, they go straight to the prototype without checking they are thinking correctly about either the unmet need or the solution. This almost always leads to going back and doing things again.
- Once one has completed a Value Milestone, the next steps are working towards the next Value Milestone. In other words, after finding a promising unmet need, one next needs to validate a conceptual solution. Not go straight to the fun part of developing a prototype!
- Once you complete a Value Milestone, it is usually very important to have some proof-point you can share with others to show that the milestone has indeed been completed. So, for example, if you convince yourself you have identified an important unmet need and come up with a great solution, and validated that the solution is indeed very promising, you need some proof-point to share with investors or managers. This is a surprisingly subtle point, often overlooked. "Trust me, they loved it" is usually not a very compelling proof-point.
- For believers in modern approaches to product development and company development (lean startup, and agile development, for example) the potential users / customers of the product have a critical role to play for each Value Milestone. But it is a different role for each Value Milestone, as discussed in more detail below.
Learning Interactions vs Proof-point Interactions.
There are two conceptually different purposes for customer interaction. One is to learn something. The other is to collect a "proof point" one can share with others. In theory you can design an interaction that does both, but that is not always easy or economical, and I find it is helpful to think of these as conceptually distinct interactions.
A "Learning" Customer Interaction
The purpose of this type of interaction is to learn something.
The classic example here is when one has a working prototype of a conceptual solution to a thorny unmet need. A good reason to interact with customers is to try and learn whether the prototype actually "works" to address the Unmet Need. And maybe to learn how to improve it.
A "Proof-point" Customer Interaction
The purpose of this interaction is to collect some evidence that you can later use to get others comfortable with the fact that you have really attained a given Value Milestone.
To stick with the example that goes with a prototype Value Milestone, the key proof point you want is something that convinces people you really have a working prototype that meets the Unmet Need better than competing alternatives. Saying you have a prototype, or showing people a prototype, or even demonstrating a prototype does not really tell the audience anything about whether or not it meets the need. You need some type of proof-point that involves customers who do indeed think the prototype meets their specific need.
Note that "proof-points" come in varying degrees of perfection. Often one does not actually need to "prove" something. But you need some supporting proof-point to convince people like investors and managers that you are ready to move to the next stage of development.
For startups, this is especially important. Imagine presenting to the investor, and explaining that "it works really well". Put yourself in our shoes. Of course, you will think it works well. You are the entrepreneur! But how do we know we have the same idea of what "it works well" means?
There are some important differences between learning and proof-point interactions.
- Learning interactions are to help the development team make decisions. You don't always know in advance what you are going to learn. The design of the interaction needs to allow discovery of the unexpected. The evidence needs to convince the team, but may not need to serve as a proof-point for others.
- Proof-point interactions are to help convince others. They don't need to be as open to the unexpected as learning interactions, because they are typically designed to demonstrate a specific point rather than uncover new things. The evidence needs to help convince people beyond the team. This often takes a different type of evidence.
Customer Interaction Goals Depend on Stage of Development
It's probably obvious by now that we need different goals for customer interactions that take place prior to attaining each of the different Value Milestones.
Here is my summary of how to think about what we need and when. There are often additional goals in each area (depending on the company and target customers), but this is a good place to start. Feel free to add ideas in the comment section.
|Value Milestone||Learning Interaction Goal||Proof-point Interaction Goal|
|Important Unmet Need, Shared by Many||Discover unmet needs. Find out which are important. Discover what types of people are potential "customers". Learn how people meet the "need" today. Learn what competing solutions they use.||Collect shareable evidence of both the importance and likely size of the need.|
|Conceptual Solution that meets the need better than the competition||Learn things like: Will our conceptual solution likely meet the need? Which of several conceptual solutions is likely to be "best"? How could we make the solution even better? How does our solution compare with current alternatives?||Some type of shareable enthusiasm for our conceptual solution, from people who typify potential customers, and have tried competing alternatives. Enough to justify investing in a prototype.|
|Working Prototype||Answer questions like: Do "customers" think it will meet their need, if turned into a real product? What is good, what is bad about it? How could it be better?||Enough positive shareable evidence to justify the investment it will take to bring an actual product to market.|
|Product or Service||Find out how well it meets the need of real customers.||Evidence from potential and real customers that we can share with other stakeholders, (including customers) to show that the product works really well, and meets the need we identified, and does so better than the competing alternatives.|
|Customers Like & Buy It||Variety of goals relating to marketing and selling the product more effectively and or improving it in subsequent product iterations.||Testimonials to help market the product. Proof-points for validating the business model.|
In listing the goals above, I have focused on goals that relate to the solution-need alignment. The Lean Startup / Customer Development models emphasize in addition the importance of validating all aspects of a business model, and for new ventures I agree this is critical. There are additional goals relating to business model validation that one would add to this list if doing a new venture, or exploring a new business model in an existing business.
Customer Interaction Methods
There are whole books written on how to interact with customers to learn useful things, and there are a variety of techniques. The right technique really depends on the goal.
Learning interactions often benefit from deep-interactions like one on one interviews, deep group discussions, and observational ethnographic research. But other more quantitative techniques like surveys have a role too, especially when respondent numbers and demographic diversity matter more than depth.
Proof-point interactions can use similar approaches, but usually need different documentation, and different agendas. Techniques like video or audio interviews can be useful.
This article is not about which technique to use, as I feel that depends very much on the specific goal. In my experience, once one clarifies the goal, the best technique is usually fairly easy to determine, so I focused here on goals.
If you have any questions, feel free to engage with me via the comments section, or by email.
(1) The Value Milestone Framework is something I use a lot, and I have written and talked about it frequently, much of which is on the TangibleFuture website (see TangibleFuture's Entrepreneur Tools Section.)
(3) I especially like the series of books called "The Lean Series"
(4) If you have read this far down, I also want to recommend "What Customers Want", by Anthony Ulwick. It is a bit off the topic of this specific article, but a "must read" if you are interested in getting insights from customers into what products to develop.