When to be Hasty with Product Research
More haste! Less speed!
This contradictory plate hung in my grandmother’s kitchen when I was a kid. It bothered me that the saying was so nonsensical. Haste and speed are the same thing. How can you have more of one and less of the other? I was suspicious of the plate. I took to ignoring it. Later I decided maybe it was a poor translation, like those t-shirt word-play-translations: “Settle for less than you deserve” or “So take a chance and don’t ever.”
I inherited the plate decades ago, and recently got it out of storage. The saying still annoyed me, so I googled it to see if there was an explanation or a source. It turns out the phrase is typically written with a comma.
More Haste, Less Speed
According to the explanations, the comma is playing a much bigger role than you might suspect. In fact, the comma ought to be replaced with an arrow to indicate causation.
More Haste → Less Speed
If you go too fast you’ll mess things up. Then you’ll have to spend extra time fixing them. Apply this concept to what happens within product development in a tech organization, “and don’t ever.” Heh.
“Move Fast” Works for Engineering, Not Understanding People
Working quickly in product development is widely embraced and fairly established. The goal of lean product development is to validate ideas and test prototypes before investing too much time in code. It’s about not getting too swept up in a solution— investing the least effort for the greatest clarity in which direction to follow for actual development. This is good. And evolving.
But working quickly is a problem when it comes to understanding the people you’re trying to support. I mean deep understanding — not opinions, likes & dislikes, or explanations of what people are doing. Those are easy to collect quickly. Deep understanding is how people reason and react and guide decisions as they achieve the larger human intents and purposes of life.
Many organizations incorporate understanding people as a part of an overall cycle, only to run into trouble. When they try to exert the least effort for the greatest clarity in deeply understanding people, it doesn’t actually fit into the process. There’s not enough time for it. Teams value the knowledge but are constrained to make do with shortcuts, which sometimes lead to sloppy pseudo-science. Teams invent people’s perspectives out of quantitative data or survey choices. They unconsciously assume a person thinks a certain way because of a demographic correlation. To avoid these risks — to allow time for deep understanding, I recommend that you sever deep understanding from any cycle and let it run separately. Slowly. In small increments. With a cadence that makes sense for what you want to know and when you need to know it. This means little breaks in product development now and then where your team gets into people’s minds. (Or it could mean a parallel team doing this research, but that runs the risk of the knowledge not really being absorbed by the people who need it most.) It takes the haste out.
How do you know when to engage in deep understanding? I’ve got some guideposts below.
Understanding People
Understanding people comes in a lot of flavors. All of them are useful at different points of product management. Some of them can be run quickly, but not others. Let me clarify.
The most common definition of understanding people is making sure your solution works for people. It’s A/B testing, usability testing, user interviews, or analytics. It occurs after the designs have taken some sort of form.
Becoming much more common these days is validating an idea that your team has — making sure the concept has legs before spending any time on development. It’s doing just enough research and validating concepts as frequently as possible. It occurs after ideas have surfaced, but before they’ve taken design form.
Even less common is understanding people before idea generation. It’s trying to get inside people’s minds to see how they achieve their larger intentions and purposes without reference to your organization. The goal is to allow for later idea creation that is not constrained by existing services or organizational philosophies. It occurs before the ideas come up.
Here’s an example, in reverse chronological order:
After the design has taken form: How well does our gym coach app work for people? Does this feature work better in this configuration or that configuration? What about writing the content this way or that way? Why aren’t people responding as we expected? Why are our customers behaving the way our quantitative data depicts?
After the idea has surfaced: Is our idea of a gym coach app going to be helpful? Can customers help us come up with features? Did we look at this from all angles? Can our idea be tailored to support different audiences in different, nuanced ways? Which of our ideas will make the most difference?
Before the ideas come up: What went through people’s minds as they have worked to stay generally fit, to lose weight, to recover from an injury, to train for an event as a newbie or a repeater or a champ, to build muscle? What are the patterns of reasoning? What kinds of different thinking-style segments do people fall into? Which of those segments or patterns do we want to support now? Later? Can we provide deeper support or maintenance of a person’s intents? Are there opportunities to (re)define our offerings so people naturally flock to us because of how well we support their thinking? How can we compete based on intrinsic value in people’s lives instead of simply monetary value? Are we leaving brilliant ideas undiscovered?
The italics in all three sections above indicate questions that organizations have trouble answering with confidence. These questions require deep understanding of what goes through people’s minds. These are the questions that cannot be answered speedily.
Deep Understanding
The connection between your organization’s offerings and deep understanding is support. How does your organization help people achieve their intent or purpose? (Instead of support, it could be “persuasion” or “behavior change,” but those are topics for another day.) Which thinking-styles do you support better than others? Digital products are past the pioneer phase now. So successful organizations get ahead by providing support that is not minimal but nuanced and varied, paying attention to many details and perspectives. It’s more than just decorating interactions with wry phrases designed to make people grin — which ultimately fail for a much larger percentage of users than you suspect. It’s about providing different answers for different thinking-styles, or choosing which thinking-styles to help with.
Let me define “deep understanding” again. It’s what people are thinking and how they are reacting — not about tasks and goals, but as they pursue larger intents and purposes. It’s not “book a flight” or “take a trip,” but “rescue the client relationship.” People achieve that larger purpose in a number of different ways, following a number of different philosophies. If you are asking questions like those in italics above, you can collect and curate this knowledge in a depiction of the reasoning-patterns (mental model diagrams) and the thinking-styles (behavioral audience segments). And you can consciously and clearly decide to execute in support of certain patterns.
One of the other things about deep understanding that makes it different from other flavors of research is that it doesn’t grow stale. It’s valid for years or decades. It’s about people’s human thinking, not about technology or interactions with services. Human thinking doesn’t evolve all that quickly. (E.g. deciding to attend a performance.) You could have asked your great grandparents and gotten answers that would still be valid today. This research can be added to over time, cumulatively. Hence your team can add little chunks to it over time, when certain questions come up.
The value emerges after you re-frame the way you think about the problem as if your organization does not exist. When you come back to reality after this little exploration, your deeper understanding influences the way you think about the solutions. You can spin quickly for several months in the design and development cycle based on the deep understanding you gained.
When To, When Not To
Organizations need all kinds of levels of understanding people. It’s good practice to know which kind of understanding to reach for in which situation. When you have questions like those in italics, above, you reach for deep understanding, whether it’s pre-idea, post-idea, or post-design. But more importantly, you don’t reach for deep understanding when your questions are more typical of the development process. These other explorations can more easily fit into the spinning cycle.
If you think of all the possible research/understanding tools at your disposal, the reasons-for-use fall into the intersection of evaluative, generative, quantitative, and qualitative study.
You can think of the boxes that result from these intersections as toolboxes, in a way. Depending on what you want to achieve, you reach for a tool in one of these boxes. Mature practices reach into each of these boxes, over and over.
But in the diagram above, I want to bring attention to the fact that even mature practices spend most of their energy focused on thinking post-idea and post-design. This arena is referred to as the solution-space in product management. There’s another layer, called the problem-space. That’s pre-idea.
The italic questions above are all answered with qualitative studies, and they scatter across generative & evaluative, solution-space & problem-space according to the nature of the answers desired.
Pick the right tool for your intention. Use lots of tools, and make sure you have a balance of knowledge from each of the boxes. Most of your research goals will fit into your existing lean processes reasonably. If you try to squeeze deep understanding into your existing cycles, you’ll try to push it too fast, and poor information will result. That poor information is a risky foundation for product decisions, and more often than not it will mean you will have to go back and re-do something. So I recommend running the studies you do to gain deep understanding separately from your lean process. Chop them off; run them at a separate cadence. For this, the motto stands.
More Haste → Less Speed
References:
I’m thrilled that so many people across fields are working to evolve and clarify processes involved in product development. I’d like to thank the following people for their inspiration in my thinking.
Product management leaders Teresa Torres, Jeff Patton, and Marty Cagan talk about a dual-track approach, where Product Discovery is separated from Product Delivery. In Discovery, they talk about creating a deep understanding of the customer’s world as well as iterative testing of initiatives. Teresa says, “There isn’t a good picture of what good discovery looks like. It’s still evolving.”
Well-known product management leader and author, Dan Olsen, interprets the existing process vocabulary and combines it with what product managers do — take knowledge from Discovery and propose something to address it. He’d like to define four tracks that work across the problem-space and solution-space divide: Discovery, Definition, Design, Delivery.
Laura Klein approaches this concept from a UX background. Her book, UX for Lean Startups, emphasizes the testing of the ideas as hypotheses. Laura writes that deep understanding of the customer’s world triggers rich ideas.
Bridging the worlds of IT and design, Mike Clarke focuses on outcomes, which is another word for purposes or intents, I believe. He talks about three tracks in a process, as seen from both the user and the business perspectives. The first track includes “insight research.”
Design Thinking, according to the Stanford Design School, includes five steps that cascade from each other. The basic process flow starts by developing empathy (deep understanding) and then defining the problem.
In the book Design A Better Business, the cycle is a figure 8, passing through Point of View several times.
Thanks also to Jeff Gothelf, Jeff Patton, and Christina Wodtke for inspiration.
