The Sales Stakeholder Interview

This is an excerpt from from Kim Goodwin’s excellent Designing for the Digital Age. It is quite long, so we’ve broken it into several sections. Many thanks to Ms. Goodwin and Wiley for allowing us to share this with our readers.

Sales stakeholders

Sometimes sales and marketing are lumped together in an organization, but most large companies split the two functions. In either case, sales and marketing people tend to have different concerns, so it’s important to include one or more senior members of the sales group as part of the product team. This is true even in companies that ship consumer products, since the distributors or stores to which they sell have their own concerns about things like shelf space.

An enterprise system sales team is often closer to the customers than the marketing team is. In most cases, though, that doesn’t mean they’re closer to end users—IT tools and systems used by small groups of experts are the likeliest exceptions. They may also be more focused on the here and now, since they’re getting evaluated and compensated based on today’s sales, while the marketing group is more focused on the future. Sales people may be among the voices pushing to ship the product right away. However, this is tempered by the fact that sales people get an earful when the customers are unhappy, so it’s not in their best interests to push for shipment of a product that isn’t ready.

A sales person’s biggest worry during design research is that there will be other people spending time with his customers, possibly making a bad impression, promising things he can’t deliver, or saying something that will cause the customer to wait and buy next year’s version instead of next month’s incremental upgrade. It’s important to acknowledge these concerns and to promise that you won’t do any of these things.

Good questions for sales people often focus on what they hear from customers or see at customer sites:

Who is typically involved in the purchase decision?

This question will help you identify all of the right people for design research. For example, a hospital IT department may be the apparent customer for an information system, but you may not realize that the heads of medicine, nursing, the lab, and other departments are very influential.

Why do customers buy a product like this one, and why this one over a competitor’s?

This is good preparation for later interviews with customers. A related but sometimes useful question is, “What one thing could we do to this product that would make sales easier?”

When you lose sales, what are the most common reasons?

People are sometimes puzzled at having a designer ask this kind of question, but it’s helpful in identifying potential product weaknesses. In some cases, though, what customers say is not really what they mean. For example, when people cite a competitor’s user interface as better, sometimes it’s not that the behavior is better, but that the visual design is more attractive. In other cases, the deal is lost because the product lacks important functionality or the workflow is inferior. Naturally, there are also reasons that designers are less able to address, such as poor customer service or shoddy manufacturing, though these are worth pointing out to stakeholders.

What things do customers complain about or ask for most often, and why?

Customers, like stakeholders, may ask for certain solutions without identifying the problem they hope to solve; be sure to ask the sales person why customers are asking for particular things. Sales people often don’t take the time to probe and learn the need behind the feature request, but the answer to this question may hint at some things to look for in customer and user interviews.

See also

Excerpted with permission from the publisher, Wiley, from Designing for the Digital Age: How to Create Human-Centered Products and Services by Kim Goodwin. Copyright (c) 2009.

Posted in Deliverables, Deliverables and Documentation, Process and Methods | Comments Off

Sorry, comments are closed.