Design Thinking
By David Shoaf

I recently had a chance to participate in a class on Design Thinking. Design Thinking, you ask? This course, sourced from the Stanford School of Design, presents some interesting concepts they clearly are quite excited about.  The term, I’ve noticed, has also started enter the lexicon of product management. Why would this happen?

Inbound product management functions have traditionally focused on market and product definition, the quantification of priorities to address problems found in those markets. It also provides guidance in the form of product requirements, value propositions and the related pricing, margins and forecasts necessary to justify investments in products that satisfy unmet needs in those markets.

Design thinking proposes that these elements are not really needed. Rather, the concept suggests that the only requirement is that the maker/developer merely collaborates with the user using structured methods of development. The resulting products are then clearly aligned to solve the user’s problem.

Design Thinking calls out five main phases:

  • Empathize
  • Define
  • Ideate
  • Prototype
  • Test

A few of my product management colleagues reacted with horror or disbelief that Design Thinking is being considered at all, while others embraced it as the “next big thing.”  Why? They point out that these 5 steps are not really part of the Product Management function or that “this isn’t what Product Management is all about.”

If I seem a bit snarky about this, I am.  For me, the problem with Design Thinking is that, in its current iteration, it will be difficult to scale for large teams and organizations.  Further, I see many elements of what the product management community now knows as “agile” development in this concept. Why would we convolute the essence of product management with yet another “cool” thing?

Specifically, the assumption that a company would expose its developers directly to customers and expect to see a competitive product delivered to market on-time and within budget is a bit farfetched. I have never met an engineering organization funded to sustain that sort of direct engagement besides a few consulting companies—and with it, the rates they charge!

In working with various organizations, product management teams need structure and discipline to deliver consistent guidance in the form of product requirements.  This means consistent PM Deliverables, and as the company grows, organizational complexity goes with it.

Should you consider Design Thinking? Sure.  there are some good ideas for the engineering community.  Does that mean you would completely adopt this latest-and-greatest- thing-since-sliced-bread? Of course not.

The key is whether it has value in motivating your product managers or providing higher value for the product management deliverables.  Don’t get stuck on the next big thing and abandon core product management structure and discipline.