Making decisions is extremely difficult, especially in an organization that is averse to change. Every company I have ever worked for has seemed to fall at least once into the trap of viewing tasks as large chunks rather than bitesize pieces. This eventually leads to a feeling of being overwhelmed by the sheer weight of decision. It's what is commonly called Analysis Paralysis. A feeling that I know all too well.
How the heck can we make this large decision about the future of our product with so little information? Why would we make such a massive leap of faith, even if every sign is leading us off the cliff?
These are the sorts of things that companies of all sizes who are wrestling with large decisions find themselves asking. These sorts of questions tend to keep products stuck in place. The fear is that one wrong turn will lose the company 'millions', even if you are only running $1000 in revenue a month. In this post, I'd like to explore why. Then I'll discuss ways in which I have helped make these decisions easier for organizations I have worked with.
Why companies (and people) get stuck in Analysis Paralysis
I want to clarify from the start that the thinking behind this mentality is not limited to just large, established organizations. Startups and Fortune 500 companies alike struggle with decision-making. Especially when they believe (rightly or incorrectly) that those decisions can sink their product. Who wouldn't be averse to making a change that could cost jobs?
The breakdown in the thinking at these organizations is that they believe another week of deliberation will make a difference. Unfortunately, the solution doesn't come to us magically overnight. And it definitely doesn't come without some degree of uncertainty. No problem is ever solved without at least a small bit of risk, whether it is mitigated or not.
The fear within these decision-making processes is that one wrong step could bring down the building. This fear of taking risks with a product can easily grind production to a halt. Your developers are left with little to no direction, and if you're running the product, you're not much better off. The secret here is to identify this sort of thinking in your own organization, and then begin to build a way out. It's not easy, but here is how I have worked through these problems in the past.
A warning, before we move on
I want to say upfront that I've been in enough of these situations to know that sometimes even the strongest product leaders let their ego get the best of them. Don't let yourself fall into the trap of choosing a narrative before you start this process. Come at this with as impartial of a belief system as you possibly can. It won't be easy, but it will be better for the company and your own mental health.
Step 1: Choose the largest assumption, then ask questions
The beginning of the process is simple. Take a look at the large decision that you are potentially going to be undertaking, and choose the largest assumption about that decision. The one that could cause everything else to crumble if you get it wrong. Then, spend at least three to four hours either validating or disproving that assumption. This can be done using data research, formal customer interviews, or even just simple discussions with non-customers you meet on the street. Your job is not to take a stance of whether it is the right choice or not, but to gather data to create a narrative. The idea here is to figure out whether you can pull one proverbial Jenga piece out of the tower without causing it to fall.
If you can completely break apart the direction for the product by proving that your biggest assumption is wrong, it makes it easier to change directions. You can then sit down with your team and show them that this huge, 6 month undertaking might not be worth it. This can save you hours of handwringing and posturing on behalf of your customers. At this point, it's time to either go back to the drawing board, or gather more data to further prove your findings.
If, however, your research leads you to prove that your largest assumption is correct, then it's on to step 2
Step 2: Repeat Step 1
Unfortunately, this is where you can get into a bit of a loop depending on how large your decision actually is. If this is a course altering, company changing decision, then anticipate being here for a bit. The end goal of this FOR loop is to get to a place where you have either validated or disproven all the major, game changing assumptions for this project. When you can come back to your team with a firm understanding regarding the validity of all your assumptions, it's time to finally move on.
Step 3: Take all your understanding and determine the scope
Every project has a scope. Whether you are looking at a large undertaking or a small one, it's important to understand just what the undertaking might be. We aren't working in concrete timeframes here. Rather we are trying to come to some understanding of whether we are looking at 6 weeks, 6 months, or 6 years. The reason for determining a rough scope here, is to figure out the best method for continuing on successfully into step 4.
Step 4: Find every large task and break it apart
Your project is bound to have massive tasks that could be anywhere between 1-2 months or work, or 1-2 years. These massive tasks are the roadblocks that you are going to try to remove on behalf of your team. We don't want to be dealing in the abstract when it comes to our largest tasks. That's why we need to identify them now, and break them apart.
Taking these large chunks of work and breaking them down into smaller parts will help in the following ways:
- It shows everyone just how much work needs to get done
- It exposes where the team can streamline the process
- It gives people to get a clear understanding of how their tasks fit into the larger picture
- It mitigates risk as much as possible
By taking on these smaller tasks, you can easily make minor adjustments here and there which can revise your project scope. That's why it's important to...
Step 5: Never stop testing assumptions
The first portion of every large task should be some process in which you put pen to paper to develop a plan. Whether that is a small team meeting, a wireframing session, or any other group planning strategy. It doesn't really matter which you choose, but including this time is important. You want to begin identifying now just what smaller assumptions are wrapped up in each of these tasks. Through some initial planning, it should become clear exactly what needs to be tested for each of these tasks.
It's getting a bit repetitive, I know, but this is extremely valuable. You see, by attempting to tackle the large, course altering decisions for our products, we sometimes fail to make the smaller, course correcting decisions. The idea of this step is to figure out which smaller decisions you can make now to help steer the ship in the right direction. Identifying and making these small decisions now can save you from major headaches down the road. You'll spend a little more time upfront in meetings for a lot less time down the road.
For example, let's say you are unsure of how your customers will want to see information on the dashboard for your product. The best decision to make here is to have your development team spend a short burst of time creating 3-4 low resolution walkthroughs of a dashboard. Then, identify a few user behaviors you want to test and ensure that a customer could walk through that flow of tasks in each of these dashboards. Finally, go find a few customers and have them do just that. Testing these smaller assumptions out now can help identify other things that need to be fixed later. The hope here is to continually test out pieces or chunks of your product on a regular basis so that you always know you are on the right track.
Step 6: Regularly check in with your team
Maybe you don't get a clear direction on which dashboard is best (which is fine), but you do have 100% of customers ask about a missing feature. That is extremely valuable feedback for your team and the direction that they are headed with the product. That's why it's crucial that you spend time meeting with your team members regularly to provide updates and check ins.
Meetings suck, we all know that. This doesn't need to be some long, drawn out process that takes hours of everyone's time. I'm really just talking about short daily (ideally) or weekly (still good) check ins with teams to ensure that everyone is headed towards the same goal. This can help you identify continuing problems that need to be solved cross-functionally. It can also help you find new things to either prove or disprove with end users.
Wrapping it all up
The steps here are by no means exhaustive. You'll find yourself continually adrift in a sea of potentially important questions. The key is to just pick an assumption or task, and test it out as much as you can. The more you do this, the better you'll get at identifying the little hang-ups that cause your team problems. Being a great Product Manager is as much about giving your team everything they need to succeed, as it is about knowing your team well enough to know where they'll struggle. Removing as much from their path as you can is what will help your team reach terminal velocity. Your job is to get everyone working on product to a place where you can barely keep up. That's the sweet spot, and boy is it exhilarating.