Good Brainstorms Drive Outcomes, Not Outputs

Brainstorms are fun and essential for almost every product team.

They can get everyone in the team involved, they help fill out your backlog, they’re the things that get creative-minded folks out of bed in the morning. 

But there are many ways teams can let brainstorming sessions get in the way of progress.

Brainstorms can be noisy, and without active facilitation, they’re not always inclusive to all members of the team. They can be emotional (people tend to love their own ideas) and without the right structure, they can quickly tailspin into being counterproductive. Everyone has experienced at least one brainstorm where the team struggled to decide on the next steps and then defaulted to a vote, nervously hoping that a 51% majority would reveal the right thing for the team to build.

But by far, the most dangerous form of brainstorming is when teams rush to brainstorm the wrong thing and jump into solutions before they fully understand the problem. Skipping the problem to think of solutions usually means the team is focused on outputs, rather than outcomes. What you build and ship is an output, but the only thing your customer needs and cares about are outcomes. The first step in delivering outcomes is understanding what problem stands in the way.  

At HubSpot, the Growth Team’s responsibility is to convert someone who signs up for our free tools into a delighted customer by helping them unlock the value of the HubSpot platform, no matter what their software budget is. Rather than diving right into a discussion about all of the things we could possibly build to achieve this (aka outputs) we shelve blue-sky ideation in favor of focusing exclusively on understanding what problems exist in the user experience today. Why? Simple: getting clarity and alignment on the problem yields higher quality solutions. If someone told you they were injured and needed help, it would be difficult for you to know whether they needed crutches or a bandage unless you had more information about what the issue was. It’s the difference between “ready, aim, shoot!” and “ready, shoot! Did we miss? Shoot again!” 

Here are some key themes for guiding a conversation around problems, specifically the friction standing in between your users and the desired end state. I present to you the three D’s:

• Discoverability
• Desire
• Doability 

Discoverability

Can your users find the action they need to take to be successful with your product? This is a great first question in the problem discovery process, yet simple adjustments to interface design are something teams may overlook in favor of chasing complex solutions. Jason Fried has a great framework for understanding discoverability hierarchy called The Obvious, the Easy, and the Possible. Oftentimes, the problem your product has is that there’s an important task or action that should be easy or even obvious for your customer to locate, but for some reason, they struggle to do so. Prioritize understanding if this is a pothole for your customers before moving on to other hypotheses. Validate what your users are struggling to locate, architect solutions from there, and if they work, you’ll have confirmation that you’re on the right path.

Some helpful tips and launch points:

• Make sure that you have instrumented all page and button views in your analytics tool of choice and then study this data first. If the vast majority of users don’t see the button or the page the button is on, you could have a discoverability problem. 
• Check your pages on multiple devices and browsers. If the content is below the fold, then it’s possible people aren’t seeing it.
• Institute a quarterly cadence of usability benchmarking to help identify areas where users are struggling. Task-based usability is key to answering your discoverability-related hypotheses, and the same goes for desire and doability, as you’ll see below. 

Desirability

So let’s assume the action your users need to take in order to be successful with your product is easy, maybe even obvious, to locate, yet they still don’t take the action. Well, the truth is that the people who use your product can read between the lines. When we put that big button in our navigation bar, users are well aware that it’s because we, the product team, want them to take that action. Perhaps the reason that no one is clicking it is that they, the users, don’t want to. If you’re wondering why no one is clicking on your big button, your users may lack desire. Spending time with your team brainstorming hypotheses about why users don’t want to do the thing you’re asking them to do is time well spent. So much of growth work is manufacturing motivation. Come up with some ideas about why users don’t want to do the thing, talk to them to validate whether you’re on the right track, and then figure out ways to fix it.

• Some tips to try
• Don’t look past the words. Content testing is important and getting your meaning and message right can often help manufacture desire from your users.
• Check your funnels. If people are seeing it and not clicking, don’t spend weeks testing button colors.
• In your usability sessions, find out why users don’t want to click, in their own words. Maybe they aren’t ready yet? Maybe they don’t care about it at all? Maybe they’re not the person with the permission to do the action and they need their boss’s approval? Whatever it is, go talk to people and find out.

Doability

Ok, so you’ve made the button obvious, you’ve confirmed users are clicking it, but they’re not finishing the flow. Maybe the action is just too damn hard to complete. Understanding your product’s usability issues and addressing them is critical to growth ⁠— your team should care about this as much as they think about shipping new features. Just think: if your highest-intent users and customers are struggling to do basic things in your product, how much money are you leaving on the table? Take the time to understand which flows are causing your users pain.

• Some best practices
• In your usability sessions, observe people trying to complete the task in your product, unmoderated. Even if you’re 1000% sure your product is easy as pie and flawlessly amazing, humor those around you by putting it to the test in a usability session. The results can be unsurprising at best and downright mortifying at worst when you see people struggling to complete a task. But that’s how you make your product better. Embrace the cringe. 
• Cut out the cruft. Eliminate features or steps that are unnecessary or force users to provide data you don’t do anything with. 

While it may seem small, adopting this method has helped our team significantly. Focusing on problems first has helped us be more efficient with our meetings and more effective in our execution. And most importantly, it’s helped us become an outcome-driven team rather than an output-driven one.