Last week I played Bingo at work. Well, not exactly; I didn’t have a marker in hand, hoping to snag four corners. Instead I had the pleasure of attending a talk that was part of the SF Fed’s UX Design Center Micro-Series hosted by my buddy and colleague Brian St. John. (That’s him in the tiny square on the upper left.)
The talk was entitled “Listening. Envisioning. Disrupting Business as Usual,” featuring Tracey Kelly (Envisioning Lead at Microsoft–also with a book coming out in September, “Design Thinking in AI and Software Projects“) and Daniel Hunter (20-year veteran at Microsoft, from software development to sales, now Director at Microsoft Catalyst), who spoke about how design thinking was critical to their success.
Instead of the fixed sequence of a PowerPoint presentation, we started instead with a “Bingo” card of topics as the first slide, and we were invited to choose a topic for discussion. I was greedy and chose two. (I’m totally stealing this idea, by the way; it afforded more novelty and audience interaction, especially crucial for a Zoom call.)
So a couple of my (selfish) takeaways below:
The topic of “Understanding the problem” came first. It’s an often-repeated principle for product managers and product manager-adjacent types (I just made that term up), but one sometimes taken for granted because of its ubiquity. “When presented with a problem, we typically want to solve it quickly,” Kelly said.
This is a wholly understandable impulse. We fix problems! We come up with solutions! The topic resonated strongly for me: I manage projects in a software application development shop, and my colleagues do tend to jump straight into solution mode without stepping back to understand the user and the problem’s context. I will confess here that it’s a habit I myself have had to unlearn, despite my former academic background as an ethnographer who immersed himself in a specific community as part of fieldwork.
Kelly gave a visual example: that often-circulated image of a pie chart of knowledge, with the largest piece of the pie being “the stuff that I don’t know I don’t know.” “That’s where the problem space lives,” she said.
Hunter reiterated that understanding the landscape gave designers a wider lens in general. (I realize, as I write this, that you can’t have a literal roadmap without surveyors assessing the landscape first. Same thing with a product roadmap.) All this upfront work, before a single line of code or even a user story is written, foregrounds “problem definition, which is a huge shift for solution sellers.”
Asking questions, of course, was crucial—as were exercises such as the ladder of abstraction technique, and the 5 whys mental model—and had a direct correlation to understanding: “The more information you have to understand the problem, the better you can see all the options to come up with a solution.”
“It just takes stepping back,” Hunter added.
My second question was about Catalyst, an “idea framework” (or rather, an “I D E A framework”) that was thought up, pun intended, by the Design Thinking team at Microsoft, as part of their goal of co-creation with their customers. It’s a methodology they’ve scaled out to their business application sellers (now 3,000-4,000 globally).
Prior to Catalyst, their average time to close was 18 months—which they dropped down to 4 months. “In 4 hours (!) we got a customer to agree on a direction,” Hunter said. (Exclamation point mine.)
Catalyst employs the classic Double Diamond design process of divergence and convergence, ideation and prototyping: in the first stage, said Hunter, “we nail down the problem and then we diverge, without constraint, then converge on a unified future-state solution.” In the next stage, they quantify the business value of those solutions, and examine the customer’s technology landscape.
It sounds easy, but I can testify to the fact that the work accomplished in these stages are by no means trivial. Brainstorming fatigue does set in after a while, and the challenge for a facilitator is not just to keep activities fresh, but to coax out some form of convergence from a group of typically unherdable cats.
I was particularly interested in Catalyst’s “Empower” stage, which unfortunately we didn’t get to discuss, where so-called “solution demonstrations” are created and used to promote buy-in among different stakeholders, including upper management. Shifting the focus to “empowerment”—that is, collaborating with and supporting the Catalyst customers in communication—appealed to me in terms of business value, because I’m constantly confronted with this challenge at work.
But part of the fun, nonetheless, is crafting a narrative hook around the solution and how it emerges from an understanding of the user and the user’s problem. It’s a good test of my storytelling skills: something I use all the time in my fiction writing, but perhaps a little more challenging when talking about software applications. But as Hunter and Kelly say in their title, listening and envisioning are critical to the success of a product–and to telling a story as well.
Their talk was some of the most absorbing fun I’ve had at work in a while–my only regret is that I didn’t get to yell out “Bingo!”
(And thanks to Brian for being my beta reader!)