Tag Archives: customer feedback

How To Get Quality Customer Insights (Spoiler: It’s Not About Time)

A Sales Exec and I were debating whether amount of time spent with a customer is a measure of the quality of the customer interaction.

His argument:

Just curious — do you see 23 touches for 5 mins the same as 23 touches for 1 hour each — I think it is different and material.

From my perspective, I need to allocated a certain number of hours per week with customers, and believe that number in a normal week is likely 5 hours. I am not sure if that is right, but 5 hours out of 40 per se seems about right. To me, a 3-hour dinner with a customer will be very revealing.

Time matters… Speaks to quality, don’t you think?

His assumption here is that there’s no meaningful insight to be gained in a 5-minute conversation. He’s also arbitrarily picked 5 hours per week. (Why not 4? Or 2? Or 8?)

My response:

Here’s how we should think about it.

Why are we seeking VOC? What’s the purpose?

At the most fundamental level, in any situation, there are three kinds of customer insights we’re trying to gain:

  • Problem Discovery
  • Problem Hypothesis Testing
  • Solution Hypothesis Testing

There are many techniques to accomplishing these. The specific ones we use depends on the situation.

For problem discovery, a series of 1-on-1 interviews is best. These take time. 45-60 minutes an interview across 10, 20, 50 customers, for example.

For hypothesis testing a broad problem domain, again, 1:1 interviews may be best to start with.

So in this case, I’ll opt for 23 phone conversations of 30-60 mins each, because I know neither email nor a survey nor a 5-min phone conversation will provide me the richness of insight I need.

For solution hypothesis testing, it can vary.

If I’m validating a mockup of a potential solution the customer has never seen before, a 20-60 min interview may be needed.

In all the above situations, I want the richness of the fluidity of the conversation, have an opportunity to ask follow-up questions, and feel the customer’s emotional responses.

But let’s say I’m trying to validate the need or usefulness of a specific feature — i.e., will it or does it solve a specific, previously identified customer problem.

In this case, using an email or an automated tool would enable 23 touches in 5 minutes, and work perfectly. I could do it via phone calls, which would have taken longer, but ultimately would have given me the same quality of insight.

Another example is having weekly meetings with the Sales team.

The meeting doesn’t preclude the opportunity for a Product Manager to get on sales calls and demos. However, there’s great efficiency and value to these meetings, because in 30 mins I get buyer feedback across all our products from 9-10 folks who are making a large number of customer calls every day.

Which technique to use in any given situation depends on the type of VOC one is seeking, the purpose of seeking it, ability to access the customer quickly, the time available to seek and act on it, and of course reasonable judgment.

With respect to allocating time for yourself to obtain VOC, that’s a different thing.

You’re a busy person, so it’s perfectly reasonable you need to figure out how much time to allocate for VOC vs. other tasks.

But that’s solving your problem — your problem of time allocation.

It’s different than the how, what and why of obtaining the VOC itself.

And provides no guarantee of the quality of customer insight that you may gain.

Guidelines For Conducting A Customer Conversation Session

By Prashanth Padmanabhan

There are some basic principles that you can follow while telling your story to your customer.

1. Show up at the customer’s office, if you can.

It shows respect. It tells them that you care for their thought. It is money well spent. As a product manager or product designer you are the voice of the customer and that is your only advantage over every other function. So customer visits should be your number one priority. Nothing else is more important than that.

2. Always show a prototype or draw a picture on the white board.

Don’t show a set of slides. This forces participants to think differently, look at the prototype and imagine rather than go into a passive finger-pointing mode. The prototype must include a list of concepts that you want to confront them with for feedback. Organize those concepts in the form of a story you can tell by going through the different screens in the prototype. Pause for a few seconds after each concept is outlined and let the interviewees share their thoughts. Acknowledge any interesting thoughts that come up and move on to the next concept in the story.

3. After introductions, ask them what they plan to get out of the session, and write that down on a flip chart.

If the crowd is large, ask everyone they plan to participate or if they are merely there to observe. Differentiate between the participants and observers and direct the conversation to the participants.

4. Listen more. Speak less.

You should be talking for about ten percent of the time and listening for the reminder of the time. If you have a hard time keeping quiet, take on the role of the writer on the flip chart. This will help you talk less and listen more. It will force you to keep quiet and will nudge customers to think aloud and direct you writing.

5. Write or draw on a flip chart.

Don’t sit down in a chair and write in a notebook where no one can see what you are writing. Writing on a flip chart, conveys to customers that you are listening, synthesizing and are open for comments. They can see your thought process, point out gaps in your thinking and, if necessary, correct what you write. So take notes publicly. Not privately.

Tip: Avoid total silence when in a conference! If you are running a workshop via conference, while taking notes, please avoid silence. Tell the customer you’re taking notes so they know you are listening.

6. Display all the flips charts all the time.

Do not flip the chart over and go to a new page. Tear the paper you wrote on and tape it to a wall. Don’t worry. Customers do not mind you posting 4-5 flip charts on the walls of their conference rooms. Pausing to tape the flip chart paper on the wall will give you a logical break after about 15-20 minutes of conversation. If your colleagues are present, it will give them an opportunity to chime in. It will also give you a minute to collect your thoughts.

After your paste the flip chart on the wall, underline the key words in the notes, recap the conversation, point out who said what, and ask participants if you missed anything. It gives participants an opportunity to point of simple errors that are bothering them.

7. Document while at the session.

Not after you come back to the office. Use a (phone) camera to take a picture of all the flip board charts. That is you documentation. You don’t have to write elaborate notes after you come back from the session. Post the pictures to a collaboration site, such as Streamwork, SuccessFactors JAM, Yammer or SharePoint, along with the notes and share it with customers.

8. Capture customer quotes and share them with colleagues rather than writing elaborate reports. Your colleagues will appreciate the quotes from customers and users.

Prashanth Padmanabhan is an entrepreneur, product designer, collaboration enthusiast, product manager for people and work management software, and SAP mentor. He’s co-authored two books, SAP Enterprise Learning and Look & Flow, a book on product innovation using design thinking and storytelling. His blog is Journal on Product Design and Development.
This post was originally published on Look and Flow, the blog site for his book. It is reprinted here with permission.

The Case Against The Business Case – Part II

Note: This is part of 1 of a two-part series. Read part 1 here.

In part 1, I talked about the problems of pursuing a new product idea in an organization, which traditionally starts with preparing and selling a business case. I shared research that I conducted in which I spoke with a number of product management professionals across the country in companies large and small who resoundingly shared their distaste for the process.

The response was amazing. It seems my post touched a chord!

Some interesting stats:

  • Within one week, the post became the 3rd most viewed on my blog.
  • Tweets, likes and positive comments on my blog and LinkedIn groups where I shared my post totaled 31. In other words, 31 additional people were in agreement with the original 24 with whom I had spoken.
  • On the flip side, there were a 6 disagreeing comments posted on the same LinkedIn groups.

Now, if there were any other detractors (because many more viewed the article), they either didn’t agree, didn’t comment, or didn’t care.

Still, with 83% promoters and 17% detractors, this would give an NPS-style score of 66%.

So it seems I’m on to something here.

Here’s something interesting. According to the Pragmatic Marketing’s 2013 Annual Product Management and Marketing Survey, 50% of respondents indicated they spend at least half a day per week preparing business cases.

part-of-job

Do the math on this, and that’s 17.6 hours per month or the equivalent of 1 month and 3 days per year spent preparing business cases.

So on average, a product manager is spending over one month of an entire year preparing business cases. Surely there should be some ROI to spending that much time? Yet, we all know the rate of failed products is sadly high.

To be clear, I’m not saying a business case is not necessary. Indeed, one needs to have a robust business case to ask for a commitment of resources and/or investment.

I’m saying that while well-intentioned, somewhere along the way, the process by which we’ve gone about preparing the business case has become wasteful.

[optin-monster-shortcode id=”tjtsmjhkd0zsxede”]

 

Several months ago, Steve Blank wrote a column in the Wall Street Journal that talked about the need for a startup to begin not with a business plan, but with building and testing a business model.

Three years prior to that, he blogged about how Customer Development is more effective than the traditional product development process in helping startups raise VC money.

“In a traditional product development model, entrepreneurs come up with an idea or concept, write a business plan and try to get funding to bring that idea to fruition. The goal of their startup in this stage becomes “getting funded.” Entrepreneurs put together their funding presentation by extracting the key ideas from their business plan, putting them on PowerPoint/Keynote and pitching the company – until they get funded or exhausted.”

It seems to me the same logic can be applied to pursuing new product ideas in established organizations.

Just like entrepreneurs typically jump right into writing the business case and seeking funding, product managers (or any visionary employee) often go direct from coming up with a concept to writing the business case and seeking its approval.

traditional-biz-case

Here’s another quote from that WSJ article:

“Entrepreneurs treat a business plan, once written, as the culmination of everything they know and believe. All they need to do is add money and magically that five-year forecast in Appendix A will simply happen if they execute to the plan.”

I’ve found the same with business cases. There are two key problems with the traditional approach to preparing a business case.

One is, like with startups, pursuing a new product idea in an organization is also fraught with uncertainty. The assumptions that go into the financial forecast need to be tested.

The other is that when seeking approval, your goal and your execs’ goal may not necessarily be aligned.

You still have a lot to learn and prove in your model. But the execs are ultimately interested in only one thing: ROI. Perfectly understandable, given the financial responsibility entrusted upon them.

problem-with-biz-case

This often leads to wasteful execution. The focus becomes hitting an arbitrary delivery date and trying to hit a promised ROI.

The product manager is caught between a rock and hard place: learning from customers and launching on time. It often leads to delivering bloatware or crapware.

What was that stat again about the rate of failed products?

So it seems to me that to build a robust business case, it’s important to validate that you’ve truly understood your customers’ problems, that they’ve bought into your proposed solution, that the problem is worth solving, and that it fits with the company’s overall corporate strategy.

For extra credit, you need to identify some early adopters, or “earlyvangelists,” as Steve Blank calls them.

These insights can help you identify key metrics that will drive your financials, making for a much more solid business case, and increase the chances for more efficient execution.

To add to this, product managers face a unique challenge that entrepreneurs don’t, which is gaining and maintaining internal stakeholder support.

This can be especially true in larger organizations where there are simply more people to manage and placate. Lots of opinions. Capturing and addressing concerns. Following up. Competing agendas. Finding an executive champion. Lots of approvals.

These are real challenges with which the bold product manager has to deal.

How to address that? Perhaps there’s a way to apply Customer Development concepts to internal stakeholders…?

In fact, there is.