Guest Post by: George Steiner (Mentee, Session 10, The Product Mentor) [Paired with Mentor, Chris Butler]
Driving alignment is one of the most important aspects of a Product Manager’s job. Without a strong Product Manager, team’s can struggle to make decisions, or certain parties can feel disenfranchised. Some aspects for driving alignment are relatively consistent across companies and teams: make sure voices are heard, treat colleagues with respect, use data when possible, etc. – but some things can vary widely. If you’re a great PM, you can’t have a set way of doing things, one recipe for success, but rather you must know how to adapt – like a liquid in a container. There are three main aspects of driving alignment that I’ve seen vary a lot across companies and teams: how you document decisions, direction vs autonomy, and communication styles.
Documenting Decisions
When I started working at a larger company, I remember the first time someone said I should write a strategy document for this new project I had started talking about. I was too embarrassed to tell them that I wasn’t even sure what that they meant. I thought: “A strategy document? What was that? Why would I waste time writing one of those?” However, as any good product manager would do, I phrased my ignorance as curiosity. “So what do you think is important to include in that?” – as if to try and come across as wanting their input. But really, I just had never written a formal strategy document before.
Did this mean I was a bad PM? I had several years of experience, had I been doing it wrong? Maybe, but I don’t think so. I had gotten great reviews at my last job, I thought I was a pretty good PM. Rather, this encounter was introducing me to how documenting decisions can vary widely across teams/companies. From what I’ve observed, it tends to vary along the axis of “how much things are written down.”
In my experience, it’s much more important to document things, especially around strategy, at larger companies. At first glance if you’ve come from a place that doesn’t document much (likely a startup), this can seem inefficient. I worked at a series A startup for two years and I could count the “strategy documents” I wrote on one hand. Now at a large company, it seems like I’m writing a new one every week.
But at a larger company it’s actually more efficient to write it down, because more people need to have visibility on it. Herding all of those cats in one or two meetings can be impossible in a large organization. At a startup, it’s easy to have a quick meeting with the three people impacted, make the decision, and get back to work. Neither approach is right or wrong, they just serve different customer types with different needs, like different products.
So how do you know how much to document things? Well, you’ll almost certainly have to adjust as you go, but I think it’s safe to air on the side of less documentation, and add things as needed, that way you minimize your waist. You’ll know more documentation is needed because either a) people will ask explicitly for them or b) you’re having to repeat yourself verbally too much or c) people are not on the same page.
What to document usually falls into several buckets: plans, execution, and references. Almost all teams need documentation on execution. Plans and references tend to happen more at larger companies than startups.
Direction vs Autonomy
It’s one thing to drive alignment on a key strategy decision (and perhaps document it), but there will always be a hundred smaller decisions that have to be made to organize and actually ship any product. And with this comes a conundrum for every Product Manager – how hands on should you be with your team? Nobody likes a micromanager but at the same time you are responsible to make sure the plan gets executed and things are always moving forward.
At a small startup, I quickly realized that the engineering team really needed my support to get organized. So I gladly dove into the project management aspects of the job. I set us up on Asana. I created and managed all of our tickets / user stories. We reviewed the Kanban board every week as a team. Etc etc. As a new team, they just needed some basic organization to help everyone stay aligned.
When I joined a large company, I thought I’d be doing the same thing. I even assumed that they had a really good process for all of the project management activities that I could follow. It turned out there was not a lot of formal processes, and what little process there was had been driven heavily by the engineers, not the PMs.
This took a lot of adjustment for me. Anyone who knows me will tell you that I like to have things neatly organized, my way, following my system. But I had to adapt and do what is best for the team. At this much larger company they believed strongly in giving engineer’s autonomy, it was a core part of the culture. Gradually, I became comfortable not writing all of the bug tickets and tracking them to completion. Sure, at first it made me anxious, but eventually it was freeing. I could spend more of my time driving our strategy. Well, sort of.
After I pulled back a bit some projects didn’t get done on time / properly. I then realized I still had to be more hands on with some members of the team, on certain projects. A good explanation of why is from one of my favorite books, High Output Management, by Andy Grove.
Andy talks about something called task relevant maturity, which says depending on how much experience a particular person has with a particular task, you should give the necessary guidance. It’s a good reminder to you that it’s about their experience with this task, not general experience. If you have a Michelin star chef, you don’t need to give much guidance if they’re working at a restaurant – but if they were training students in karate, they probably need a lot more help. While Andy’s framework was intended for managers with direct reports, it also applies well for product management, since you frequently find yourself in this position with a cross functional team. In fact, how you document decisions could benefit from a similar thoughtfulness in carefully considering your audience.
If you’re not sure how much oversight someone/something needs, try being hands off for a bit and see how they (or the project) progresses. Air on the side of autonomy, because a) it’s easier for you and b) giving too much direction to the wrong people can really rub them the wrong way.
Communication style
When I started my new job at a large tech company in California, I got some tough feedback early on. I was told that I was being too direct, too confrontational, especially with the engineers. Basically saying too much “that idea is bad and here’s why” and not enough “hmm interesting, why did you decide to do it that way?” I ended up laying off a bit (and suffering some short term losses with what I considered to be poor decision making) in the hope that building my relationship with the team would reap long term gains. It did. Sometimes you may have to make those sort of tradeoffs between confrontation and team building.
When I worked at a small startup in NYC, that sort of directness was par for the course. At first I thought it might be a California versus New York City thing, or small versus large company thing. But after hearing from a friend how unbelievably direct people are at Netflix (aka a large company in California), I’m now convinced there’s no specific criteria and it just varies randomly across companies and teams (at least within the USA, where all my experience has been).
Being direct always sounds better, likely because as a society we generally believe in honesty. But similarly to how you’d tell a white lie not to hurt a friend’s feelings, the same emotions can play a role in the workplace. That’s why this is certainly the trickiest of the three topics, and the one I will easily admit I have the least figured out. The only advice I can give confidently is simply be very aware of how you interact and do your best to adapt to the company’s norms. Pretend as if you were writing a book on your company’s culture, and carefully observe how other employees interact. You can use that as a starting point for yourself. At Netflix, no one would bat an eye if you walked into a meeting and said “that’s the stupidest idea I’ve ever heard” (and in fact, they expect it). I honestly have trouble even imagining that happening at my company.
Closing thoughts
PMs usually love frameworks. Follow step A, B, and C – then depending on C, do X or Y. They help us break down very complex problems into bite size pieces. It should be no surprise that when I’d interview PMs, I’d ask them to calculate how many windows were in Montana (ie. how well can they break down a complex problem).
In this article I tried to break down driving alignment into something at least approaching a framework. I believe there are at least three main pillars you’ll need to properly calibrate on: documentation, autonomy, and communication style. I would invite you to observe how your organization makes decisions. Do you agree with these three pillars? Are there others I am missing? Has your experience with any of them been similar? Different? The “soft skills” of product management are almost definitely the hardest, but they’re also the most interesting, because whenever you think you have it figured out, something will remind you that we’re all still learning.
George has been working in product management for over eight years. He’s worked at companies of all sizes, ranging from a two person startup to a tech giant, and everything in between. In his spare time you can find George hiking, biking, or sailing.
More About The Product Mentor
The Product Mentor is a program designed to pair Product Management Mentors and Mentees around the World, across all industries, from start-up to enterprise, guided by the fundamental goals…
Better Decisions. Better Products. Better Product People.
Each Session of the program runs for 6 months with paired individuals…
- Conducting regular 1-on-1 mentor-mentee chats
- Sharing experiences with the larger Product community
- Participating in live-streamed product management lessons and Q&A
- Mentors and Mentees sharing their product management knowledge with the broader community
Sign up to be a Mentor today & join an elite group of product management leaders!
Check out the Mentors & Enjoy!
Jeremy Horn
The Product Guy
The Product Guy 