To PM or not PM?

This morning one of my kids woke up my wife and I around 430-ish (some of the stuff my wife and I are going through/have been through as a parent of two internationally adopted children is another story for another day) and the first thing that went across my twitter feed was So You’re Hiring a Product Manager? where John Cutler throws out a prioritization challenge.

I’ve been following John religiously on Twitter and Medium for years (I think) — how hard could it be to interview with him? And without having any coffee. Now you might you say, “you aren’t a PM!” That’s true. I consider myself an Engineering Delivery Leader, but I often feel like a PM. Meaning a Product Manager, not Project Manager or Program Manager. And often I’ve had to act as one because some Product Managers don’t have a nuanced enough understanding of infrastructure, software delivery platforms, security, or other non-functional requirements. Somebody’s gotta do it. And I would argue “thinking like a PM” is a critical skill for any engineering leader.

I’ve have been working in Product orgs for the last 6–7 years in this weird place (in the last 4 years) that is the intersection between Operations (running things) Engineering (building things) and the Business (understanding what is valued — or should I say what is valuable) so I feel like I’ve “been there” enough to give it a shot, so here goes. Wish me luck.

I kept vacillating between thinking of “good PMs” I’ve worked with and how I see myself working as “fake PM” in my current role, so this may be a bit schizo. Also, for the last 3–4 years I’ve had Director or VP in my title so that might be skewing my answer one way or the other.

Start with the “External” Why

What immediately bubbled to the top was the customer. Now I’m probably answering this because this seems the right answer. It could even be a cliché, but I’ll stick with it. In my case, my customers have been: “real” customers (meaning paying customers, who I haven’t deal with too much in my current role but did a lot previously), sales teams, and software engineering teams. This is why you exist. This is why your team exists. If you don’t have this foundation, you are screwed. Get this right. Start here.

To build a deep understanding of customer needs and pain-points
To develop a deep understanding of business goals, and then figure out how to leverage design and technology to meet those goals
To field external customer requests, prioritize them according to value and level of effort, and then make sure they are delivered quickly without sacrificing quality
To delight our customers and make sure we are always improving the product experience

Convert to “Internal” Why

Once you have the external bit right, you can take that back to your team. Clear, crisp decision-making (yours, not theirs) immediately bubbled to the top. The “right” statement is a bit tricky, but I’ll leave it on so as not to “overthink” it. Building the right thing at the right time for the right reason is what makes it interesting because it is super hard.

To provide the necessary context to the team so that they can make reasonably good decisions, reasonably quickly
To own the prioritization of the roadmap and backlog
Define the “right things” so that the team can “build them right”
To formulate, test, revise, and communicate a product strategy

Optimize for Delivery of Value

This is where we get into fun stuff. What is the difference between and Engineering leader, a PM, a Scrum Master. How many organizations can’t figure this out? Most, but I’ll put these into the last bucket. This is how you ship. This is how well your team works. This is the how. I’m sure there are some tricky things that should be thrown out here as well..

To hit measurable and specific goals tied to short, medium, and long-term business outcomes
To collect requests from inside the company, put together a roadmap, and make it visible to the rest of the company
To ensure predictable and timely delivery of features and capabilities
To shield their team from requests and interruptions, while managing external stakeholders and keeping everyone in the loop
To troubleshoot and figure out why their team is not delivering more quickly
To maximize the ROI of the team’s efforts

Not Even the Job of a PM

I would argue these various skills are a mix of engineering management or project management (yeah, project/program managers are still needed, so deal with it) or business analyst or architects — or even the damn engineers. So, product really needs to stay out of this bucket. This is the what. Stay in your lane PMs.

To call “bullshit” on team estimates, and basically hold them accountable
To act as the “glue” for a team of talented designers, developers, and [other roles like data science, marketing, etc. ]
To manage projects from definition all the way through to release
To make the final call on design and technical decisions. To make sure the team makes the right technical and design tradeoffs
To manage their product and team as a CEO might manage a startup and team
To translate business requirements into technical requirements

So how did I do?

Let’s see if I can get a few more hours of sleep.