Have you ever watched your (potential) customers try to get their work done? Have you followed people in their daily work lives, and have you seen them struggle with products and services (or the lack of them)? Have you observed what users are doing, and did you make notes of how that is sometimes different from what they are saying?
I admit that this is one of my weakest areas of expertise. Like many other entrepreneurs, creatives, and inventors, my head is usually full of ideas, but I tend to jump to the implementation of new products and services without checking what potential users and customers are actually doing. And when I do make inquiries, I often make the mistake of only asking what people want rather than observing what they need.
I often make the mistake of only asking what people want rather than observing what they need.
I console myself with the thought that it seems to be a professional deficiency among product teams in general and developers specifically. As I wrote earlier, both Scrum and Kanban focus on delivery while they mostly ignore discovery. Continuous innovation requires both: discover the right thing to make; deliver to make that thing right.
Fortunately, there is a global community of professionals whose brains are wired precisely the other way around. In the disciplines of Service Design and Design Thinking (which I will treat as one and the same in this article, for the sake of simplicity), the emphasis is on figuring out exactly what users need rather than what they want. Professional designers use methods such as ethnographic research, participant observation, cultural probes, research walls, and journey mapping to analyze the behaviors of customers before they turn any ideas into user stories and hand them over to developers as backlog items.
The funny thing is, professional designers are sometimes accused of being interested only in the discovery of innovation and not in the delivery of it. Service Design and Design Thinking have dozens of practices for research, ideation, and prototyping. Still, they offer little or no guidance when it comes to transitioning good ideas from exploration to execution. They explore what is valuable but they don’t explain how to deliver that value fast and frequently. And that’s where Scrum and Kanban come in.
I see Service Design and Design Thinking as complementary to Scrum and Kanban.
In other words, I see Service Design and Design Thinking as complementary to Scrum and Kanban. Designers should learn to stick around during execution and not just throw their stuff over a wall to a delivery team. And developers should learn to understand user needs and not just mindlessly implement someone else’s requirements.
Continuous innovation is discovery and delivery. We should care equally about both.