Skip to main content

VPM and Design Thinking

Design Thinking and VPM are complementary approaches. Design Thinking focuses on understanding the customer problem deeply before committing to a solution. VPM provides the execution framework once the team is ready to build.

The handoff point is straightforward: Design Thinking reduces problem uncertainty, and VPM reduces delivery uncertainty. Design work clarifies what should be built, for whom, and why it matters; VPM then translates that clarity into a visible, managed execution system with cadence, ownership, and schedule control.

In many organizations, these approaches run in a loop rather than a one-way sequence. Early delivery signals from VPM can trigger focused Design Thinking cycles to refine assumptions, while Design Thinking outputs can be reinserted into the execution plan as scoped changes. Used together, they improve both solution quality and delivery reliability.

Where Traditional VOC Breaks Down​

Many teams treat Voice of the Customer (VOC) as routine: run surveys, hold a few focus groups, summarize findings, then move on. The issue is not usually effort. The issue is structure. Conventional VOC often narrows discovery too early and turns rich customer reality into filtered summaries.

The following gaps are common in practice:

1) Single-Point Filtering​

  • One product lead or analyst becomes the main gate for what gets elevated.
  • Confirmation bias can push familiar narratives over contradictory signals.
  • Emotional and situational detail is often stripped out in translation.
  • Delivery teams hear a summary of the customer, not the customer directly.

2) Over-Reliance on Current Customers​

  • Survivorship bias limits input to people who already tolerate the product.
  • Existing users normalize painful workarounds and under-report them.
  • Non-users, churned users, and competitor users are often excluded.
  • The result is usually sustaining improvement, not breakthrough change.
  • This dynamic aligns with Christensen's warning in The Innovator's Dilemma that incumbent feedback loops can reinforce incrementalism.

3) Solution-Language Instead of Problem-Language​

  • Requests arrive as feature ideas constrained by current assumptions.
  • Teams optimize requested features instead of the underlying job-to-be-done.
  • This is the classic "faster horses" trap.

4) Premature Quantification​

  • Surveys are only as good as the questions already known.
  • Unknown unknowns rarely appear in fixed-choice instruments.
  • Exploration gets cut short before discovery has depth.

5) Averaging That Hides Segments​

  • Aggregation collapses conflicting user needs into an artificial "average."
  • Contradictions, which are often the source of innovation, are treated as noise.

6) Rational-Only Bias​

  • Research focuses on features, functions, and specs.
  • Emotional and social drivers (status, anxiety, identity, confidence) are under-captured.

7) Checkbox Validation​

  • "We talked to customers" can become political cover for decisions already made.
  • Validation is used to justify direction rather than discover it.

8) Builders Separated from Customers​

  • Engineers and designers are kept at distance from direct customer contact.
  • Empathy erodes when it is passed through documents only.

How Design Thinking Changes the Pattern​

Design Thinking addresses these structural gaps by changing who learns, when they learn, and how evidence is interpreted.

  • Cross-functional immersion replaces single-point filtering.
  • Interview pools intentionally include current users, non-users, churned users, and competitor users.
  • Problem framing is separated from solution commitment.
  • Qualitative depth comes first; quantification follows for prioritization.
  • Personas and workflow maps preserve segmentation rather than averaging it away.
  • Emotional and social signals are treated as first-class data.
  • Discovery precedes validation.
  • Builders participate directly so empathy is lived, not summarized.

When paired with VPM, these insights are translated into execution behavior: visible plans, explicit ownership, short feedback cadence, and controlled rollout.

How many people to interview​

Broadening the pool raises an obvious question: how many people is enough? A full workflow usually has four to seven personas, splitting roughly 40 percent provider, 60 percent customer. On the provider side that means Sales, Customer Service, and Product Marketing in almost every workflow, with R&D, Technical Sales, and Installation in some. On the customer side the Principal Investigator and Lab Manager appear in most, Purchasing and Lab Technicians in many, and more specialized roles (IT, Maintenance, the administrators who place and track orders) only in selective workflows. Trying to cover every role that could possibly touch the work pushes you toward fifteen personas, which is not workable.

A workable target follows two rough numbers. Count about seven personas per workflow, and plan three to eight people per persona to get a reasonable read. That puts you near thirty interviews per workflow as an aspiration, though twenty to twenty-five is a normal landing point.

Thirty sounds like a lot until you remember how many companies sit inside a single persona. "Three maintenance people, really?" makes sense only if you picture one team. Maintenance groups in Boston, Lisbon, and Shanghai often work nothing alike, so three is thin rather than generous. This is well below a scientific sampling standard. We take shortcuts on purpose, and that is fine for discovery.

Within the three-to-eight range, the central persona for a workflow earns the most, seven or eight. Beyond that, let learning set the count. Keep interviewing a persona until the interviews stop teaching you something. When one or two in a row add little, move your remaining slots to a persona you understand less well.

Set an interview schedule, then expect it to move. People no-show or go quiet, and some personas reach the point of being understood early, both of which pull the number down. At the same time you discover personas you missed and keep learning past your original target, which adds a few back. The net is familiar: start aiming at thirty and settle around twenty-five.

How to run a discovery interview​

These interviews are not VOC question lists. Good VOC questions get information. Design thinking questions poke at different areas until you reach the moment where someone says "and that's the problem, you don't talk amongst yourselves." Before the interview I sketch the workflow I expect us to discuss. I rarely share that sketch with the customer, but it tells me whether the right people are in the room, and it gives me something to mark up as the conversation moves.

I start with context. What is your role, how long have you been here, what is your history. Then I ask what role they normally play in the workflow we are discussing: are they managing it, is it occasional, is it core to their day. The answers tell me how to weigh everything that follows.

From there I start at the beginning of the workflow. "Let's start with how you request a system selection. Tell us how you kick that off." This is where the interview diverges, and that is the point. They might say "before we get to that I have to tell you about this," and I pick up a pencil and insert the step they just described. They might say "I don't kick that off, that comes from someone else," and I mark that I am missing a persona. Or they start talking, and I listen to them describe the flow.

While they talk I listen for pain points, gain gaps, and jobs to be done (JTBD). I make a note and tie each one to a step in the workflow. I watch non-verbal cues for intensity: volume, pace, the taboo words, the silences, the facial expressions. When I strike a nerve, the move is to ladder. "Tell me about that, what is that like." From there comes the step that did not go as expected: they needed input from us and could not get it, we asked for information that was make-work, they told us the same thing many times, the information we ask for is in the wrong form, and a hundred other things.

I show up with a handful of questions, four or five at most, because I want to be talking about five percent of the time. I do not want to set up questions, shift topics, or close down a conversation. They know what hurts. They need a conversation that brings it to the surface, and then they drive me from topic to topic.

Antipatterns​

  • Talking more than five percent of the time after the first ten minutes.
  • Asked-and-answered questions, the ones with a single answer and nowhere to go. This happens easily and kills momentum.
  • Too little laddering. Not enough "tell me more about that," "how did that affect what you were trying to accomplish," "do you expect that sort of thing." Laddering is how you dig into an issue that has deeper issues underneath it.
  • Insights you cannot tag to the workflow. Insight is the general word for a pain point, gain gap, or job to be done. When you cannot tie insights to a workflow, you lose the ability to organize them and rationalize input across customers. You might have a great one-off comment, but it will not drive the right decision if you cannot move from "this customer says" to "the market needs."
  • Insights without frequency or intensity. Someone may complain intensely about something that happened yesterday (recency bias), so you need to know whether it happens often or whether it is rare but highly consequential.

A design thinking question list is like the first ten or fifteen plays a coach scripts before a game. There may be a hundred plays in the game, but the coach prepares only the opening, knowing the game will develop and that the development will guide the rest of the calls. The questions exist to get the conversation going. Most of the decisions about what to ask next get made once the interview is already moving.

Customer Experience Foundation and Business Case​

Design Thinking is not only a design philosophy; it is an economic lever. Better customer understanding improves retention, spending, and resilience.

Experience Quality Correlates With Revenue​

Harvard Business Review reported that, after controlling for other drivers, customers with top-rated past experiences spent 140% more than those with the worst-rated experiences. In subscription settings, best-experience customers stayed roughly six years longer, while worst-experience customers churned much earlier.

Source: Peter Kriss, The Value of Customer Experience, Quantified, Harvard Business Review, August 2014.

Negative Experiences Destroy Loyalty Quickly​

PwC's multi-country customer experience survey found that 32% of customers would stop doing business with a brand they love after one bad experience. It also found that customers can pay a premium (up to 16%) for strong experience quality.

Source: PwC, Experience Is Everything: Here's How to Get It Right, Future of Customer Experience Survey 2017/18.

Retention Has Multiplying Profit Effects​

Bain/Harvard Business Review reporting on Reichheld's work shows that a 5% increase in retention can raise profits by 25% to 95%, depending on industry economics.

Source: Frederick Reichheld, Bain & Company, as cited in The Value of Keeping the Right Customers, Harvard Business Review, October 2014.

Taken together, these findings reinforce the implementation logic: invest in deep discovery first, prove outcomes in controlled pilots, then scale with VPM discipline.