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:
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:
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.
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.
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.