The Seven-Year Sprint: Keeping Pace in the Product Management Race
Seven lessons I learned directing products and people
Hey there!
Today is a special day for me because I'm celebrating my third year in my current job as Director of Product. Before this role, I worked in product for four years, and before that, I frequently created apps and websites for fun. It's been an incredible journey!
At one point, I didn't even know that product management was a thing. I used to think of careers such as teaching, medicine, law, accounting, psychology, programming, and entrepreneurship. I spoke with many people and did a lot of research before deciding on this career path.
I knew what I wanted: to create innovative technology while being part of the decision-making process, and to use both my analytical and creative skills every day at work. Additionally, I wanted to help people. Through my life experiences, I have learned that there are many ways to accomplish this goal, from creating helpful products to being a supportive team member to giving back to your community.
Now, I'm grateful and fulfilled in my role as Director of Product. I'm so happy to be doing what I love every day!
In the past, I read a lot of articles written by product leaders about their experiences in the field. This was my way of learning about the job and how to excel at it. It really helped! I wanted to give back.. sooo…
If you're interested in becoming a product manager or simply want to learn more about the role, this post is for you. I'll be sharing seven (or eight) lessons I learned while working in the field.
(And for everyone else, it might be worth reading to find out what I do every single weekday besides walking in the park and taking photos of the park. After all, retirement is still many years away and you might have to talk to me during this time...)
Seven lessons I learned working as a product manager:
(and tips to grow your career)
A product manager is responsible for guiding a product's journey from concept to market and beyond. They balance business, technology, and user experience to create products that meet customer needs and drive company profits. Their role involves understanding market trends, setting product strategy, prioritizing features, and working with teams like engineering, design, marketing, and sales. Through their keen insight and strategic decision-making, they help shape a product's direction, ensuring it not only reaches the market but thrives within it.
You are your own teacher and student
Product management jobs have a lot of day to day tasks.
You might be talking to the engineering team about tickets. You might be interviewing users. You might be writing documentation. If you are on Slack, you will definitely be responding to Slack messages. If you are in person, good luck having quiet time without scheduling it in the calendar.
Because of all the tasks, you can get stuck doing “just the job” (gasp) and not make time for learning new technology / skills.
I recommend scheduling “reading time” on your calendar. You can call what you want. But it is your time to teach yourself some stuff!
read documentation/blogs of any tech partners
read what your clients are talking about online - twitter, threads, facebook groups, whatever
read what other product people are talking about
take classes if you can! especially if you have a learning budget
Hear everyone out and ask a lot of follow up questions!
A significant part of this job involves actively listening to people's requests.
If you don’t like to listen to people’s opinions and needs, this is not the job for you.
You might be listening to the stakeholders, engineers, users, merchants, client-facing team members, your own brain, the robots, and more.
When someone gives you a request, don't just nod and write it down. Instead, ask a lot of questions.
The "5 Why's" technique can be useful.
For example, ask "Why do you want this?" and follow up with "And why is that?" and continue the questioning process to understand the underlying reasons behind the request.
Start by imagining a resource-rich roadmap:
Once you've listened to someone's request and understand why it's important to them, imagine it as something that needs to be done.
Play a mental exercise where you convince yourself that this request is of utmost importance. This helps you empathize with the requester and actively listen to them.
Only after you fully understand why it's important, make decisions about timing based on the resources at hand and other requests.
Frameworks, such as my RITES/E framework, can assist with prioritization. However, they are only helpful if they are not used against the team.
You cannot use a framework as the sole basis to overrule people's opinions or feelings. Simply saying "look, this number is higher!" will not work repeatedly as an argument. They’ll just tell you to change your framework.
To build trust, you need to demonstrate that you know when to use a framework and when to be flexible.
You must ensure that the team trusts your intuition and reasoning.
How can you do this? By conducting research and telling compelling stories based on your findings!
Test the product yourself as much as possible.
You will rarely regret doing a manual test of the product an extra time.
You will rarely regret looking into an issue yourself in order to understand it better.
This might seem obvious but I have seen smart people be fired because they haven’t thoroughly tested their own product features.
They relied on other people too much. This looks bad because people who really care are obsessed and test features!
The most important time to test is during the QA process. The second most important time is when it is just released. I always keep very close eye on features during launch week/month.
Assume a bug is a bug until it is proven otherwise.
This principle differs from our legal system, but it is relevant in software development because software bugs do not have feelings.
I have seen people be fired for not doing this…
If multiple team members report a high-priority bug, it is likely that a significant number of clients are experiencing the same issue.
Do not dismiss their concerns as an edge case until you have exhausted all possible testing methods.
If you believe the issue is an edge case and your team disagrees, there may be a miscommunication regarding the goals and use-cases of the product.
To determine whether something is truly a bug, track the number of people experiencing or discussing the issue. Use analytics to support your case rather than relying solely on personal opinions. Don’t make it personal!
Recognize and ride the energy waves
I wrote a whole article about this, but here's a summary: sometimes there is a lot of energy for people to work on a certain feature, and less on another.
This could be because something is a hot topic or it interests the team internally more.
It's much slower and harder to work on a feature that people aren't enthusiastic about.
As a project manager, it's your job to sell the goal of the feature and to increase energy levels as much as possible. However, it's also important to listen to the team's energy levels, because they can accomplish much more quickly if they work on what they're excited about. They will eventually work on everything else. If planned wisely, there could be time for it all!
Bonus tip: Record everything, especially what happened during tough moments.
You will need evidence of your successes to keep moving forward in your role.
When things go wrong at work (and they will from time to time), record how you helped make the situation better!
Often, you will shine when you help everyone during difficult times.
Stay positive, respectful, and work extra hard when the team needs you. They will remember your personality most of all. People promote who they are rooting for.
To be honest, the lessons above can be applied to many types of jobs and life situations. Listening, learning, and maintaining a pleasant disposition are always important!
My seven-year career has been quite dynamic, and I have big goals for the future. To manage my tasks and goals effectively, I break them down into one-week to one-month increments, using a similar approach to sprints in project management.
Moving forward, I hope to continue growing as the Director of Product.
However, I am also curious about the possibility of advancing to the role of Chief Product Officer.
If you have any questions about becoming a product manager or growing in this career, please feel free to comment here or reach out to me privately!
Meanwhile, my work-anniversary twin and I are celebrating our three-year milestone. Project: 3 years.
State: completed! ✅
Having worked with you makes my brain retrieve "ladder to success" images for depicting "Assume a bug is a bug until it is proven otherwise". I think you skipped a key ingredient: Break down complex things into manageable pieces. I witnessed you confronting some complex stuff fearlessly, making your way through it while learning and setting up tools to measure and make decisions at the right time.