Times like these call for quickly rethinking how your team does things. So, how can you surface new options, learn fast, and find better approaches?
Try these tactics to experiment more systematically and effectively.
Understanding the lives and challenges of the people your team serves — whether they are internal or external customers — is the critical jumping-off point for imagining how to make things better for them. In times of great change, your core users’ needs are likely changing, too. Your previous research and institutional knowledge about them might no longer apply or, at least, may need to be reconfigured.
To ensure that your team’s work stays aligned with your users’ evolving needs, start by asking your team for their observations using questions like:
To supplement and validate your team’s observations of your core users, consider short surveys, a handful of interviews, and/or a focus group with them. Research suggests that even small samples of users (as few as three to five) can provide surprisingly helpful insights that allow you to make good decisions, especially if you gradually build on what you learn by checking with users again during your innovation process to be sure you’re on the right track.
Be sure to keep your findings front and center as ideas swirl and gain momentum. Your users’ needs can — and should — serve as a touchstone when debates arise over which potential changes are worth testing.
Contrary to popular belief, breakthroughs are rarely 100 percent original. More often, they are small improvements on what’s already been tried. For example, Apple’s iPod wasn’t the first MP3 player — it was the one with the best design.
What existing concepts — within your organization and within and beyond your industry — can you and your team build on to better serve your users? To develop options, you can:
Unless you have endless time and funds, you’ll have to make some tough calls about which ideas are worth testing. Effective innovators often select ideas by considering how useful the proposed change will be for users and how feasible it is to implement, with a tendency to place greater value on usefulness: A really useful change that’s hard to implement typically holds more promise than a feasible change that’s not all that useful.
For example, let’s say you manage a help desk team for a new piece of remote-work software, and email volume has recently doubled. Users are experiencing long help desk wait times, and you worry that if wait times persist, poor service could drive away customers.
To zero in on good options, list out all of your ideas and evaluate them by asking:
If no clear best option emerges, could you break your team into groups and experiment with different options simultaneously until a “winner” emerges (as management expert Linda Hill describes Google doing in this Ted Talk)? Or could you try quick, scaled-down experiments for each option?
You might have an educated guess about what will happen when you make a change, but be careful — those hunches can lure you too quickly into solution mode, causing you to overlook important factors and to end up with a solution that doesn’t adequately address the problems. Instead, start with the fundamental questions you want to answer, which will help you design a more effective test.
For example, imagine you work for a hotel that uses entry key cards. Your team is rethinking the check-in process to improve sanitation for staff and guest safety and peace of mind. You don’t have the budget to switch to a keyless entry system, so you’re considering whether to purchase UV lamps to disinfect key cards.
Your research questions might be:
One of the biggest questions teams face when they experiment is how much time and money to invest in building out an idea before testing it. Slapdash prototypes can yield suspect results; your users might not be able to adequately experience or visualize the idea you’re testing. But full builds are expensive and invite confirmation bias; you’ve invested too much to interpret the results objectively.
Aim for something between these two extremes. Choose an approach that works for your industry and your team’s function. Some options:
If your team is accustomed to sharing unfinished work for scrutiny on a regular basis, these approaches will probably be easier for you. If not, you’ll need to do more to foster a team culture of risk-taking and learning on your team.
How do you judge if your hypothesis is valid? To be as objective as possible, try to use direct observation of behavior or results (e.g., did someone buy it?) rather than a hypothetical (e.g., a survey question asking “Would you buy it?”), which may not be a reliable indicator of whether someone would actually use or buy something. You may already have information streams in place that you can tap to gauge the impact of your experiment.
These streams could include:
If your team plans to supplement existing data by posing questions to beta testers, put careful thought into the questions to be sure that they yield answers that will help you improve your plan. For example, instead of asking your testers questions likely to yield generic or yes-or-no answers (e.g., “Do you like this?”), try questions like:
And follow up with the magic question “Why?” in order to dig deeper.
Effective experimentation demands humility. As a leader, you need to constantly remind yourself and your team that your desire to do right for users is way more important than your desire to be right. If you don’t, you risk letting your egos derail your decision-making and, ultimately, the team’s results.
Here are a few ways to cultivate this flexible, innovation-friendly mindset:
Teams that get punished for misses learn the unfortunate lesson that innovation isn’t worth the risk and they should stop trying.
This step may seem like it would take time that your busy team doesn’t have. But consider: A team who experiments carefully and efficiently gets reliable results faster. Think of scrutinizing your processes as an investment in your team’s future ability to innovate and excel.
For example, maybe your team realizes that the client interview data that took precious time to collect doesn’t yield much because, in the rush to start interviewing, the team failed to include questions about some critical areas. Or your team realizes only after lengthy experimentation that a quiet team member was right in their early critique — and that you need a system to be sure that dissenting views get full consideration from the start.
To unearth these kinds of insights, frequently ask your team in both group and 1-on-1 settings, “What’s one thing we could be doing better?” and keep notes on what you hear. And once you’ve completed an experiment, schedule time for a debrief meeting so that people can compare their observations on what worked, what didn’t, and what to do differently next time. Then, act on what you learn.