2 Techniques Procurement Leaders Can Learn From Design Thinking

Design thinking is a set of approaches to problem-solving. Long used by creatives, architects, brand strategists, writers, over the past ten years it has become popular among business executives and software developers. Why?

Design thinking offers a more satisfying explanations for problems and helps leaders organize data to plan how to fix it. Rather than playing a blame game, design thinking encourages leaders to tinker with incentives, requirements and functional processes to achieve the outcomes that best serve the organization’s needs. This has amazing potential for accelerating beneficial outcomes in procurement organizations.

At a high level, design thinking is characterized by the following:

  • Iterative Process. Rather than trying to shoot for a perfect final outcome through deliberation (read: long meetings, analysis paralysis), iteration allows a group to put together something that works well enough to test, get feedback from users/customers/stakeholders and then change it throughout the course of a structured feedback process. Iteration means that leaders can admit when a guess is just a guess, groups resist becoming psychologically invested in dead ends and no one has to die on their sword by building consensus to commit to a course of action with insufficient data.
  • User-Centric Thinking. Design thinkers often put a big emphasis on the role of empathy in understanding why people behave a certain way under certain circumstances. This makes sense: if you can “put yourself in the user’s shoes” then you can understand why the user acts, or at least have a better idea. Like many aspects of design thinking, user-centric thinking may seem obvious, but anyone who has heard a product team gripe about the persistence of “user error” knows how easy it can be to blame the user for not understanding an interface, rather than taking responsibility for making the interface simpler/more accessible.
  • Fail Fast & Cheaply. Testing something doesn’t mean building it and watching it fail. Ideating, prototyping, experimenting and gathering feedback using precise, structured processes can happen in a variety of ways, using a variety of representations that are cheap, easy, and de-risk the possibility of failure.

What can procurement leaders learn from design thinking?

Before delving into suggestions for procurement professionals generally, I want to talk briefly about how our team at Bid Ops uses design thinking for our own platform development. Prior to adding a new feature to our product roadmap, we conduct detailed interviews with experts and realworld users to make sure that there’s a true pain point that our functionality will be able to resolve. Basically, if the feature eliminates a text field or adds relevant data to an evaluation matrix, we are usually eager to prototype it and then deploy it in a test bid environment where we actually go through a complete, live, timed rehearsal.

1. “Agile” Procurement.

The concept of “Agile” is an application of design thinking to the software development process. “Agile” is distinguished from “Waterfall.” In Agile, you create a Minimum Viable Product (MVP) as soon as possible, test it, gather data, iterate and then begin building the actual system. In Waterfall, you spend a lot of time deliberating, make a long timeline and the build a product without ever knowing if it’ll work until it’s been launched! To many Agile thinkers, that’s adding a tremendous amount of risk to the product, and increasing the likelihood that users will find bugs in the product later on.

Here’s a useful illustration (Waterfall is the top, Agile is the bottom):

 

procurement_bid_negotiation_agile

(Source: Henrik Kniberg ,  Agile Coach, https://twitter.com/henrikkniberg/status/691932339354599425)

Agile is distinguished from Waterfall.

Now think about this in terms of procurement. The traditional RFP process is essentially a Waterfall process: you develop the specs, perform the Current State Analysis, solicit a pool of vendors to qualify, gather pricing, evaluate award scenarios and all without knowing if the vendors will be able to deliver the goods/services or how well they will perform! This is the definition of Waterfall and it’s why you hear these horror stories of vendors low-bidding an RFP and then get stuck being unable to deliver at the promised performance.

Solution: Proof of Concept (PoC) procurement. The notion of paid pilots for a new technology solution has been prevalent in the start-up world for some time, but fundamentally the same principles ought to apply for a new vendor. If there are ways to see how a vendor will perform, either through a trial period or an “onboarding audit”, then you will potentially be able to draw out the award process for large, important purchases to gain additional insight into vendor performance and to explore the possibility of multi-award or collaborative scenarios, all of which reduce the risk involved with putting all of one’s eggs into a single vendor’s basket.

2. Progressive Onboarding.

Apps can be difficult to learn right out of the box, and there’s often just a lot of information! Visually, a screen with a lot of text can be overwhelming. Where to begin???? Well, designers came up with the idea of progressive onboarding, which means that you teach the user how to use the app bit by bit (rather than all at once) and the more they use the app, the more they unlock greater/advanced functionality. Here’s an example of how the popular collaboration app Slack does this, by only showing users how #channels work after they’ve logged in and begun poking around:

 

procurement_negotiation_vendor_onboarding

(Slack, image taken from Appcues, 2017)

Overwhelmed with too much information? Sounds like a couple RFQs I’ve read :) Much like old-school software, procurement documents tend to overwhelm the vendor with a huge number of requirements, asks for detailed information and chores in order to even submit for qualification. From a functional evaluation perspective, most of this information is simply not useful, and requiring vendors to enter in additional data means that fewer vendors will bid. That’s part of the reason that many procurement systems suffer from the problem of adverse selection: they foist byzantine administrative requirements on a group of users who are results-oriented sales people with limited time to devote to an abundance of opportunities. Progressive onboarding can and should be a way that procurement professionals increase the number of vendors competing for their business, by only asking for information on a need-to-know basis (e.g. at the point the evaluation process where such information could be win-qualifying).