Lessons Learned: Embracing the Challenges of Product Management
I was pulled into the world of product management about two years ago. My professional life as a Martech strategist before that was uneventful and it even allowed me to stop and smell the roses occasionally.
About three years ago, some people in my organization decided to change the overall branding. No small feat, especially when a multitude of digital assets fly around in numerous channels and are published on hundreds of web properties serving those tens of stakeholders in countless ways.
This type of rebranding project can include a brand guide, pdfs, brochures, collateral, website, and email updates for small businesses. On a smaller scale, it’s very manageable by a small team of designers and developers. But things quickly change as organizations get larger. While the details of rebranding and how it can be managed is a separate blog post, the rebranding initiative is why I found myself in the world of product management.
My department, as a stakeholder, has significantly different needs than the rest of the organization, so we are generally treated a little differently. Good? Bad? Who knows?
At that point, my career took a slight turn, from managing an email automation platform to managing an email automation platform and a CRM system, and website development. The simplicity of my daily work life was interrupted overnight to fight the ever-so-hungry many-headed corporate monster from Greek mythology or a Marvel movie.
During the web development and brand transition projects, I came across the product manager and product owner role description and realized this was going to be my career from now on. Our organization needed more tech stack ownership and management for a long time. Our tech platforms needed to be integrated; many siloed departments ran their businesses from Excel sheets even if they had access to a world-class CRM system.
The web development project I was pushed into allowed me to understand the 10+-year-old CRM setup better. Working with developers on both sides, the front and back end of the website was one team, and the CRM developer side was the other. We built a modern shopping cart that was designed to answer business needs.
While I had experience in team, project, and production management, I hadn’t heard of the “product owner” or “product manager” jog title until then. So, I started reading about it, took courses, learned methodologies, listened to podcasts, attended local meet-ups, and joined Slack channels where other professionals discussed their challenges and work.
Product management appealed to me first because it shifted focus from people management. People management is a strange area where managers are responsible for ethically guiding their subordinates to achieve goals. The goals are sometimes wrapped in “career advancement” or similar motivational packages that help it easier for the worker to do their jobs.
In this case, product management is one step removed from people management where the goal is to design, build, and enhance a physical or digital product that generates income, facilitates business operations, and adds value to the organization maintaining the product.
So, during the past 2-3 years I learned, not everything, but a lot. First, successful product management isn’t about people management but more about human relations. It’s not our responsibility as leaders to motivate people to get their work done. However, it’s our responsibility to communicate clear goals, draw roadmaps, and set expectations.
Communication is key.
This has been the key to success in every single project I was involved in. The moment there is silence in a project is the moment things start to go south. No matter who is involved and what they are doing, a periodical communication needs to be enforced to help projects move forward. People and teams get pulled in all directions; communication is what brings them back to focus. It can be as simple as a “Where are we at?” or “How can I help move things forward?” to start a stagnated project moving again. Periodical checkpoints are also important. Depending on team structures it can be established weekly or bi-weekly. Any longer than that is too infrequent to keep a healthy track of things.
Flexibility
Projects can have very rigid terms of scope; this is good and bad. It’s good because teams align on well-defined requirements and work to deliver in a predictable way, and bad because the business needs driving the project can change while the project is in progress. When the latter happens, there was a few ways to manage, a. stay on course and deliver on the agreed scope, b. stop and rescope, or c. while moving forward see what changes can be made without impacting the delivery of the project and what can be scoped as a future delivery. These options should be considered when business needs change mid-project, and the best option is dependent on the nature of the scope change and the project timeline.
Since the business landscape changes happen more often than not, the scopes can grow, and teams can change to adapt. I experienced this a lot during the past 2-3 years. Not only the scope of our projects have changed and evolved. but also, the top-level leadership had a significant turnover in my organization. There was a time when there was no clear leadership structure and when we didn’t know what the next department head would bring on for ideas and requirements. A careful consideration of the state of the organization, and at points with such uncertainty it was important to have an understanding of industry standards to keep moving forward.
Documentation
I can’t stress the value of an implementation enough. I stepped into a 10+-year-old tech stack without any documentation. The learning curve was immense and it took a lot of trial and error to completely map out the integrations, connections, automation, and business rules that layered on top of each other for over a decade. Each tech manager added their own complexities without any future concern. Today we make the best efforts to document every detail for every change we implement in the system in written, audio, and video format so the next manager who is in charge has a reliable knowledgebase to get their work done more efficiently.
With the recent advancements in technology I am also expecting us to add an AI layer to keep track of changes and complexities of the digital connections that run the business.
Roadmaps and expectations
Another very important step. Letting people know where we are headed, what are the organizational priorities. These in turn help the teams align and get organized to achieve different project goals. The roadmaps are usually tied to a lot of whys. Why is this project more important than the next? Why is one project dependent on the other? Why is this project not being worked on asynchronously with the other? These are few questions we need to find answers to when creating a roadmap for the future, These also help us set some expectations and communicate delivery timelines to different teams.
Contact me
Please let me know if I can help you with your product management questions.
