If you manage a product or service in the business-to-business (B2B) market, customer requests for features will be a regular part of your work. Requests come in through the sales team, service reps, and senior management, as well as directly from customers themselves. It’s a disruptive insertion of new items for your agenda. That disruption isn’t necessarily bad, but it does distract you from other planning and execution you’re working on.

Reflecting on my own experiences here, I realized that each request needs to go through a series of decisions. These decisions make sure you know why you would agree to or decline the request, and are aware of the bigger picture effects of your decision. They make up the customer request decision flow:

The flow is a series of decisions, in priority order. My perspective is product management, but they apply to other areas as well (service, contracting processes, etc.).

Firm request from a priority customer?

This decision point is made up of two criteria: priority customer and firm request.

Priority customer

The first decision point may be somewhat offputting, especially if you operate in the small business or consumer markets. It matters who makes the request. In the enterprise market, just a few customers will be a significant share of your revenue. These customers’ revenue help you meet the payroll. They help keep the lights on. If you’re public, they help keep the stock price up.

In addition to high revenue, some customers are also valuable for non-monetary reasons. Lighthouse customers are important for establishing credibility with other companies.

Whether based on revenue or marketing value, some companies will be priority customers. They are a reality in every B2B company. Keeping them happy is part of the job.

Firm request

Sometimes a request is urgent, and vitally important to the customer. Other times, it’s merely a suggestion, a minor nit or a fleeting idea. It’s important to understand the difference.

Firm requests often come freighted with emotional terms, or subtle threats. “We really need this to make sure our sponsors continue to support you.” When they’re firm, pay attention, immediately.

Not all requests are firm. The customer may couch the request with wiggle room. Or directly say “it’s not a big deal”. Often, they have bigger things they want to tackle (on the product, on processes, on strategy) and look at their request as a suggestion-in-passing. They will move on to the bigger items and not focus on the request.

The ability to recognize the difference gets better with experience.

Multiple similar requests?

If the request is not a firm one from a priority customer, the next decision point is: are multiple customers are asking for the same feature? What the request lacks in priority, it may make up in commonality. If customers are making multiple requests for a similar feature, you’ve got a pain point on your hands that needs to be addressed.

A key issue is this: how do you know multiple customers have the same request? A common way is to utilize software which allows customers to post ideas, suggestions and requests. There are idea management providers that are good for this. Or you can user customer feedback sites. These asynchronous, always-on, open-to-all sites are well-suited for capturing suggestions.

In addition, you may need to check other areas. Bad as it is, your email often contains customer suggestions. Or you have a service ticket database you can check. Relevant knowledge will be in people’s heads, those who directly work with customers.

Once you know where to look, the process of determining commonality has two steps:

Identify all similar requests that have been made by different customers

Find all signals of support from customers

If you’re using an ideas or feedback site, finding similar requests is easier. Search on terms that relate to the request. Also, look at the ‘Likes’ and comments the suggestions have. I look at the number of companies represented in these signals of interest.

After gathering this information, you will have a sense of how wide the support is for the suggestion. If it’s sufficient, consider adding the request to your roadmap.

Meaningfully enhances outcomes?

Assume that the request is not a firm one from a priority customer, or one that has yet to be shared by multiple customers. There’s one final decision point: will the suggested feature meaningfully enhance customers’ outcomes?

Outcomes has a specific meaning here. It is the definition of when a job task has been satisfied. It should reflect the customer’s expectations. Remember, they only agree to use (and pay for) your product because you’re making them successful.

To apply this criteria effectively, you need working knowledge of what customers want to get done, and where they’re falling short. If you can see that the request will improve outcomes for a significant number of customers, it should be addressed.

Committed to maintaining feature?

For each of the previous three decision points, if the answer is ‘yes’, there is one more decision to make. Are you committed to maintaining the feature? While this may seem like a simple enough question, there are a number of considerations to it. Below are six factors to consider before answering ‘yes’.

Economics: What are the costs to build and maintain the feature? The expected upside of the feature should cover these. Upside is a holistic concept, including money for the new feature, new sales contracts and renewals because of the feature and increased customer satisfaction that translates into informal marketing for your company.

Release velocity: Every new feature added to a product increases the complexity of future releases. In software, a given configuration can have ongoing downstream impacts. Yammer’s V:P Engineering Kris Gale sees the additional complexity as a tax on product velocity. Your ability to release quality products quickly is impacted with each new feature. It’s worth it to add features, but think carefully about velocity impact.

User experience: The ability to use the product or service effectively is a core requirement for customers. If they find that it too complex, they will not fulfill their jobs-to-be-done. Joshua Porter nice summarizes the issue of feature creep: “No single feature addition is a big deal, but taken together change everything.” The value of the request must be greater than any negative effects on user experience.

Tip of the iceberg: sometimes, a request is a “jump” from the current product or service. And it’s only part of a broader offering needed to really address the need. You can look at a request and see how additional features will be needed over time to make it deliver value. And that may take the product in a direction you don’t want to go. Understand the longer term plan related to the request.

Mass market: You’re building a product or service for the mass market. It needs to address a large swath of customers’ needs. In that light, look at the current request. Is it the umpteenth time that this customer, or one of a handful of customers have requested something? Too many ‘outside-the-market’ requests can undermine your broader strategy. You win the battle for the lighthouse customer, but lose the war with the broader market.

Outcome prioritization: Smart product management is organized according to customers’ jobs-to-be-done and expected outcomes. Some outcomes may be currently underserved. Customers’ expectations are being met, and that needs to be addressed. The new request will delay the implementation of features to address these outstanding pain points. Determine if the new request outweighs the currently underserved outcomes.

Decide on the request

Decline the request

If the request cannot cleanly get through the six criteria of the “Committed to maintaining feature?” decision point, it is reasonable to decline the request. Indeed, you now have specific reasons for doing so. That alone is a big improvement versus what often happens: the request sits in the equivalent of a “dead letter” file. Or if there is a response, there’s only a vague, “we can’t do that right now.”

Address the request

If the request makes sense, then it’s full steam ahead. However, notice I’ve used the term “address the request”. This is different than “implement the request”. Maintain a philosophy that:

Customers know their jobs-to-be-done better than you, but you will know potential solutions better than them.

Not to say the customer hasn’t provided a specific feature solution that is right. But avoid just passing through exactly what what was requested without giving thought to different ways the job-to-be-done can be addressed.

Customer requests will be a constant in the B2B product manager’s life. Knowing how you’re going to handle them is key to the success of the product and the business.

I’ve previously written about collecting jobs-to-be-done from customers. Because I was analyzing a broad topic across the entire innovation lifecycle, it was a good way to get a breadth of insight. However, it doesn’t work as well in the more common situation for product managers and innovators: analyzing a specific flow. In that case, there are three requirements for collecting jobs-to-be-done:

Comprehensive capture of job elements

Map collection as closely as possible to the actual job flow

Understand importance and satisfaction of individual tasks

Comprehensive is important, because you can’t address what you don’t know. A limitation of my previous effort was that it was not comprehensive. Actual job flow is a powerful framework. Needs captured in context are more valuable, and it’s critical to follow the steps in the job. Importance and satisfaction become the basis for prioritizing effort.

To address these requirements, I’ve put together a process to understand customers’ jobs-to-be-done. The major elements are:

For purposes of this write-up, assume you’re an automotive product manager. You’re tasked with understanding people’s needs to get work done on the commute to the office. Note this is a job that becomes more readily enabled by self-driving cars.

Start with the job flow

A job-to-be-done has a flow. For example, take this job:

When I commute to the office, I want to get work done.

A job flow consists of the job’s major activities, in sequence. The job flow looks something like this:

The purpose of the flow is to provide a framework for capturing specific tasks. Putting this together is primarily the responsibility of the product manager (or innovation team). By stating the major activities that define the job, expect a much more comprehensive capture of all the job elements.

Job task

Each activity consists of a series of tasks. Task are what the customer actually does. They are independent of specific features, although may often be intertwined. Here’s an example task:

Previously, I’d focused on including context in job statements. But when these tasks are organized according to the job flow, the context is readily known. So task statements don’t include a context element.

But they do include an expectation statement. For every task we do, we have an expectation for it. It defines whether we consider the current experience wonderful or painful. This expectation is formalized for each task, captured in the customer’s own words. It’s valuable to know what the customer expects, as that becomes the basis of design.

Collect jobs tasks for each activity

Next step is to conduct the actual customer interviews. Whether done in the customer’s environment (best) or via a web conference call (acceptable), the job flow provides a familiar framework to the customer.

When I worked at eFinance, I conducted brown paper sessions with clients to understand their commercial credit processes. A staple of the Capgemini consulting model, the brown paper is a step-by-step process flow of what the customer does today. Collecting the job tasks is similar here. Similarities and differences:

Brown papers are conducted with groups of people together. Job-to-be-done capture will more often be solo interviews.

Brown papers are done in a strict step-by-step flow, captured visually on a wall. If doing this for job-to-be-done interviews works for you, go for it. But a simpler post-it note capture style works as well.

After capturing the steps in a brown paper, the group is invited to post stickies describing points where improvement is needed. In the job-to-be-done interviews, each task includes a statement of what the customer expects for it.

A key element of the interview process is to probe the responses of the customer. In a perfect world, they will lay out the individual tasks and easily express their expectations. But likely, customers will talk a lot about features. Which is valuable in its own right. But the objective here is to capture what they are trying to get done. So apply the simple question why. Not in a robotic way. But make sure to probe past the expression of features. These are the tasks – versus features – to place on the job canvas.

Here’s an example of the approach:

Customer: I want a 4G internet card.Interviewer: Why do you need that?Customer: So I can connect to email and the web.Interviewer: What is your expectation for connecting to email and the web?Customer: Always-on internet.

One tip: Use different color sticky notes for each major activity’s group of tasks. This color coding will help later in identifying where the tasks occur in the job flow.

Job canvas

For each major activity, job tasks are collected onto that customer’s job canvas. An example (with fewer tasks than would actually be there):

In reality, there will be a large number of tasks per customer interviewed. Strategyn’s Tony Ulwick states there will be between 50-150 outcomes collected from multiple customer interviews. Gerry Katz of Applied Marketing Science sees 100 or more needs collected as well. Sheila Mello of Product Development Consulting says it’s not unusual to extra several hundred images from the customer interviews.

Top tasks by importance and dissatisfaction

Once the job tasks have been captured, the customer selects the tasks:

That are most important

That are least satisfied

The customer will select the 3-5 tasks that are most important for each major activity in the flow (e.g. there are 3 major activities shown in the job canvas above). These tasks will be assigned points. For example, assume three tasks are identified as important. The most important task would receive 3 points, the next most important 2 points, and so on.

The customer will also select the 3-5 tasks that are least satisfied for each major activity in the flow. Assuming three selected tasks, the task that is least satisfied receives 3 points, the next least satisfied task receives 2 points, and so on.

Keep this insight handy, but separate from the collected stickies (or however you’ve collected the job tasks). We’ll come back to how to use this information.

Note: it will help to apply unique numbers to the individual job tasks. You’re going to want to know the most important and least satisfied tasks across multiple customers later in the process.

Number of customer interviews

A general rule of thumb is that 15-20 customer interviews will provides solid coverage of customers’ needs. You can take it further, as George Castellion advocates 40 interviews. Each interview starts with a blank canvas containing only major activities.

Create affinity groups

After conducting multiple interviews, you will have a large number of job tasks, with information on which ones are most important and least satisfied. Working with a large number of statements by people is a challenge that others have faced. They key is to reduce the large number to a manageable set of insights. There’s a proven approach called the KJ-Method to systematically abstract hundreds of statements into a few key groups.

UX expert Jared Spool provides a detailed series of steps to run the K-J Method. I’ll use his description here.

Bring together group of people do the affinity grouping

The first step is to determine who will do the affinity grouping with you. Try to keep this group at 5 people or fewer. Draw on people from different disciplines.

Put all the job tasks on a wall

In a single space, all the job tasks should be visible and accessible. They need not be laid out in the job flow, which might introduce a bias to the grouping. The color of the stickies will be the basis for knowing where the tasks fall in the flow.

Group similar items

The next step is for the team members to group like job tasks together. The process is one of looking at pairs of tasks, and determining if they share characteristics. This how Jared instructs clients to do this:

“Take two items that seem like they belong together and place them in an empty portion of the wall, at least 2 feet away from any other sticky notes. Then keep moving other like items into that group.”

“Feel free to move items into groups other people create. If, when reviewing someone else’s group, it doesn’t quite make sense to you, please feel free to rearrange the items until the grouping makes sense.”

“You’re to complete this step without any discussion of the sticky notes or the groups. Every item has to be in a group, though there are likely to be a few groups with only one item.”

Label the groups

Each participant then gets to label each group. This entails looking at the grouped job tasks and determining the common theme. Again, here’s how Jared instructs teams on this process:

“I want you to now give each group a name. Read through each group and write down a name that best represents each group on the new set of sticky notes I just gave you.”

“A name is a noun cluster, such as ‘Printer Support Problems’. Please refrain from writing entire sentences.”

“As you read through each group, you may realize that the group really has two themes. Feel free to split those groups up, as appropriate.”

“You may also notice that two groups really share the same theme. In that case, you can feel free to combine the two groups into one.”

“Please give every group a name. A group can have more than one name. The only time you’re excused from giving a group a name is if someone has already used the exact words you had intended to use.”

Note that part of the exercise in this step is to give one more consideration to the groupings. If, upon trying to determine a label one finds that the groups doesn’t actually make sense, the groups can be split up as needed.

I’ll add this caveat to Jared’s instructions. For purposes of this affinity group work, lots of different labels for each group of tasks are not important. It’s OK to go with one person’s good label for a group, a point to emphasize more strongly.

Here’s an example of labeling a group of job tasks:

Once done, you’ve organized a solid group of job tasks into major themes for what customers are trying to do.

Calculate the importance and dissatisfaction score for each group

Remember asking the customers to rate the three most important and three least satisfied job tasks? Now it’s time to use those ratings. In each group, calculate the following for both importance and dissatisfaction:

Total points

Average points per task

For each group, you’ll have something like this:

The Total score gives a sense for where the customer energy is. Large scores on either metric will demand attention. The Average score is good for cases where a group has only a few, highly scored job tasks. It ensures they don’t get overlooked.

Prioritize roadmap

You now have major groups scored with customers’ view of importance and dissatisfaction. Within each group are the tasks and expectations that customers have. This is the good stuff, the insight that fuels design efforts. It’s also the data-driven, factually based input that helps clear the fog when tackling a new area for development.

The expressed customer insight – what they want to do, what is important, what is not satisfied – becomes the foundation for constructing a roadmap. The team can layer on other considerations: business strategy, adjacent initiatives that impact the effort, internal priorities. Balance these with what customers actually value. Anything that ignores this hard-won customer insight needs a compelling reason, and an understanding of the higher risk it entails.