Quieten the Squeaky Wheel through Feature Prioritization [Mind the Product]

Prioritization is challenging and stressful. Sometimes it’s because of micro-prioritization such as bug triage and moving one small fix in front of another. Other times it comes from the macro level: deciding to target new user growth versus lifetime value; spending time on user research or analytics; handling your manager’s feature request versus the tech debt the engineers beg for.

And then there’s the squeaky wheel. This can be a person or a topic, but it’s always something where I feel like an all-caps message came through: “THIS IS A BIG DEAL!! FIX IT!” Given that I want to be good at my job, please stakeholders, and solve problems, I’m always tempted to rush to make things right. I tell myself that if I just knock this one out they’ll go away and I can return to my regularly scheduled programming.

This happened to me recently. We’ve been reworking our home page and in the process found the search bar had a bug – a strange loading effect where it flashes gray for a millisecond. The product team decided to ship with this bug and we put it in our backlog to be fixed once we took care of a few other stories. An engineer on another team saw the bug and was concerned about it, starting a conversation on Slack that escalated to the point where I had multiple people messaging me about when we were going to get this fixed.

Nobody likes shipping imperfect products, but at the same time we all know that we can’t hold off to wait for perfection. I had a prioritization challenge in front of me – do I change our backlog and move this story up or stick with the original plan?

Squeaky wheels get more complicated with status. I have been in situations where a C-level executive said, “ee need to build something like THIS!” and laid out feature requirements. However we had a list of features that had already been validated by user research. Do we move this idea up and begin to research it, or go with what we know?

The best way to solve for squeaky wheel syndrome is to have a prioritization process in place ahead of time. A system removes the personal from these conversations and turns it into a conversation about the values you’ve established as a team. Because it’s systematized, there are more consistent inputs and outputs which mean that the emotions anyone is feeling that day are removed from the equation.

So that bug on our home screen? I was able to lay out that our system defines issues in terms of severity. This bug has a certain severity score and should get pulled in next sprint, but we don’t interrupt work in progress for that level. Given that we already had those standards established, I was able to quiet everyone down and get back to work. They were able to trust the system and were glad that I had heard them and had a plan in place.

What about the CEO, however? Can a prioritization process help you through larger feature development and tactics? Yes, if you have a system in place. But the only way your system will work is if your leadership believes in it as much as you do.

Pick a Method, any Method

When it comes to building out a prioritization system, it doesn’t matter which you choose. RICE, Kano, MoSCoW (who came up with that capitalization?), or any of the other ones out there – pick one you like and run with it.

The only thing that really matters is gaining support for your prioritization system. If everyone has agreed on what prioritization model your team is using, they became part of the decision to de-prioritize their idea. And if they still don’t like the outcome and want to be a squeaky wheel?  It shifts the conversation from “Product refuses build my thing” to “The system says that my idea isn’t the most important thing to work on right now”. Any debates become about whether the process is working or not instead of a personal conflict between product and the requestor.

Step 1: Define Goals

We began by talking at a high level about our goals as an organization. All product teams did this at the same time, and we all made sure our executive stakeholders and leadership were in the room. Once we felt like everyone had the same sense of our guiding principles, I asked our stakeholders to list out all the goals for my product team. I said yes to every goal they mentioned. The list was a little long.

So I asked: “What do we do if we have an idea that we think might improve customer satisfaction and retention, but will decrease our margins? Should that win out over an idea that might increase total revenue but could cause more calls to customer support?” Our extended leadership team hadn’t gone into deep discussions about our product KPIs before, so this was a good opportunity to help them learn more about the product process. Once we had a short list of goals in hand, we wrapped up for the day.

Step 2: Customize a Framework

When the team reconvened, it was time to talk about frameworks. We chose a RICE model because it leads to numeric scores for each item on the list and matched well with the objectives we had chosen for the product. We didn’t spend too much time choosing the framework.

We spent a tremendous amount of time customizing the framework. If you use something off the shelf, it’s too easy to say “well, that worked for so-and-so, but it isn’t going to work for us”. You create room for excuses. When you customize the framework to fit your needs, everyone has shared ownership.

We thought about customization in several ways – the first was categories. Instead of Reach, we talked about the number of customers who would see this per month. Impact became two things – reduction in customer support calls and increase in average order value. Our definitions allowed the model to use the language we use when talking about our business.

The second way we customized was with the definitions. Within our framework we defined that a big impact might be so many thousand extra customers taking an action, while a small impact might be defined in a different way. Each category had clearly outlined definitions of small, medium, and large to make sure we were having an objective conversation.

Our final customizations were in how we weighted each category. Instead of everything being equal, we decided to weight growth more heavily than cost savings. This allowed us to make sure we were doing more of the things that would help us succeed long term as a company, without completely ignoring the reality that we can’t just be a company that spends forever.

Step 3: Prioritize Ideas

Only now, once we had talked about goals, chosen a framework, and customized it, did we begin to put ideas into the model. I got to say yes to every idea that came my way, whether I thought it was good for our business or not. We placed them in the model, filled out the framework, and got our scores. A little final tweaking allowed us to make sure everyone felt comfortable with the results.

The prioritization system switched our conversation. No longer was product responsible for prioritizing in a vacuum. The entire company had a voice in prioritization, and the model helped us understand whether we were making good choices or not. Now when someone comes to me with an idea I always get to say “Yes, let’s add it to our model!” and the data helps us say yes or no as a team.

What if someone disagrees anyway? They’re upset because their item is still at the bottom of the list, and that’s understandable. At that point your response can be: “Okay, what do you think needs to be adjusted in the model? Do we need to weight things differently, do we need new categorizations?” It gives us an opportunity to talk about the goals for the product and company overall, and we decide as a team what the best next steps are.

The post Quieten the Squeaky Wheel through Feature Prioritization appeared first on Mind the Product.

Source: Mind the Product http://www.mindtheproduct.com/2019/02/quieten-the-squeaky-wheel-through-feature-prioritization/