Oct 8, 2019
Five Steps to Continuous Learning in Your Product Company
Every product company wants to build better products faster, usually bigger too. However, very few organizations get as excited about learning—learning more, learning faster—as they do about building. There is an assumption that continuing to ship will make a product organization smarter over time, but this isn’t always the case.
With all the focus on certain types of obvious productivity, it’s easy to get down in the weeds or seize on a trendy technique and miss opportunities for deeper insights. And this means missed opportunities to make the best decisions for your business. And this means accumulating risk.
No one would suggest writing a bunch of code, shipping a few features, and then declaring that you were done writing code forever. Even the most process-averse young companies are keen to put processes in place to become a more “delivery-driven organization.”
If you are continuously shipping, you should also be continuously learning.
But this still happens with research. A growing sense that something is being missed can lead to occasional bursts of Big Research, or a semi-regular “research sprint” to make the r-word more palatable (the Flintstone’s chewable multivitamin of inquiry). A report emerges, perhaps a shiny PDF or multimedia extravaganza from an expensive outside agency. And then, the enthusiasm wanes and things proceed as usual, with the addition of some unease or doubt about this whole research thing. Tried it. Didn’t work.
If you are continuously shipping, you should also be continuously learning. The only secret sauce is curiosity. The rest is just committing to the fundamentals, which is really hard.
#1 Clarify Your Goals and Decisions
This sounds kindergarten basic. Research won’t help you—and you won’t be able to tell whether or not it’s helped you—unless you are crystal clear on what you want it to help you do. It’s easy to keep chugging along and reacting to events and feedback without taking a moment to make sure that everyone is clear on the business goals and aligned on priorities.
Do you need to define your problem space? Increase sales? Decrease support costs? Build awareness?
You won’t know what questions you need to ask and answer until you know what you need to achieve. (“What do we need to achieve?” is also a great starter question.)
#2 Collaborate
Once you have clear goals, you need to collaborate. Collaboration is simply working together to achieve a goal. Again, basic in theory, tricky in reality. People can work alongside each other for a decade and never truly collaborate.
The most common mistake that well-meaning product companies make is to hire or cultivate a great research specialist and put them in a corner alone. One person is learning learning learning and everyone else is making critical product decisions in relative ignorance. This places an immense burden on one or a few individuals to not only think of the questions, and conduct all the research, but to digest the insights and feed them to the product team and hope something sticks. This is neither efficient nor fun, and usually leads to resentment on all sides.
The researcher gets exhausted from trying to get leaders and designers and engineers to pay attention. The rest of the team doesn’t want to be told what to do by someone who isn’t in the trenches with them facing the same pressure to deliver.
Or, as an organization grows, there might be a general pronouncement that everyone is empowered to do their own research. This isn’t collaborative either because the learning will be neither strategic nor coordinated, and often not shared. Roles get mushy, and different versions of the truth come into conflict.
Just because a lot of people have the keys to UserTesting or SurveyMonkey doesn’t mean that the organization is as a whole is learning what it needs to learn, let alone learning how to learn. And it’s easy to get hooked on cheap, bad data. Research specialists are the best equipped to direct the approach and distinguish real insights from fluff.
If product team members have clarity around how their work contributes to specific business outcomes, and they understand how asking and answering questions increases the likelihood of those outcomes, then they will have a better idea how participating in asking and answering questions fits into their specific roles.
#3 Questions and outcomes over methods and activities
If there were one thing I could change about how most product companies think about research it would be to shift the mindset from activities to questions. It doesn’t matter what you are doing, it matters how much you are learning and how well new insights are spreading throughout the company as it grows. And a good question is a tool you can use over and over again to keep unlocking new insights.
I get so many inquiries from companies that start with “We want to run a survey…” or “We want to do customer site visits…” or something similar. This is the research equivalent of hiring a designer with a solution already in mind. It’s far better to start with “We want to learn about…” and let the methods and approach follow from that. Research gets unnecessarily expensive when you start with the method. The point is learning. You might as well do the cheapest easiest thing that gets you what you need. This is not cheating. Just because a particular type of research is more expensive doesn’t make it better.
Is your organization learning what it needs to make better and better decisions? Great! Are you burning through a lot of resources to make a show of science rigor? Bad!
Here is your universal research prompt:
“We want to learn [question] by [date] in order to [take action] to [achieve goal].”
Then you can figure out the best way to go about that. As with all design, there is no one right way.
Remember, research questions are not the same as interview questions. What you want to know is not the same as what you can ask anyone directly in a survey or face-to-face.
I need to make a special comment about “experiments”. I’ve started to hear this word a lot more lately, as in “We don’t waste time doing expensive research, we focus on running experiments.” It usually translates to doing bad testing instead in order to save money in the short term and avoid learning things you don’t want to learn, while sounding rational and objective. People who argue against doing research at all in favor of sprints or experiments are fighting the wrong fight, making an attempt to substitute a magic item for a scary word.
#4 Plug the memory hole
A continuously learning organization is a continuously remembering one. It doesn’t matter how much you learn if you forget it all when you wake up the next day. This is ridiculously easy to do if something unexpected arises.
Forgetting is exacerbated when learning happens outside the main course of product work using special tools and communication channels. This also happens when one person is supposed to hold all of the questions and insights in their heads. The more heads you store your insights in, the better your organization will be able to remember and act on those insights.
In addition to being essential for effective, purposeful work, shared goals and questions also act as a framing narrative that all future findings can refer back to. A coherent narrative of inquiry—a story—will impose order on all of those individual facts, quotes, and datapoints swirling around.
And use checklists, for everything, always. Human memory sucks. Checklists save lives.
Do your research and talk about it using the same tools you use for everything else. Plan studies in Asana. Save your notes and transcripts in Google Docs. Share insights using GIFs in Slack. Make large attractive posters of participant quotes and design mandates to hang behind your head in Zoom, or on your actually corridor walls, if you have those.
#5 Learn and reflect and do it again
Reframing research as “learning” helps you use all parts of the animal. Too many individuals and organizations fret about doing it right. This happens because there are so few opportunities that there is a lot of pressure and perfectionism. Embrace the messiness of learning. Squash the fear of looking ignorant. Affirmative ignorance is a growth mindset. A perfect surface offers no footholds for contributions and improvement.
The research isn’t good because everything went perfectly or the report is shiny. Nothing improves your screening process like a couple of bad recruits. The research is good because it tells you something about the real world that increases your confidence and decreases your risk.
Design goes through iterations. Code has bugs. Research activities will provide you with opportunities for unexpected learning.
You will always be doing it wrong. Yes, be ethical. Yes, have an explicit standard of confidence to assess your results. But don’t hold yourself and your team to an unrealistic standard that only increases anxiety without adding to knowledge. And take those pauses. It is impossible to integrate new information without time to breath and ruminate.
Now go forward and find out how wrong you are. It’s your best chance of getting your products right.
Get a copy of Just Enough Research 2e right now and you’ll be on your way.
