Applied Design Thinking Part 1

Michael Hay
7 min readDec 1, 2024

--

An active Affinity Method-based design thinking session

Have you ever heard “What customer is really asking for that,” from an engineer? How about this question from product managers/owners “Will that feature make money?” While asking this and other questions is critical when used to stall or stymie building they aren’t helpful. What becomes clear when these questions are used adversarially or to protect turf is a lack of team simpatico. Ideally, a functional and diverse team would be asking hard questions of themselves in a safe place where disagreements aren’t penalized. An operative point, and focus of this article: How to build a functionally diverse team with simpatico fertile for Design Thinking and capable of setting the right pace for innovation? While the reasons for an accelerating pace of innovation can be debated; no debate is required for the necessity of innovation! Essentially, user and market needs can now be described with words like diverse, uncertain, random or nonlinear, and all are kindling for invention that can lead to innovation. Additionally, understanding what you might want to innovate on isn’t a question you can answer either alone or in an office. Instead the root reasons to innovate, and the needed pace can only be found out in the world with your target users by a diverse team. However, a team without simpatico and lacking a safe space to explore contrarian or wild ideas, as well as disagree, will invent a plenty and suffer an innovation drought. Yet, perhaps the best way to relate the development of team simpatico isn’t to be abstract about it, but through the fabric of a story…

A team with simpatico

In my own career the times of accelerated innovation occurred when there was boundless conflict and deep simpatico amongst the team members. I remember fondly the early days of Storage Management software at Hitachi Data Systems (HDS). We began our adventure of team building with conceptual product ideas that intuitively would not sell — we pointed that out, but our engineers asked us what customers said so. In these early days HDS did not have indigenous engineering and relied completely on the wizard like capabilities of the R&D teams in Japan. So, this meant that if we were to answer this question we’d not only have to gather market insights, but have an approach that respected people having English as a second language. (As it turns out this would become a key ingredient in a highly functional note taking process we’ll talk about in another article.). Acting in the role of a technical product manager I needed to quickly gather market insights in a way that allowed not just the core team of planners and engineers, who had English as a second language, to have a mutual understanding, but also allow the understanding to spread and stand on its own.

Therefore, I quickly reached out to field Sales Engineers and Technologists like James Burgh and John Pilger to set up times to visit customers directly and validate our ideas. In parallel we progressed our schedule, some lite customer briefing materials (using Design Thinking techniques), a questionnaire to guide our discussions, and flexible travel schedules. The team confirmed our schedules taking us across several cities and states in the United States. Finally the day came and we all met at New York’s Kennedy airport on a chilly winter evening. Upon landing a spry Larry Korbus led us on an adventure in the subway and then to our hotel in Midtown. I recall the next day as a blur, but that evening is etched in my long-term memory. That’s because we drove from New York to parts unknown in New Jersey packed like sardines in the back seat of a car for what seemed like forever.

During that trip we visited customers in New York, New Jersey, Georgia, and Texas, and somewhere along the way something magic happened. Perhaps it was because of the shared dinners in the airports, strip malls, or maybe the debriefing at that BBQ joint in Austin, TX where our host, 7 foot tall sales rep, consumed copious quantities of ribs. I suppose the precise moment doesn’t really matter the magic is that simpatico emerged and the team gelled. After that trip we were able to talk about sensitive topics, our families, go to our favorite restaurants and importantly when we needed to disagree and find a compromise we had the space for it. What resulted was ultimately a product that made some serious coin for HDS because it found a niche and solved real user problems. Since that chilly winter evening, I’ve had many similar experiences and a realization that real magic happens in the time spent on the road together to gel a team with simpatico.

Process distillations, and

The reality of my my previous article “Operating Technology to the Power of Information Technology” is that we developed teams with simpatico for Oil and Gas and Financial Services developments. While my references in that article to Design Thinking and Co-Creation are important, again behind that too are teams that gelled on the road. So regardless of an IoT future powered by Information Science, storage management software or consumer services the key to fast paced innovation is unlocking the human potential of a team! Therefore, it is my hope that this and other related articles operationally define and appropriately detail a “cookbook” that the reader can follow and learn how I captured and dispersed raw intelligence from target audiences to powerful teams. To start relating I’ve distilled some key points from my successes below related to engendering simpatico.

This process was usually led by a Technical Product Manager, or someone acting in that role, in partnership with engineering. What results are well documented raw intelligence, user narratives, user stories and early prototypes. These artifacts made what to do apparent for the Developer, Product Manager, Marketer, Manager, and Executive alike. It in fact led us to many mutual understandings, but the most important was a shared sense of priority backed by well documented user needs from real customers. Moreover, there were intangible benefits which resulted from the process of acquiring these data about the market, and they include at least:

Product Management and Engineering intimacy

  • What is it: An interview team composed of a Technical PM, a Business PM, an Engineering Architect, and an Engineering Product Owner which was the core team. Added to this was a Field Technical Representative from the targeted region with the right set of skills.
  • What does it do: This team would typically visit 15–20 customers to test specific product ideas and prototypes to capture user feedback.
  • What is the benefit: Because the team would spend multiple weeks together on the road and in the office to capture intelligence and produce insight, they formed a strong relationship that fundamentally established trust, allowed everyone to share the same voice of the customer, and produced a safe “space” to have healthy conflict.

A growing body of knowledge

  • What is it: A growing repository of user interview notes, recordings of interviews and their associated transcriptions.
  • What does it do: During the design phase the Designer, a role played by the technical PM, would pull from the repository new and old interviews to compose the right collateral for a design. The Designer would then manually read these interviews, and summarize key themes linked to specific customers and representative quotes for the themes. In later phases of the design, themes would be further detailed as user narratives, stories, mockups and in some cases prototypes.
  • What is the benefit: Since many of the topics where of a similar category — Data Center Infrastructure Management for Storage Systems — new Designs could build from current and past interviews resulting in a more robust design. In some sense, previous interviews afforded the Designer more inputs to base their design from. In fact, because many of the interviews were recorded, the Designer could literally hear the voice of the customer uncovering new insights.

A transparent design

  • What is it: Because designs were based off user interactions (current and previous) and in many cases the Design Team heard directly from customers the whole team could clearly link what users asked for with what was said. Since the design was inherently transparent, due to traceability, the team became dispassionate about their own ideas and passionate about meeting customer needs.
  • What does it do: The design, and future end user validations of design outputs, ensured that what was built met the right priorities that satisfied the most customers as needs. Additionally, because the design was for the “whole product” it always exceeded the deadlines. Therefore, a natural outcome was a roadmap allowing the product to evolve over time revealing multiple benefits to customers over time. (Today this is called the backlog in Agile-speak, but at that point they were just deferred requirements.)
  • What is the benefit: Products and services that met users’ needs, were competitive and ultimately grew revenues and profits. Additionally, the software capabilities began to influence pricing models, strategies and features of the underlying systems.

Banking interviews for the future

Over time we made material improvements to our approach, volume of interviews and processes overall. (More on this will come in future articles.) We leveraged our approach to peer into industry problems in Financial Services Compliance, Upstream Oil & Gas and the field of Human Resources. Further over the course of 13 years of work we amassed nearly 200 such interviews in formats that can be searched and analyzed. Having amassed so many past interviews has enabled the teams using them to explore, discern guide posts for post-it note driven design sessions, and more generally bolster proof for designs. It can also potentially defer the need for plane tickets thus compressing costs and enabling speed ups. Stay tuned for more specific and practical ideas in future articles on the topic.

--

--

No responses yet