Empathy, Context and Customer Management: Design-Centered Procurement (Part 2)

tesla Kaspars Grinvalds/Adobe Stock

Back due to popular demand: We're bringing this Plus series out from behind the paywall so all procurement professionals can start using design thinking to inform their procurement architecture — and learn how user-focused software enables this process. Read the first three installments in the coming weeks, or download the white paper today to get the full story all in one PDF!

In Part 1 of this series, we introduced the idea of design-centered procurement and how procurement needs to put is “users” (stakeholders) at the core of what it does. The heart of good design isn’t just about aesthetics, but about solving a problem — or lots of problems at once. Those problems are very situational, but there can be many common problems as well. The trick is to tease out the problems that are situational to the environment versus dispositional regarding the person experiencing the problem. Both are valid — you need to understand “where people are coming from.” I know this sounds like an eHarmony line, but the reason why Google/Alphabet is worth nearly half a trillion dollars in market capitalization is due in part because its search results are deeply compatible to your situation and relevant to the problem you’re trying to solve when you go searching (i.e., Google is a finding engine, not a searching engine). If you’ve noticed, your search results, especially on your smartphone, are increasingly freakishly relevant, because Google (and an ecosystem of other mega vendors) is constantly watching you and has a digital profile of you (i.e., who you are) that uses your behaviors (and your attributes) to predict what you want so that it can help you find the solution to your problem — and also serve you up to its advertisers. It all starts with you as the customer and your problem as the context. In the rest of this analysis, we’ll discuss how to do this.

Implications for Internal Procurement Service Providers

If procurement groups want to influence spend more deeply to add more value, they need to better segment their “customers” more deeply before engaging them in a more focused way.   Casual requisitioners, departmental business buyers, functional budget owners, business unit budget owners, category managers, junior buyers, transactional buyers, suppliers, senior management, BPO/MSP staff, center of excellence (CoE) staff, “shadow” procurement staff, etc. are all different personas, too, that play different roles, have different metrics, and speak different languages (sometimes literally).

So, the questions for practitioners to ask themselves are:

  • Have we segmented our customers (i.e., stakeholders) and tailored our engagement strategies for them?
  • Have we captured how they define success of the buying process and understand their role (and yours) in it? Do you know how they approach it (e.g., a supplier management centric approach versus a sourcing-centric approach) or even how they talk about it (e.g., Marketing groups using the term “investment” rather than “spend”)?
  • Have we performed a “voice of the customer” effort to capture their prioritized expectations from suppliers and from you (and performance against those expectations)?
  • Have we included technology systems-specific feedback (that IT can use too)?

Bottom line: It’s hard to design an effective operating model to influence stakeholders if you don’t understand the motivations behind their behaviors.   

In the area of “user-centered design” or “design-centered thinking” championed by design firm IDEO, the first step of the design process is empathize. Empathy is basically about understanding the context of users regarding who they are, how they think, what they believe, what are the problems they’re facing and how they define success. It’s basically getting to statements of value that you can use to align your services/solutions to them, but also why those value streams are important to them.

If we return to the car example that we started off with in Part 1, consider now the comparison between the design of the ill-fated Pontiac Aztek and that of a Tesla Model S. The Aztek took a bunch of functional requirements (small SUV, rugged body cladding, Pontiac grille, smooth ride, gas-efficient, low-cost) and created a vehicle that checked the checkboxes but didn’t deal with the trade-offs through good design.

As you might expect, customers hated it during market testing. Of course, this didn't dissuade executives, though, because they had legacy assets to use, legacy jobs to preserve and siloed legacy metrics to hit. Sure enough, the program was an internal “success” and came in on-time and under budget. But against the big picture outcomes of revenues, profits and brand, it was a disaster. Only about 22,000 units were sold in 2001.

Tesla, on the other hand, fundamentally rethought the design approach (i.e., a high-end consumer electronics device that was also a kick-ass car) and basically put software at the heart of its design. The software not only constantly gets updated and gets smarter, but is used to collect actual usability data to inform subsequent product development efforts (in a sense, the car is actually a robot of sorts that will increasingly transport its precious cargo via self-driving functionality).

Tesla also used “design for supply” principles to use about 7,000 small batteries in its battery pack that could be sourced cheaply and competitively using standardized components (i.e., lowering risk) to deliver needed outcomes. The quality of the design cemented its role as innovator and brand leader. The Model S scored higher than 100 in Consumer Reports (on a 100 point scale!) and 400,000 consumers so far have put a deposit down on the Model 3, which isn’t even due out until late 2017.

Let that number sink in. Design clearly matters. If you sit in a Model S and drive in one, you’ll get a sense for the “customer experience” that people are buying. The hardware is great, but the software is the true game changer.

In our next installment, we’ll focus on the software, but in this case, the software powering the “supply management services solution” otherwise known as the procurement function.

First Voice

  1. Nicholas Martin:

    Very nice examples. Your concept of ‘Design for supply’ definitely makes sense in my industry (SaaS, eSourcing software).

    The innovations of the last few years have significantly changed the nature of eSourcing software, however we still encounter buyers who measure our solutions against the criteria of the past. (e.g. can it be installed on Premise? does it offer this esoteric feature?, etc).

    I am not saying that these factors are never important, however without ‘Design for supply’ they will mean that you risk missing out on opportunities to use solutions in new (and profitable) ways.

Discuss this:

Your email address will not be published. Required fields are marked *