How I do continuous product discovery

How I do continuous product discovery

BY Simon Knight ON MAY 3, 2022

One of the things that’s been very useful to me over the course of my product management career so far is talking to customers.

This statement seems so obvious that it should be self-evident. It should go without saying that speaking with customers is a fundamental product management activity that underpins all other aspects of the job. It follows that product managers therefore should absolutely treat this activity with the gravitas it deserves and prioritise it accordingly, so that it rises to the top of their no-doubt busy to-do lists.

In my experience though,  this activity is often not prioritised nor seen as the massively important activity I believe it to be. My observations have led me to conclude that this happens for several reasons:

1. The product manager is fearful of speaking directly to customers due to <reasons>.
2. The product manager does not understand the benefits of speaking to customers.
3. The product manager does not feel like they have enough time to spend on speaking to customers.
4. The product manager does not have a good process in place to support their speaking to customers on a regular basis.

I want to address the last point on this list.

The benefits of talking to customers have been written about extensively elsewhere, so I’m not going to focus too much on those, except for the sake of completeness. Speaking directly with customers on a consistent basis helps product managers to:

• Empathise with the customer and better understand the context within which they’re trying to use a product.
• Gain a better understanding of the customer or user’s goals, needs and pain points.
• Provides the product manager with regular “aha!” moments as information from customer discussions is synthesised over time.

A lot of the concepts I’m talking about here draw from and build upon the work of Teresa Torres and her excellent book, Continuous Discovery Habits, which inspired me to implement this process and follow up my learnings with this article.

Automation

Some of the main challenges with doing continuous discovery revolve around getting customers on to the phone calls in the first place. [Insert your preferred tooling here.]

Finding customers who are willing to sacrifice some portion of their day to talk to a product manager about a product is a big ask. As a product manager I know this, (since my day is similarly busy!) and I try to ensure that the time investment is as small and focused as it can be, and that the time is used as efficiently as possible. More on this later though.

The primary and initial obstacle to carrying out continuous discovery communications is getting the customer on a call in the first place. I’ve solved this problem by:

1. Getting a list of names and emails of customers/users who have indicated (in a survey response) that they are willing to have a conversation with me.
2. Automating the process of reaching out to those customers via email using a Google Sheet (with their names and emails on it) – and by installing a Google Sheet plugin called YAMM which works alongside Gmail to send emails to the customers, inviting them to a call.
3. I use another plugin called CloudHQ which works alongside Gmail and my Google Calendar, enabling respondents to select a convenient time and date on which to have the call.
4. I manage my own calendar such that I have some open slots which can be used by customers to have these calls, without causing me too much additional work or stress in the process.

With all that work done and largely automated (except for the occasional sending of bulk emails, and the ongoing maintenance of my calendar to ensure I don’t get meetings scheduled for inconvenient times) – I’m good to go with the calls themselves.

Doing the call(s)

Arguably this constitutes the hard part of the process; particularly if fear (reason 1 from my original list) is a factor to not really engage with customers in the first place. Some advance preparation for the calls can surely help to mitigate that though, and provide some additional benefits. Here’s what my preparation process looks like:
1. I create a shared document with a customer call template on it. The template should resemble something like the below:

• Names and details of the attendees
• Time and date of the meeting
• Any relevant background information
• Questions you want to ask the customer
• A space for notes from the call itself

2. Before the call, I make a copy of the document and fill out any necessary or desired background information. Often that involves taking a look at the customer account details to get a sense of their size and value to the business. I might also take a look at what it is they do and how, for some additional context and just as generally useful information to have in my pocket for the upcoming meeting.

3. During the call itself I more or less always follow the same structure for the discussion:

• Introductions
• Whatever the customer wants to talk or ask about (I’m using their time after all – and this will still be useful information to me)
• My questions for them
• Wrap up the call, including summarising and identifying any actions or next steps

Most of the time, the entire call can be done in around 20-25 mins, though my calendar slots are usually half an hour long. I started with hour-long slots a few years back, but frankly, that’s too much of an ask for everyone concerned. Half-hour slots work much better and strike the right balance between convenience and usefulness.

After the call, there’s a bit more work to do still. And sadly I haven’t found a way of automating this effort away – yet!

After the call

The purpose of all this work is to learn. I’d contend that just doing the calls and having those customer interactions in the first place is going to result in increased empathy and roadmap insights – but you need to make those things actionable.

You need to transform the insights from your calls into data, so you can be driven by it.

Here’s the best way I’ve found of doing that:

1. Probably during the call, the customer mentioned a bunch of things that can broadly be categorised as either requests for new features or improvements, or requests for fixes (bugs). Those things should be turned into tickets (e.g. in Jira) if they don’t already exist.
2. For each ticket, whether it’s a feature request or a bug, you should add a reference to the customer account (their ID or account number). This serves two functions, one of which is to gauge the amount of interest in or requests for the ticket, which can help with prioritisation later down the road. If the bug or the feature request already exists in your ticketing system, you can just use the customer ID or account number from your call.

Over the course of time, following this process will result in a backlog of opportunities that you can work on – now, later or never, depending on the amount of interest in them and your overall vision/strategy for the product. But for super-bonus points, you can further supplement this information with another data point that will give you product manager superpowers.

Revenue

With your tickets all logged and having added the customer ID to them, you’re now in a position to start generating some reports that tell you how much revenue is associated with them (though you may need some operational or data scientist support to stitch this info together for you). Revenue that is:

• At risk, in the case of bug tickets
• An opportunity, in the case of feature requests or improvement tickets

Here are  some examples of how I use that data to generate reports in my day-to-day work:

• Top 10 bugs by revenue – I use this alongside other members of my team and business to hold a weekly meeting to discuss the bugs and ensure necessary actions are being taken.
• Other customer issues by revenue – similar to above, but focusing on issues that can’t neatly be categorised as bugs.
• Releases by revenue – assuming that releases are made up of some number of tickets, which fall into the categories of improvements or fixes, a weekly report can be generated showing how much revenue is associated with those releases, acting as an indicator of how much revenue growth can be expected from feature release, or how much churn might be prevented in relation to some bug fixes.
• Components by revenue – while roadmapping I can use this report to help get a sense of which areas of the product (components) may warrant additional attention, based on the associated revenue. This assumes you have mapped your components onto the tickets in the first place though.

And so on. You can slice the data in lots of different ways. These are just some examples that have proven useful to me and my team.

Continuous discovery in a nutshell

I mentioned earlier that my efforts built on Teresa Torres’ excellent book, Continuous Discovery Habits. When I read her book however, despite being a big mind map user myself, I didn’t feel like the Opportunity Space mapping approach she recommends could be systemised or would scale sufficiently to provide my team with all the information we were seeking for our product and roadmap.

I think the alternative process I’ve outlined above demonstrates how continuous discovery can be implemented and automated in the first instance. It also shows how the resulting insights can be recorded and combined with existing business data to produce both a backlog and a reporting structure that helps to inform future product strategy.

While reading the above, if you have some ideas as to how to further improve this process, or if you fundamentally don’t agree or disapprove of it, I’d love to hear from you!

Discover more content on product discovery.