There are way too many articles out there regarding how best to make hard product decisions easier. Many people (including myself) will tell you that breaking these decisions down into smaller pieces will help. Others will tell you that improving customer research techniques will solve the problem. However, I want to talk today about how I've personally made hard product decisions even harder. In a follow-up post, I'll discuss what I've been doing to fix things.
How I make product decisions harder, and how you can too!
Making a conscious choice to increase the difficulty of our product making decisions is not something that most people do. What breeds this sort of behavior is really just old habits and lack of self-awareness. We can all slip extremely easily into the realm of making product decisions excruciatingly difficult. Some of us do it for years without realizing that we are making the lives of others more difficult. Here are some common reasons that product decisions become more difficult, as experienced by me and those around me:
Allowing indecision to beget indecision
A lack of product leadership is something that can be extremely detrimental to a piece of software or an entire organization. It brings to mind the maritime idiom of the captain having full responsibility of going down with the ship. With no one setting the course and leading by example, an entire product can falter and end up in the rocks. One of the main ways that a lack of firm leadership for a product causes failure is through indecision.
If you haven't experienced this yet, you might be asking how a LACK of decision can cause issues. I mean, you're just sitting still at that point, right? Unfortunately, a lack of momentum is something that most companies are not able to experience. And it wouldn't be a great thing even if they could. As the mantra goes:
If you're not moving forward, you're moving backwards.
The main issue with indecision at most organizations is that the lack of direction is infectious. It can cause entire departments to flounder for lack of work. Or worse, it forces individual developers to take the lead with little to no understanding of the product's scope. I'm all about empowering development team members to make product decisions, but not when they are ill-informed. See, indecision from a product leader can cause others to not only question a product's viability, but also a product leads ability to set a firm direction. Don't let yourself be caught up in the vicious cycle of indecision!
Forgetting to do your homework
Early in my career, I was definitely guilty of this one. Mainly because I was still wading in the shallow end of the Product Management pool. But now I know better. Mostly. When I say that I was forgetting to do my homework regarding large product decisions, what I really mean is that I was doing little to no legwork around researching and detailing product requirements. I was really just flying by the seat of my pants on a lot of the early product decisions that I was making.
A question would arise around what we needed to do regarding a certain new feature, and I would make a best guess. The problem with that behavior was that this 'best guess' was really just a shot in the dark. I had done almost no customer interviews, talked to no one outside the company about the feature, and was just overall lost. Most of the information that I had regarding the way that the product was laid out was based on flawed information from other people. I learned very quickly to not inherently trust what a developer tells you a piece of code does. Not until I've seen it with my own eyes and tried to completely break it.
My distinct lack of understanding when it came to our product and the decisions that go into making it better was completely brought about through naivety. I didn't know what I didn't know. It took me months to get some sort of firm footing, but in those early months, I made a lot of dumb mistakes with what I chose to put forward as important. Not doing your homework on what is supposed to go into even the smallest of features can cause you so much more work than you can ever realize. Never forget to do your homework and definitely don't copy your answers from someone else.
Not grading your work
You see, it was easy to forget to do my homework regarding product decisions in those early stages because no one was grading my work. We had almost no expectations when it came to follow-up with customers or metrics for success. Our One Metric that Matters was really just the number of support calls that we had to get on right after a release. If we could put out a version of our software that didn't completely brick our customers, we were happy.
Even if you are putting out an extremely solid product, if you aren't measuring success by something, then you are just wasting development hours. By placing at least some focus on a solid metric for success, you can accurately measure how you and your team are doing. It also makes feature requirements and grooming decisions so much easier. If you know the most important metric for your organization, you can begin to determine the features or tweaks that will most impact that metric.
One of the best decisions that we have made currently in our organization is to define our One Metric that Matters. While this isn't a permanent decisions by any means, it at least gives us a framework for determining the features that matter right now. With that, I'm able to challenge myself to see whether my decisions as a Product Manager are positively impacting our metric. Did I make the right call on a feature decision? Or did it have little to no impact? These are extremely important things to know.
How I'm trying to improve
I know that I should know better when it comes to each of these items. At this point, I can only look back on past me and shake my head. While I am the most hard on myself, it's important to see and react to signs of these behaviors in others as well. Not that I'm looking to become an unstoppable force of Product Management, but little by little I'm getting better at fixing these problems within my team. Can I control everything? No. But in my next post, I'll be exploring the practical steps that I'm taking to get better at not making hard product decisions even harder.