I’ve been a product manager on an engineering team for the past nine months. It’s the latest chapter in a tech career that spans over eight years. Prior to moving into this role, I was a content strategist on a developer advocate team and I had recently completed a Masters degree in User Experience Design. While I spent considerable time observing and learning from developers, it’s one thing to listen to their conversations and another to work alongside them.
Being a PM on an engineering team has been both the most challenging and most rewarding experience of my career. I’ve had to learn about a new domain that I had no prior experience with (experimentation, also known as A/B testing) while learning about our tooling, infrastructure, existing processes and the metrics that we (and our main client, the Marketing team) cares about. There were no guide books. My manager made it clear that there was a huge learning curve.
But I’ve learned and processed information, and I continue to learn and process information. I’ve deepened my understanding of experiment design, business goals, and engineering considerations, and have successfully built systems, processes, and educational components to help the program run smoothly and begin to scale. When I finished grad school last summer, I wondered if I would get the chance to learn as much as I had in class. I didn’t know it then, but life on the engineering team is all about learning.
In this post, I’ll share lessons I’ve learned working as a PM on a scaling program. Some of these were compiled from previously published Twitter threads.
What do I mean by PM?
I work at a company where many non-engineers carry the title “program manager”. It’s, unfortunately, a catch-all that includes some (if not all) of the responsibilities that fall under roles like:
- Product Manager
- Technical Program Manager
- Project Manager
In practice, my role is a blend of product management and technical program management. I run the A/B testing program on one of my company’s largest web properties, and I sit on a cross-functional team that includes an analyst, developer, and a counterpart in marketing. I own the product backlog and the list of features my team will work on next. We use the same KPIs our marketing partners do to determine outcomes and impact of experiments, in addition to a few that we’re currently working on and are unique to our team. I oversee infrastructure projects that impact the A/B testing program, and I also handle the day-to-day project management of building each test like creating and assigning tasks, managing timelines, writing specs, communicating status updates, and more. I build out processes and documentation and educate stakeholders and partners on the program goals, the experimentation practice, and how to work with us.
The lessons I’ve learned here are not exclusive to me or my role. PMs of all shapes (product, program, and project managers) will find that these are applicable to their work in some capacity.
What I’ve Learned
While I've learned more than the 11 items listed (of that I can assure you), these lessons stand out the most:
Creating documentation is an absolute must. Why? I always consider this: If I were starting this job tomorrow, what would I want to know? If someone on the team were leaving in 2 weeks, what would I want them to show me? Technical debt, wasted effort, and onboarding are all things that can be mitigated with better documentation. (I wrote a post about the kinds of internal documentation you should have to start.)
Ideas are infinite but resources and time are finite. An architect can come up with an amazing blueprint for a new structure but the civil engineer determines if it’s feasible to build. While you make the decisions on what the team builds next, you depend on inputs such as data and information from your team to help you make the right calls.
When you roll out a brand new process, know that it'll take time for people to get used to it. Part of that education is also letting people know when they've inadvertently side-stepped the process. Guide them on how to follow it and enforce your process without exception. If you make concessions, no one will follow the process.
...but iterate and improve on processes when the time is right. Give it time for people to get used to the process. But if you’re approached with constructive feedback that will help your stakeholders, make changes as needed. This is also true for iterating no processes as you start to scale,
Use your time wisely. PMing requires extensive conversations with multiple stakeholders. Add blocks of time in between meetings and give each block a name that’s associated with a task: “Write up weekly report” or “Respond to questions in PBIs” for example. This will help you know what to you need to focus on, especially when you’ve spent a lot of time context switching. Insist on receiving objectives and goals when someone sends you a meeting invite, and communicate your working hours and availability to your team and partners.
Talk to PMs on other teams. The PM role can be lonely, especially if you’re not in an organization where you sit with other PMs. I’ve found it incredibly educational to set up time with PMs in other teams who run similar programs to get an understanding of what is working for them. Why reinvent the wheel when you don’t have to?
...and talk to people in other roles to learn more about how their work impacts yours. While I’m not expected to be an expert in infrastructure, data pipelines, and tooling, I am expected to be conversational in these areas and speak to them with confidence when asked by my clients. I like to schedule a meeting or two per month with people from within my team who work in different functions to understand their perspective on a particular topic. For example, we have a growth expert on my team who has a background in statistics and experimentation. He is the kind of person who I’ll reach out to to learn more about a given topic and to get advice. I also have a weekly 1:1 with my analyst and developer colleagues. (Also: whenever you can’t speak to something, bring in the expert to do the talking! It’s better to do that than misrepresent something you don’t understand yet.)
Create templates for everything. Speaking of reinventing the wheel: if you spent a lot of time creating a plan, report, email, or any other type of asset, create a templated version of it that you can copy and turn into a new doc. I have a Word document of email templates for the most common communications I send, a template for project plans, a template for a newsletter, and even an intake form. You never know when you’ll need it and your future self with thank you!
Get all the facts before you make any promises. Working in engineering in the capacity that I do, I know exactly why it’s hard to provide the kinds of hard timelines or precise estimates that business clients need or want (they often operate on hard deadlines). I’ve learned that it’s not good to over promise and under deliver; I’d much rather be slightly conservative in my estimates than to be overly optimistic. There are always unforeseen snags and issues when something is getting built no matter how acquainted you are with the infrastructure.
Once your team is ready to build, move out of their way. Since the very start, I’ve leaned on my developer and analyst teammates to tell me what is feasible and what is not. They are far more knowledgeable about the infrastructure than I am, and know if something isn’t possible. I involve them as early in the ideation process as possible to ensure that the developer perspective is never lost in the conversation. As a PM, I see it as my role to advocate for my team as much as I advocate for the customer and product.
Be patient; education and communication are the name of the game. As the spokesperson for the program, I know more about its various components better than anyone else. Each of my stakeholders and partners knows a part of the whole, and my job is to bring them along with me as the program evolves. This means creating opportunities to educate and ask questions and to facilitate understanding in any way I can. On the flip side, always learn more. Do independent research, reach out to colleagues, and ask as many questions as you can. The more knowledgeable you are the stronger the product (or program) will be.
If you’re interested in PMing, here are some books that have helped me solidify my understanding of the role that I play, the inherent challenges with building products, and the value that great PMs bring to their organization and the evolution of a product:
- Escaping the Build Trap by Melissa Perri
- Inspired by Marty Cagan
- The Professional Product Owner by Don McGreal
- Just Enough Research by Erika Hall (technically a UX book but applicable to any PM)
This post was originally published on my blog.
I'm Stephanie, a Content Strategist and Technical PM. Visit developersguidetocontent.com to learn more about my work!
Latest comments (0)