Six Lessons From My First Six Months as a Product Manager
Two things happened late last year. The first was that a relatively new CTO at my company began nudging the development process more firmly toward agile, and trying to build up a product focus; the second was that I realized my job, doing various operational and occasionally strategic work on the same team and product I’d been on for nine years, had gotten pretty stagnant. I still loved the product, and of course I hadn’t been doing the same work for that whole time (nine years ago I was entry-level, for one thing), but I felt like I’d hit a wall and was no longer being challenged, and my skills weren’t really being used.
These two things came together late in the year, and I was offered a new job as the product manager for that same project I already loved. The change became official in January. I brought to the role nearly a decade of expertise in said product, plus great communication skills and general enthusiasm. I did not bring to the role any knowledge of agile or scrum methodologies, or really, a terribly clear sense of what the PM role entailed. I kind of leapt before I looked.
Needless to say, I’ve done a whole lot of learning in the last six months. Here are six lessons that other beginning PMs might find useful.
1. Your company isn’t perfectly agile. That’s okay.
A few months ago, I got to go to an official product ownership training for a few days, and I learned a ton about the job I’d jumped into — including best practices all around. What I realized was that, while my company is getting there, we certainly don’t have all of those best practices in place. And frankly, not all best practices would suit our company.
Methodologies and recommended processes are basically like any other advice you might run into. They might be time tested, and might work for the overwhelming majority of cases…but nothing is universal. Take what works for you and your company, and don’t bother with pieces that don’t. You should experiment with recommendations — figuring out your process is a process in and of itself — but the goal is to find what you need to make your company and your team work most efficiently.
2. Define success in a way that’s actually achievable.
For this, I’m not really talking about “success” as “does the product meet its goals?”. I’m talking about a personal level.
I am, and always have been, a bit of an overachiever. I was definitely the kid in college who never needed extensions on my papers (I loooooove deadlines). But the thing about the PM role is that, while the buck may stop with you in a lot of ways, you’re not a developer, or a salesperson, or even anyone’s manager. You can persuade and prioritize, but at the end of the day, there’s a lot you can’t control. And that means that success or failure may be entirely out of your hands.
Letting go of control is really hard for some of us. (Me. It’s hard for me.) So instead of defining your personal sense of success as “everything always gets done on time, under budget, and all the stakeholders are thrilled” — lots of things you can’t control — try aiming for something like “transparency with stakeholders about priorities and any changes that will impact them.” Because that’s in your control, not setting you up for failure.
3. Tasks are easy, strategy is hard.
When I leapt into this role, the first things I learned were the day-to-day tasks. Writing user stories, maintaining a burndown chart, sending status updates when needed. And yes — that stuff does all need to be done, by you.
But learning additional layers on the job — figuring out what process is lacking and what’s needed; learning to prioritize; looking toward the future of the product and making sure everyone is sharing a vision — that takes longer. Especially if you’re someone who comes from a process- and problem solving-oriented background. (Me again, still talking about me…) Learning how to think bigger and work at a strategic level may take awhile.
That’s okay — all new jobs have learning curves. But you need to get there eventually. (I’m still working on it.)
4. Communication is your job.
Both “your job,” as in, “falls to you, personally,” but also “is the main thing your job revolves around.” As the PM, you’re going to have to be aware of all different aspects of your product — the high-level vision, the business team, the users, the developers, etc. When someone has a question, you may not have the answer…but you’d best know who can answer and get the asker pointed in the right direction.
That means you need to be able to communicate in all directions. To translate developer jargon into something business folks can understand; to translate user questions and concerns for the developers. (They’re called “user stories” for a reason…) There are a lot of different departments, and they all use different terminologies that people who aren’t within that speciality may not understand. Look — you don’t need to learn to code, but you need to be able to follow what the dev team is talking about. You aren’t going to write sales contracts, but you need to understand what’s being sold. And you need to be able to facilitate the communication between all of those different departments.
You also need to be communicating regularly, so everyone is on the same page, and everyone’s expectations are set correctly. For example, stakeholders are going to get antsy if they don’t hear back on any of their requests — even if those requests are actually already in progress.
Your mileage may vary, but I’ve found that a quick, “Thanks, I’ll let you know when I’ve got an answer for this,” goes a long way (and then make sure you actually follow up!). I could continue at length — like I said, communication is my main skill — but the upshot is that people appreciate knowing what’s going on, and you’re the one responsible for telling them.
5. You have to be able to say no and deliver bad news.
I will be honest: I’m really conflict-averse. I’ve improved on that front with age and experience, but one of my biggest anxieties about stepping into the PM role was knowing that at some point, I’d have to be the badguy.
Well… “badguy.” It’s true, it sucks to tell stakeholders that something is delayed… but how often is it genuinely a crisis? It can feel like it, especially to the stakeholder who’s getting bad news, but you’re not a supervillain out to ruin anyone’s day. You’re the one who knows the most about conflicting priorities and deadlines and resources, so when you’ve got to say no or deliver bad news, it’s because you don’t have any other options.
It’s not easy. No one likes doing it, and no one likes hearing it, either. But you’re a human being with only so much capacity, and so is everyone you work with. Eventually that will be filled up, and something will have to give — a deadline, a priority, a budget item. You’re the one who will best understand from a bird’s-eye perspective, so making those calls will often fall to you. But once you have a bit of practice at it, it does actually get easier.
6. Everyone is on the same team.
Which brings me to this: when you’ve got to pick and choose priorities and deliver bad news, it can feel like you’re disappointing people. When you know what competing interests come from different departments, it can feel like there are rivalries and you’re picking sides. And sometimes it feels a lot like your job is to defend your own team, your own interests.
So it’s important, when you feel that mindset closing in, to take a breath and step back. Return to that bird’s eye view. Everyone is at the same company. Everyone wants the product to succeed. Everyone wants to satisfy users and clients.
It’s not that teams are competing, leading to winners and losers. You’re not a referee. You’re the coach who sees the whole field, and is trying to get all the right pieces into place. Because in the end, you’re all on the same team, and you’re all winning together.
By day, Becky Allen is a product manager at Remedy Health Media. By evening, she writes YA fantasy novels. In between, she drinks too much coffee and tweets a lot.
