2023 Goal Setting
What are some goals a product manager should consider when planning for the new year?
I believe in investing time at the end of a year to reflect on the previous 12 months. Let’s call it the “Annual Life Retro.” Whether you reflect on your personal or professional life, you should determine what you did that was successful, where you fell short, and what you hope to achieve in the coming year. This list will evolve with other near or long-term goals, but looking back and seeing progress is an important reminder that you are growing and changing as a person and product manager.
As we are transitioning into the new year, here are three ideas I would like you to keep in mind as you’re shaping the evolution of your career and your product(s) to set yourself, your dev teams, and ultimately your users up for success in 2023.
Make a plan to measure everything.
As product managers, we constantly discuss with our product teams and company leadership where we want to take our product. We are consistently bombarded with new ideas and must factor in these and our thoughts; everything comes together in our prioritization and road-mapping exercises. It’s exciting, frustrating, and stressful, but for many of us, this is what we live for as product managers.
When looking at any of the problems to be solved, one of the essential ideas to remember is how you plan to answer the question - “How will I know if this change is successful?”
In many companies, data quality and access can be difficult. However, suppose we create work items where we don’t understand whether the work is successful after implementation. In that case, we start to develop or continue a culture of gut feeling where the only understood success from a data perspective is whether you shipped an enhancement and are left with a limited understanding of your impact on the company and your customers. When possible, every work item you create should include your idea of how you will measure the data you have before you put it in front of the dev team, as supporting work to tell the story may need to be backed into the effort.
Suppose you do suffer from the challenge of insufficient or inaccessible data. In that case, I recommend assessing the data you have at hand and consider prioritizing work that will help create the information you need to help tell the story of the product. If you are hearing from stakeholders to build XYZ enhancement and show them how successful past recommendations were, and you can show why your ideas should be pursued first, you will come across as a more trusted advisor. Additionally, you will be able to make better decisions on prioritizing your backlog once you visualize each work item against each other, with more accurate value-centric data being considered.
Create a culture of iterations…when you can.
Whenever we write up a new feature or epic as product managers, we want to hit the proverbial home run where we create a fantastic experience for our users while simultaneously improving the bottom line or some key metric for our company. However, as you begin shipping changes to your users, you realize the difference may not have the desired impact you had hoped for, which can be a bummer for all parties.
Although we don’t always have the option to take the skateboard approach to product development highlighted here by Byrne Reese, I believe in laying out your desired changes in a way that builds on an interactive process where you have a clear end state in mind. I see this approach as baking in time or expecting that once you start collecting findings post-launch - business data, user feedback - you can decide whether to change your strategy on what is next. Whether that means killing the future work ultimately, staying the course, or modifying to adjust for feedback, you are ensuring that the enhancements to your original plan factor in everything needed to give your plan the best possible chance of success.
Devote dev team bandwidth to improving the tech stack.
Many of us have had conversations when grooming our backlog with our development team, where we discuss those pesky infrastructure updates that have been kicked down the road to be done at some point. We have also had subsequent conversations where we are told, “The company will not be able to do business if we don’t do this upgrade we’ve been talking about for three months, and we need to do it by tomorrow.”
My question to you, if you have experienced this, is - When we control the keys to the work that is happening, why would we knowingly put our users and company at risk?
As much as we want to press the gas pedal and deliver all of the great ideas we have to market, I would recommend having deep conversations with your dev team to identify which parts of the tech stack need upgrades and factor the changes into their bandwidth and your prioritization. Please discuss with your team, remember when the changes are required, and slot them in accordingly. Sometimes we need to move slower on the fun stuff to avoid all the pain and fall out.
Want to discuss the article above more? Click to leave a comment below. Let’s go!
Follow Product Party on Twitter