How do you drive goals forward when you’re constantly putting out fires?
We’ve all been there, right? You start out your week feeling awesome. You’ve just aligned on the weekly goals and initiatives with your team. Everyone left the stand up feeling like they have direction and know exactly what is expected. Then it happens…
The dreaded Slack message that starts with #SOS.
Ah crap…
Any direction you thought you had, is now out the window as you work with Customer Success, Support teams and your engineers to figure out how to solve the problem at hand. You finally solve it, when there is another customer request coming in for something that is “Urgent”. Then you get a call from Sales that there is a “High Priority” prospect that NEEDS something before they will sign their contract, so… can we deliver that thing in the next release?
And can we have a hotfix for that SOS item that started this whole thing?
And…
And…
And…
How are you supposed to make any progress on your weekly goals when you’re constantly putting out fire after fire? How do you improve the product for the customer when you’re stuck listening to the squeakiest wheel all the time?
I’m here to share my approach to bringing organization and direction to a scattershot approach to a product roadmap. Given my experience working at plenty of organizations experiencing chaotic product development, I promise you - it does not have to stay chaotic forever. Let’s dive into the steps I’ve used to bring Calm to Chaos.
Slow Down
Organize your backlog
Find common themes
Extrapolate those themes to goals/visions
Start saying No
Deliver, Deliver, Deliver
Slow Down
It’s really difficult when your hair is on fire to think about anything else. However, it’s more important than ever to take a deep breath and really bring calm into the chaos for a moment in those situations. We can’t see the whole picture if we’re constantly crawling on our hands and knees to avoid smoke. This will be the hardest part of the entire process, but I promise you, it’s also the most important. It’s going to feel strange at first, but it’ll become your new normal in no time.
In order to slow down, first you must focus on creating additional layers of folks that can check on things before you, the Product Manager. This means working with your support teams to set expectations around who should be handling issues before they turn into fires. Setting up SLA’s that all teams can agree to and ensure that there are ways to meet these SLA’s regularly.
This also means we need to set expectations with Sales and CS around what constitutes something that needs to be delivered quickly. This will always be organization specific, as each product has its own market expectations, contracts and ultimately competitive edge.These conversations, however, are all about the same. They should start with an understanding that you, as the PM, want nothing more than for your customers to be the biggest fan of your product, but set the stage that this isn’t possible when those teams are asking to build every requested feature every other day. There has to be alignment here before we can move on.
These two areas can take time. Or, if you’re in some of the start ups that I’ve been in, they take days because in start up culture, a day is a month in the eyes of the CEO (eye roll).
Once you’ve been able to set up some space for yourself…
Organize Your Backlog
I’ll be the first to admit that I am prone to a messy backlog. Who has the time to spend organizing 500 seemingly disparate items one by one? All while you’re putting out so many fires, you can’t even think straight? (this is why slowing down is the first step) ;)
The importance of organizing your backlog is so you can truly see it. When it looks like a garbage can and there are no themes, direction or sense to be made from the tickets or stories, how can you prioritize anything effectively? For those of you new to this process, I have a general method that my friend Rachael Barlevav uses and I find it to be simple and straightforward. No single method is going to work for everyone, but find the one that seems to be the best for you and your team and stick with it for at least a month before adjusting.
Sort everything in the backlog first by type* of ticket
Feature Stories
Stories (small features)
Improvements
Technical Debt
Bugs
Within each of these buckets, try your best to prioritize what you think is highest/lowest and organize them in this way- gut instinct is fine at this stage.
Put the items you need to prioritize for your next iteration at the top so they are easy to find
Alternatives sorting methods:
Type of tickets
Largest to Smallest features
Organize by Date Requested or Created
The reason I find the above organization method most useful is because it forces you to be critical about what type of ticket you’re working with. It also provides a basic framework for you to slot other items into your backlog relatively simply as you continue to add to your backlog.
Find Common Themes
Now that you have your backlog in an organized state, we can begin with finding themes. This piece of the process will take your product knowledge to complete. You must have a good understanding of your product, customers and prospects in order to think critically about the themes you might apply to each item in your backlog. Here are some examples to get your juices flowing:
There are lots of different bugs you’re seeing that happen when a user is trying to login and enter their password. They are all slightly different, but you notice a theme that maybe your login experience isn’t as optimized as it could be. I would consider a theme of “Login Optimization” to apply to those bugs.
There are lots of enhancement requests to your translations module- either it’s not translating properly, or you notice there are enhancement requests for things you already know are in your product- This would lead me to believe that there is a theme of “Translation Enhancements” that needs to be applied to those items.
You notice that a lot of the feature requests coming in are related to larger customers using your product. Maybe this would lead me to a theme of “Enterprise Support” or “Scalability”
Any way you decide to create themes for your work is fine. Just be sure you are able to keep track and sort by all of these items in one view. This may mean creating a special filter or saved search that allows you to keep track of all these items as you move forward. Maybe applying a label to these items if you’re using Jira might be the best way. Whatever method you use, just ensure it’s the same for all items you’re finding a theme for.
Some notes (mostly on bugs):
Themes do not need to be attached to every single item. Most bugs, for example, may not have a theme, but if they do, apply it.
Not all items in your backlog will be able to apply themes to. This is OK! This doesn’t mean anything, it just means that the items without a theme, are one-offs. Generally I’ve found that once you start trying to look for commonality, there are fewer and fewer items that truly DO NOT have a theme.
Save your bugs for last, these can be the most difficult and ultimately the least important to categorize (as long as you’re able to make progress on bugs consistently)
Extrapolate those themes to goals/visions
This next part is the place where a lot of folks get stuck. I’ve seen plenty of folks feel comfortable with setting up themes for their backlog, but fall short when asked to determine the goals or vision for these themes. It takes a Product Manager to step back and look holistically at not just your product, but the ecosystem your product lives in, the potential market for your product, the wants from your customers. This step takes time to reflect. Be sure you really dig into what you’ve been asked to accomplish in your product. Tap into the memories you have from side conversations you’ve had with Sales or customers or even your CEO.
Keep in mind that this article is written for folks who have little guidance on their product roadmap from their superiors. If you do happen to have any strategic vision or goals set forth by your leadership team- this is where you would apply those goals to the themes you’ve already determined.
Here is an example of some themes that I’ve used to extrapolate the strategic goals/visions
Themes
Scalability- Higher volume of users, both at one time as well as over time
Stability- Issues with basic usability or bugs during primary functions of your product
Translations- improvements to the translation functions of your product
Customer Confusion- Issues related to features you have, but folks can’t find, or features that aren’t intuitive to customers
Asset Management- Need for users to find their assets within your product, but they aren’t able to accomplish their primary need
Integration- Users are needing integration with other platforms to be successful with your product OR maybe you think about building that other platforms’ functionality into your product
Reports Improvements- The reports you provide your customers in-app are not meeting their needs
Here is how I would categorize these themes in to a Goal or Vision for a product that was events based:
Ensure primary user flows are stable and do not result in stability issues with over 100k concurrent users during any given hour long event globally.
This goal would encompass the following themes:
Scalability
Stability
Translations
Improve primary user flows to ensure there are never more than 3-5 clicks before a user is able to accomplish their goal.
Customer Confusion
Asset Management
Optimize current features to ensure they meet customer needs to reduce support and enhancement requests for existing features by 50%
Integration
Reports Improvements
Each of the three goals/visions is a quantitative goal that gives your teams the focus and structure to dig into your product and find additional ways to meet the goal. By providing your teams with a vision and goal, it also sets you up to accomplish the next step in this process…
Start Saying NO!
I said before that the previous step was hard, but that’s only partially true. This is the step that is the absolute hardest for any Product Manager to do. Saying “No” is hard. I will not sugar coat that. However, I will say that by having these themes goals and visions laid out in front of you, it can make the short term decision of yes or no, mighty easy.
Using the above examples, if a sales person came to you and said that we should build an alternative view for your main screen navigation from left side to top of the screen, it is a pretty easy decision to say, “Our focus right now is ensuring that our primary customer flows are stable and result in stability with over 100k users concurrently. Once we accomplish this goal we can consider your request at a later date.” This is the least intensive way of saying No. Think of it like a mom saying “maybe” or “someday”.
However, as a dedicated product person, I would seriously recommend you become comfortable saying “No” in a very real way. Using the same example as above, here is another way to phrase this: “We have three primary goals over the next three quarters (assuming each of these goals will take about a quarter to complete). This feature doesn’t meet any of these strategic goals.”
It’s important that as the Product Manager of your product, you always have a handle on what the goals are and what you're working toward. Creating these goals and being able to say NO, will go a long way to saving you heartache later on.
Deliver. Deliver. Deliver.
As soon as you determine your strategic goals for your product and you’ve gotten comfortable saying “No”, now is the time to DELIVER. It’s crucially important that once you have goals, you begin to see every request that comes through your backlog through the lens of Theme>Goal. This will help to ensure that you are listening to your customers and keeping a keen eye on what is being asked of your product as a whole.
Keep in mind, too, that the purpose of this article is to help folks that don't have a ton of guidance on their strategic visions; companies that are slowly but surely becoming feature factories. The sooner you can begin building toward these goals and assigning tech debt and bugs to these goals as well, the sooner you’ll be able to prove your POV to leadership and Sales. The sooner you will begin to bring Calm to the Chaos of your former ‘fire fighting’ mentality
_____________________________
I have been here many times and I know that by reading this article, you may be feeling like I’m simplifying a highly complex issue. However, I do want you to know that I have lived in your shoes many, many times and it really does all come down to these simple steps. There may be more convincing you need to do in order to gain trust with your leadership team or perhaps more knowledge you need to build with your engineering team before you can identify tech debt that meets the themes you’ve identified. But all in all, I believe that there is always calm you can bring to the chaos of product management, no matter how large or small your organization.
*There are references in this article to common Agile methods from my experience using Atlassian products. If you use another software, feel free to switch the terminology to whatever works for you and your team.
Comentarios