Moving from “System One” to “System Two” Thinking for Product Decisions

Company leaders get very good at quickly assessing the situation and coming up with a reasonable sounding solution. Better solutions might be available, but in most cases speed of decision making trumps perfection. The issues has been dealt with, the blockage removed, and both manager and team can get back to the work at hand with minimum disruption.

Leaders Naturally Default to “System One” Thinking

This sort of intuitive, reflective problem solving—sometimes called “system one thinking”—naturally finds its way into others areas of the business such as making product decisions. The executive has probably been in this industry for some time, and has a strong opinion on what customers need and how the sector works. They feel like they have a strong feel for the product, and this has been proved out by previous funding rounds, happy customers and consistent growth. So these leaders will feel like they have above average decision making capabilities. In fact that’s a big part of why they have the job in the first place, and the value they bring to the table.

When a Product Manager comes to them with a problem—for instance, account activation is down—they’ll do a quick scan of the problem space and suggest what they think is the most likely solution. “We need to improve onboarding, so let’s create an onboarding wizard”. This gets added to the feature backlog. The leader can feel like they’ve made a decisive input and get back to the important task at hand. Probably writing some sort of strategy document about the emerging impacts of AI. 

The PM goes back to the team to tell them the good news. The boss wants us to create one of those tool tip onboarding tours. Here’s the Product Requirement Document (PRD) I created, so get to work on the designs. Of course this is the point where the designers thrown their crayons up in anger.  Don’t the executives realise how ineffective and passé these onboarding wizards are. Why did they bother to even hire us if they’re just going to tell us what to do. They’ll mumble something about “outcomes over outputs” or being part of a “feature factory” under their breaths, before getting on and delivering said wizard. 

The wizard gets launched 2 months later and seems to have a small, positive impact. However nobody is really tracking the effect, not least because a dozen other challenges have come up in the interim. This is seen as a solved problem, and everybody’s focus has moved on. 

Designers Try to Force “System Two” Thinking in the Least Effective (and Most Annoying) Way Possible

Designers hate the idea of delivering sub optimal solutions. Fortunately their answer is clear. If we do this magical thing called “research” we’ll get all the right answers and it’ll be impossible for leadership to ignore us any more. So they’ll increasingly ask things like “where did this idea come from?”, “have we talked to users?”, “how do we know whether this is the right thing to build?” and “what’s our confidence interval for this idea?” These are all valid questions. However they’re also super annoying questions. Especially if you feel like you’ve got a good solution and simply need to get that solution in the hands of users. As such, design teams quickly stop being the solution and start becoming speed-bumps the organisation needs to navigate around. 

One way to do this is by getting your Product Managers to talk to the customers for you. After all, they have a lot less on than the design team, who are meant to be shipping interface. Fortunately Product Managers don’t get embroiled in time consuming and potentially wasteful “research”. Instead they do the infinitely more important act of “customer discovery”. This generally involves asking customers what they want, and adding the most popular answers to an ever growing backlog. What could possibly go wrong? 

So if constantly pushing to do more “research” isn’t the answer, what is”?

Stop Asking For Solutions

I think the first approach is to simply stop asking executives for solutions, unless you genuinely don’t have a clue yourself. I’ve seen far too many designers and product managers go into meetings, ask executives outright what they should do, and then be all surprised, angry and disgruntled when they get given a solution to implement. 

Let’s be clear here. When you ask an executive how to solve a problem, you’re basically telling them that you don’t know yourself. This doesn’t instil a huge amount of confidence in your ability. It also tips them into that “system one” type of reflexive problem solving which they love. As a result there’s a good chance you’ll get a shallow solution you won’t like.

Much better to offer up some suggestions for possible solutions, or even better,  tell them what you’re going to do in order to come up with the right answer. “We’ve come up with three potential solutions to this problem. We’re going to create a some light weight prototypes, test them on a small number of users and see which perform best”. 

Now if you’ve been paying attention you’ll probably say something like “hold on a second Andy. That’s just research, and I’m pretty sure you just said research was a waste of time”. Of course I never said anything of the sort, but people really do like to oversimplify positions to the point of them being ridiculous.  What I’m actually suggesting is a subtle bit of framing. 

If the message you inadvertently communicate is “we really don’t know what we’re doing so need to spend an indeterminate amount of time figuring this shit out out”, this is going to start ringing some pretty big alarm bells. It sounds slow, time consuming and expensive. If the executive has an even vaguely credible idea, they’d be crazy not to throw it into the mix in order to get things moving. 

However if you’re clear that you have a number of possible solutions, and a process for deciding which of those solutions will have the highest impact, there’s really no problem to solve. You’ve got everything you need; no fight or flight responses are going to be triggered; and this is really just an FYI to keep the team informed of what you’re proposing as experts. 

Use Governance to Encourage “System Two” Thinking

The other approach is to use your governance process to favour “system two” thinking over “system one” thinking. What do I mean by that?

Well, if your current product management process is that every few weeks you have a meeting to discuss product issues, brainstorm possible solutions, and then add those solutions to your backlog, you’ve basically created a system which prioritises “system one” thinking. You highlight a problem, ask your execs to give you a solution, and then stick said solution in a backlog for delivery. Problem solved. Move on to the next issue. 

“Hey Depal, how’s work coming along on the onboarding wizard?”

“It’s going great Morgan, should be live by the end of the week. However we’ve got a bigger issue with WAUs right now.”

“I see. Why don’t we take the contents out of our message notification emails. That will force users to come back to read any messages they get sent.“

“Great idea Morgan. That’s why you’re the boss.”

In order to trigger the more considered “system two” style of thinking, you need to keep the problem in the field of view for longer. One way you can do this is to have an issue log which constantly brings you back to the key problems you are meant to be solving as a team, rather than a feature backlog where you effectively store “solved” problems. 

“This quarter our product team’s focus is on increasing activation and reducing churn. How that going Depal?”

“We’ve currently got a couple of experiments running around different onboarding flows. One is looking pretty good at the moment. The team has come up with a few other potential ways of moving the dial. Want to have a look?”

These might seem silly examples, but the key idea is to stick with the problems for “longer.” To follow a whole experimental cycle which allows you to try a bunch of different things and lean from what does and doesn’t work, rather than the more common “fire and forget” approach. 

Conclusion

Business leaders have been trained to operate in a reflexive “system one” style of thinking, and are generally pretty good at it. As designers and product people we often get better results if we can switch our decision makers into the more deliberate, rational and analytical “system two” style of thinking. One that sifts through evidence, weights up options, and cycles back to review results. Sometimes this can be done simply through framing, so think carefully about how you present your work and the sort of feedback you ask for in return. Changing how you structure decision making meetings can also show things down. Especially if you’re able to maintain issues in peoples working memory for longer, discouraging “quick fix” solutions in favour of more considered approaches.