Last week I shared a way you can head off bad ideas at the pass.
Yes, I know most of you are rarely involved in discussions that early. I can hear you know reading that last post and saying “that’s great Kent, but I’m never in that situation! What do I do when I get told to deliver something?”
Fair enough. You can still use outcomes, but instead of using them to decide whether to make an investment, you’re using them to decide how to deliver the investment.
Establish your outcome
Usually, when you’re asked to deliver something, that ask tends to be fairly specific. It’s usually in the form of a solution to deliver.
Think back to the examples from the last post.
- Rewrite a 20 year old client server app that supports a crucial business process
- Bring customers for a given product line on the same ordering system that three other product lines are on
- Introduce an express pickup service
Each of these describes a solution. They describe output. What you want to know is why the person requesting the investments wants these outputs. You want to know what outcome they are looking for.
You want to know why you’re doing the rewrite.
You want to know why you’re trying to switch the ordering system for a specific customer.
You want to know why you’re introducing an express pickup service.
You want to know what problem you’re trying to solve for each.
You could use the opportunity assessment like I described in the previous post, but the results could be a little disappointing when you find out that you aren’t in a position to not do that particular initiative.
Explicitly asking “Is this problem worth solving” when you’ve already been told to solve it might be frowned upon.
So when I’m working on a product where the organization has already decided they are going to make an investment, I find it’s better to use an exercise that helps build shared understanding around the outcome. I like to use a problem statement.
I’ll gather the team, the sponsor of the investment, and any key stakeholders to a discussion.
As you might imagine, these types of discussions can be difficult to schedule because the sponsor and some of the stakeholders may have several competing priorities and busy schedules.
Be firm. Have this discussion as close to the start of work on the investment as possible, and don’t hold the discussion unless the key players are there.
It helps to explain the reason for having the discussion and inviting the people you’re inviting. Let everyone know that you’re trying to build shared understanding, the intent of the investment. You’re not questioning the investment, you’re making sure everyone understands it the same way. This hopefully encourages the sponsor and stakeholders to make time in their schedule.
If you find that some of the key players are not making time, you can always consider the nuclear option. Ask the sponsor and stakeholders if they can’t set aside an hour for a discussion to make sure an investment delivers on its intent, how important is that decision really? Consider the impact on your job and influence in the organization before you exercise this particular option.
Once you have everyone together, ask the investment sponsor to explain what the investment is intended to accomplish. They will generally describe it in output terms at this point, which is fine.
Give everyone a chance to ask questions to clarify what the sponsor said. Don’t be surprised if there aren’t many questions. People will probably be operating in the mode of not understanding fully, but not wanting to speak up.
Next, ask everyone to take four sticky notes and write the following:
- The problem of <Describe the problem>
- Affects <Who are the stakeholders affected by the problem?>
- The impact of which is <What is the impact of the problem?>
- A successful solution would <List the critical benefits or key capabilities that the solution–however, implemented–must have to be successful>
Once everyone has written their cards, ask participants to read their statements in order and place their cards on four parts of the wall each part corresponding to a part of the problem statement.
You may have fairly consistent descriptions of the problem or widely varying descriptions. I’ve found that the amount these versions differ depends on how long the team has been working on an investment before this type of level setting. The longer the team has worked without level-setting, the more variance there will be.
After everyone has read their statements, have the group work through each part of the problem statement and come up with a statement that they can all support.
This discussion will not only lead to an overarching problem statement for your work, but it will also lead to a better understanding of a variety of key aspects.
Agreement around the first point (the problem of) brings clear agreement around the problem you’re trying to solve. This may also help you understand your main decision filter.
Agreement around the second point (affects) identifies the people that are experiencing the problem. These are people you want to make sure you’re considering and you go through the work of resolving the problem.
Agreement around the third point (the impact of which is) helps you understand why it’s a problem and also why it’s worth solving. And yes, if it becomes clear during the discussion that the problem is not worth solving, explore that with your sponsor. You may discover that the problem is worth solving with a smaller investment than what’s planned. Better to determine that early on then making a large investment on a problem that’s not really that big.
Agreement around the fourth point (A successful solution would) helps you to identify any constraints you need to work under and may also point out a couple more decision filters.
You now have a guiding view of the problem you’re trying to solve that you can use to guide decisions moving forward.
You have your decision filters.
You have defined scope in terms of an outcome, rather than a list of outputs.
You are now in a position to make outcome influenced decisions to ensure an effective investment. The nature of those decisions varies based on the type of investment you’re doing. Let’s take a look at some variations based on the examples described above and from the previous post.
Rewrite only what you need to reach your outcome
System rewrites have gotten a bad rap (somewhat justified) because they often become an exercise in dressing up clunky processes, bad rules, and jumbled up data in a shiny new technology wrapper.
Teams are handed an unreasonable deadline, insufficient budget, and asked to rebuild a system. The expectation, whether stated or not, is that the new system will do everything that the old system did.
Scope is described in terms of all the functionality you have to rebuild in the new product.
Except you probably shouldn’t replace all the functionality that exists in the current system. Some of that functionality is no longer needed. You may take the opportunity that rebuilding the product provides that allows you to revise the process.
Don’t define scope based on a list of outputs you think you need to deliver. Define your scope based on the outcome you intend to deliver. A definition of scope based on outcome allows you to operate in time and cost constraints and still flex within the output you do deliver as long as you satisfy the desired outcome.
I’ve previously described how a team I worked with used discovery sessions to build an initial understanding of an investment to rebuild an existing internal product. The purpose of that activity was to understand the problem, the environment in which we’re working, and identify how the new solution could address the problem without recreating all the necessary functionality.
We used the results of those discovery sessions, continued discovery along the way, and a constant reflection back on our decision filters to make sure we produced only the outputs we need and to build those outputs in a sequence that helped us learn what other outputs were needed.
Does this solution bring the results you want?
When you want to add more products to an existing ordering system or introduce a new express pickup service you may not be worried as much about the scope as you are about whether that’s the right solution to your problem.
The way you define scope is not as big a concern as understanding whether the identified solution actually solves the problem you’re setting out to solve, or if there is a simpler, less expensive way.
In this case, you want to be clear with your decision filters and then explore different ways to accomplish that outcome, which may be significantly different than changing the ordering system they use.
This is a good situation to use impact mapping or other techniques to make sure you’re solving the right problem. Look for ways to shorten the feedback cycle so you can try something, see how it works, and identify if it really is the solution you’re looking for. You may find that the solution you end up delivering is quite different than the originally identified solution.
Decide how to deliver an outcome
At the end of the day, just because you’ve been handed a solution doesn’t mean that you still can’t figure out what outcome people are expecting and find a way to deliver that outcome in the most effective way possible. It may just be in a different way than the folks who approved the investment originally thought.
I’ve shared some ideas about how I go about doing this. I’d love to hear about your experiences!
Some other perspectives
Outcome-oriented User Research
Tim Herbig in an issue of his Product Thoughts email newsletter shared some ideas he picked up about framing user research insights in a way that prioritizes demand (motivations to use a feature) over supply (feature ideas) using a Context – Solution – Result (CSR) diagram.