Love the problem, not the solution
Technology, business considerations and user needs all play a role in solution development
Weeknotes #9: July 20–24, 2020
I wasn’t sure if I should mention it, but since the project lead tweeted about it..!
This week we kicked off a Tiger Team to investigate possible applications of the Microsoft Hololens at Transport Canada. As a user researcher, my role is to “keep us honest” and ensure we’re addressing user needs, and not just getting enamored with new technology.
This is a pretty familiar place for me; as a product strategist (and later the manager of innovation strategy) at ReadyTalk, I was involved in a lot of investigations into potential new technologies and product offerings.
We live in a world of limited resources. As organizations we’re limited in what we can build or deliver, and our users have limits of how many new products or services they’re willing or able to use. So we need to be sure we’re focusing our resources on what’s really going to make a difference.
The best (only?) way to do that is to:
- understand our users’ needs (problem space)
- deliver a solution that’s substantially better than the incumbent, in order to any overcome barriers to trial and adoption (solution space)
When we start with a hypothesized solution in mind, it’s tempting to stay in that solution space and focus on tactical considerations. But this assumes that we’re confident we’re solving an important user need; that the user is struggling so much with how they do things now that they will put in the time and effort to seek out, try and learn a new way to do things.
There are countless stories of “innovations” that fell flat because they only offered incremental improvements, or they didn’t fit with users’ way of doing things. In the end, the friction of adopting a new solution wasn’t worth it for the payoff.
So we need to be sure we’re clear on the problem we’re solving. What job are our users trying to get done, and where are they struggling because things are taking too much time, or may result in errors?
Once we know our users’ needs (in the form of the statements “minimize the time to….” and “minimize the likelihood of…”), we can turn to the solutions stage. We can either come up with possible solutions, or we can look at a competitive set, and assess how well each option addresses each need.
As I write this, I’m reminded of Ash Maurya’s book Running Lean (still one of my favourite Lean Startup books!) and the script he provides when talking to prospective customers (users) during the Problem Validation stage. Before we rush to a solution, we need to be confident that our prospective users recognize the problem we are trying to solve for them.
We may have a hypothesis that a specific technology or product could be valuable, but we need to do our due diligence and try to disprove our hypothesis. This means deconstructing what we think this solution is going to help the user do, and then making sure it’s a real problem.
When starting with a specific technology, you can try to back into the benefits it offers. For the HoloLens, that may include:
- sharing what you see with someone who’s not physically present
- seeing relevant information overlaid in the users’ environment
- navigating content and capturing notes through a non-text-based interface (via gestures and dictation)
What are users trying to get done when these may be useful? Are there certain circumstances where these benefits may be more important, or indeed even crucial?
Don’t talk to me about ‘validation’
People who’ve worked with me in the past know that I hate the word “validate”. It’s very easy to delude yourself and find evidence that supports your position.
“Would you like to be able to dictate notes and not type them?”
“Yes, of course!”
There — we’ve ‘validated’ a use for the HoloLens, because HoloLens can support dictation.
Instead, I want to be sure we’re not suggesting solutions because they possibly could solve a problem for a user. We want to be sure that our proposed solution makes sense not only technically, but also from a business and user perspective.
I sorta hate the word “desirability” because it sounds very non-functional and gratuitous. But it can’t be ignored that the ‘best technical solution’ doesn’t always win (Looking at you, Kodak). Users care about getting their own jobs done, and that may mean a trade-off of ‘technical superiority’ for getting things done quicker or with fewer errors. So we need to find out what they value — what is important to them in considering success — and developing a compelling solution. And sometimes? That’s not the most fancy tech.
Starting with user needs
So, let’s say we have conducted research and learned that inspectors struggle with taking notes in the field. Being able to dictate their notes rather than stop to type them could be beneficial. That can help us feel confident about the problem, but that’s not the same as believing this is the right way to address the problem.
I have a Google Pixel phone. It supports dictation. I already own it, and it’s with me all the time! From a user perspective, if all I want is dictation, it may be easier for me to adopt a solution that is readily available. Before deciding on a solution, we should explore how else we could solve the users’ problem. Not only do we have to make sure the solution works, we want to be sure that it is easy to discover, learn and try. Everett Rogers’s work on the Diffusion of Innovations gave us not only the widely-recognized bell-curve of adoption, he also identified factors that contributed to the rate of adoption of an innovation.
I won’t go into each of these points too much. I only draw attention to this because technical superiority over the current solution is but one factor that can lead to whether a solution is successful or not. (I’m also ignoring that if you mandate people use something, it may be adopted even without effort put into these factors. But do you want to force people to use something if it’s makes their job more difficult?)
Of course there are business considerations!
Did you cringe above when I mentioned using my personal device? If so, you may have been thinking about the business considerations. If we’re trying to deliver a solution for our employees to perform their job, we don’t want to just let them use their personal device! We have business requirements (in this case, security is paramount!) we need to consider.
All three of these perspectives need to be taken into account before we decide on a solution.
One way we can ‘keep ourselves honest’ when evaluating solutions is to look at alternatives. How are people getting the activity done now? How are they doing it with different constraints in place? What are the tradeoffs they’re making now? What behaviour or policy changes may be required to support this proposed future?
There are many strategic frameworks to evaluate options, and each may have its own positives and negatives. What’s most important is that we’re trying to ‘make the right decision’, not to ‘be right.’ It’s far better to put out a risky hypothesis and disprove it so we can move on and explore other options, than continue down a path that may not lead us where we want to go.
All this to say, I’m excited to be part of this team, so we can decouple the “what could we do” and “what should we do” by focusing on what our users are trying to get done, and determining how best to help them do so!
