< back to all resources
Resources
benjamin button, doctor who, and seurat walk into a bar
This is the long way of telling you I had a breakthrough in that moment, sipping coffee together in the window. Product vision is the Benjamin Button of the business world.
Go ahead, laugh. But… it’s just so crazy it might work.
I recently sat down with a former coworker of mine to catch up and talk shop. He’s an engineering leader with a keen interest in product, and we were discussing how to create a product vision that communicates direction yet doesn’t prescribe exactly what to build.
This is a topic I know in my bones, but have historically had trouble finding the words to articulate how to achieve this. Sometimes you learn things that, after awhile, seem obvious… and yet aren’t even remotely obvious to someone who hasn’t done it before.
This is the long way of telling you I had a breakthrough in that moment, sipping coffee together in the window. Product vision is the Benjamin Button of the business world.
Go ahead, laugh. But… it’s just so crazy it might work.
time and detail are inversely correlated
I don’t even want to admit to you how long it took me to figure out how I wanted to draw this. But hey—we got there!
The further in the future your vision depicts, the more detailed, specific, and high quality it can be. As you move closer to that time horizon, the vision becomes fuzzier, less clear, and depicts more of the problems to be solved. At the shortest distance, it may become words instead of images.
Long-term vision
In order to effectively communicate your 5 or even 10-year vision for the product, you’re going to need something a little bit more inspiring than words. You need to literally create images so that your people can see where you’re heading. The beauty of the time horizon being so far out, is that this vision should not impact the product by the time we reach that horizon. You’re not prescribing anything, because no one on your team is staffed to work on this area yet anyway. All you’re doing is demonstrating what could be.
Mid-term vision
You still need some visuals to help communicate a vision that’s 1 or 2 years out, but you’ll want to lower the “quality” of those visuals. In other words, the images will spend more real estate depicting the problems to be solved, and less to what specifically will be implemented. This is where I find it very useful to say “NONE OF WHAT I’M SHOWING YOU WILL BE BUILT! But it’s representative of the types of things we might build to solve these issues.” Also maybe never show this to a sales person…
Short-term vision
You’re a couple months out from starting work on an area, which means your visuals should be of such low quality that they’re actually just... words. At this point you’re not sharing any nods to solutions or interfaces—you’re simply articulating the problems and areas to be prioritized in the coming months.
a vision is never done
The fun thing about product is that it’s a living, evolving, changing thing. What you think it will be in 5-10 years is almost certainly not what it’s going to be, whereas what think it will be in 2 months is going to be a lot closer to the truth. And, as we move forward through time, our 5 year vision becomes our 3 year vision becomes our 1 year vision becomes our next project.
This means your vision is never done.
Think about that for a moment. Your product is constantly changing (hopefully…), your knowledge of your customers and market indicators is constantly changing. That means to some extent your vision is also constantly changing in subtle ways. You may find yourself re-making your long-term product vision every few years, but the mid-term vision is likely shifting once a year. It’s removing things that have already happened, it’s adding things previously nodded to in the long-term vision, and it’s removing specificity.
you are in both the present and the future
And it’s not because you’re either Doctors Strange or Who. As a product manager you will have to learn to flex through time. One minute you may be writing minute stories for a feature you’re implementing in a week, and the next you’ll be mocking up visions for 2 years from now. While to the untrained eye they might seem like completely opposite activities, you should see the trails and traces of threads that connect the two.
You are implementing this feature, because it was a solution to a problem that was presented in the short-term vision. Solving that problem moves the product closer to the “what if” that was painted for the mid-term, which in turn leads to the “someday utopia” presented for the long-term.
case seurat: let’s van gogh with another metaphor
Still not making sense? That’s ok—I’ve got one more metaphor to throw at you. Imagine you’re Cameron Frye, standing in the Art Institute of Chicago, wondering why the worst friend ever, Ferris, is actively destroying your life. You’re staring at a painting. It depicts a scene. Your eyes zoom in. You see a woman’s face. Your eyes keep going. You see nothing but dots.
I’m describing pointillism, an artistic technique in which the artist creates an image from dots of color. It almost certainly describes the saying, “the sum is greater than the whole of its parts.” (Dot matrix printers also come to mind, although that rather dates me.) In addition to all of that, pointillism also the perfectly demonstrates product visions.
At a distance, you can recognize the image. It’s clear, it’s beautiful.
Get a little closer, and you can still make out some detail, but the scope is much smaller.
Even closer? You can’t see the image at all, only the underlying problems.
I also cannot believe how hard I just punned
But hopefully it was worth it for you, if not me. Does this track with how you’ve worked on product visions? Are there any other metaphors I should cover in the future? Let me know in the comments!
the holy tripod
I believe deeply that every product engineering team should have a tripod at its helm. Hopefully, by the end of this blog post, you’ll agree with me.
tl;dr
At a minimum, a Lead PM, a Lead Designer, and a Lead Engineer should form a tripod that leads the product engineering team
The tripod should meet to establish agreed-upon responsibilities and communication patterns, starting from the generally accepted roles
No member of the tripod has the final say on everything, they’re like 3 co-equal branches of product government
Product is a team sport of solving a Rubik’s cube—you can’t change the constraints, so use prioritization and negotiate with one another in a collaborative manner.
Holy Tripod, Batman!
I couldn’t resist. But in all seriousness, the product tripod is a staple in my product belief system (PBS). I believe deeply that every product engineering team should have a tripod at its helm. Hopefully, by the end of this blog post, you’ll agree with me. Although why you wouldn’t just blindly follow me I’ll never understand. 🤷🏻♀️
Introducing: The Tripod
What are the key roles?
Product Manager / Lead PM
Product Designer / Lead Designer
Engineering Manager / Team Lead
Why is it so important?
Successful products aren’t typically created from a single person’s mind, but rather through the art of collaboration between a diverse group of people. Even if your organization isn’t super, ahem, diverse (we’ll address that in a different post—I have thoughts y’all), you can achieve a degree of diversity of thought simply by ensuring these three roles are collectively leading the team.
Tripod+
Sometimes a product eng team tripod has even more legs than three (I’ve been known to call it a fivepod) if you’re one of the lucky teams to have access to one (or all) of these roles:
Data Scientist
User Researcher
Program Manager
QA Lead
It’s fairly common for these roles to either be non-existent in smaller companies, or to be shared among several product engineering teams. Depending on the demands on that person, you may find them being just as involved as the core tripod members, or you may need to prioritize the most important meetings and interactions.
The Tripod and Other Metaphors
Why do we call it a tripod?
What happens when you remove one leg of a tripod? Barring some sort of shenanigans, typically a tripod that becomes a bipod is a… laying-on-its-side-pod. A tripod cannot stand if any of its legs are out of commision. Such is the physics of a product engineering team. It requires a complete tripod to stand on its own three feet and perform to its full potential.
Is it a dictatorship, oligarchy, or democracy? (Dictatorship, right? The PM is clearly the dictator, right?)
Nope.
The tripod is both none of these and all of these. It both listens to / represents its people, but it is not a majority rule system.. It is both ruled by a group of people and gives individuals the power to make final decisions.
If you are working with a PM who’s acting like a dictator, they’re doing it wrong. Please refer them to me. If you are a PM and you’re acting like a dictator, please stop. And also come see me.
But I really, really want a political metaphor...
A much better metaphor is the system of checks and balances most Americans will be familiar with as represented by our three co-equal branches of government. A group of three working toward the greater whole, but with specific, individual areas of responsibility.
Roles & Responsibilities
Why are they doing what is clearly MY job?
The responsibilities of the tripod overlap by design. This can often cause some consternation—someone’s always convinced someone else is usurping their job—but it’s important to understand the primary roles of each member of the tripod as well as the overlapping contributions they may make.
Things I’ve thought or said out loud (to people not in my tripod):
“I just feel like he’s trying to do my job.”
“But I’m supposed to run the sketch sessions!”
“I just need us to get this thing done… AGGGHHHHH”
“But I can’t let them design a solution without my participation!”
Yeah... don’t be me.
What are the definitely locked down and set in stone responsibilities?
Not so fast, rule-follower! While I like to believe stubbornly that these roles are super widely defined and acknowledged, the truth is we are all unique humans. (I’m here for the hot takes.) While there is a general guideline for who is responsible for what, each of us brings certain strengths, interests, and areas of expertise to our tripods.
The lines between each role are bendy… flexible, if you will. They can flex to conform to your unique tripod. The only absolute constant is that you must collectively discuss and define your roles when forming a new tripod. Like any relationship, communication is everything.
What are the more-or-less generally accepted hand-wavey responsibilities?
Product Lead
The expert in target customer needs/problems/opportunities
The main representative of company goals back into the team
The main representative of the tripod out to the rest of the company and customers
The final decision-maker on overall priorities / and or scoping decisions as a result of collaborating with the other leads
Design Lead
The expert in user experience personas for the customer base
The owner of the overall user experience and design aesthetic for the product
The main representative of company design systems back into the team
The final decision-maker on implemented designs
Engineering Lead
The expert in the technical lay-of-the-land for the product
The main representative of technical capabilities, constraints, company maintenance, and technical debt surrounding the product area
The final decision-maker on resourcing and structuring implementation within the product engineering team
It’s easy to say the designer has the final decision on designs and the engineering lead has the final decision on timeline and implementation and the lead PM has the final decision on scope, but it’s much more complicated to piece this together in practice.
Tripod Decision Making as a Rubiks Cube (because we needed another metaphor)
Look, this stuff isn’t simple, so I’m just putting it all out there.
Here’s a common situation that comes up time and time again in product:
-------------------------------------
DESIGN LEAD: Here’s the best possible
user experience
ENG LEAD: Cool, that’ll take us about
6 months.
LEAD PM: Nope. Try again.
DESIGN LEAD: Ok fine we could
cut this piece or phase it in later.
ENG LEAD: That doesn’t really help
us much… PM?
LEAD PM: We absolutely have to have this
piece and this piece, but that piece we could
probably punt on. What do you both think?
[debate for awhile, and comes to shared conclusions]
DESIGN LEAD: Cool here’s a new
design.
ENG LEAD: Would you be open to
changing this design element in this
way? It would save us a ton of effort.
DESIGN LEAD: Ahh, yeah here’s a
revised design.
ENG LEAD: Cool.
LEAD PM: Cool.
DESIGN LEAD: Cool.
ENGINEERS: WAAAAAHHHHHH.
(jk jk)
-------------------------------------
The Rubiks cube represents all of the constraints that the team is working with, and you, as the tripod, have to solve the puzzle together, as a team.
Imagine that your cube has these six sides:
Problems to be solved
Resource constraints
User experience standards
Technical constraints
Time constraints
Prioritization
Now, you may have noticed that “prioritization” seems like a bogus side, and you would be correct. It’s actually a placeholder side. Constraints are unchangeable, but using prioritization we can, in fact, move constraints around to find the optimal product.
Doesn’t fit into a totally important (read: arbitrary) timeline your company has? Ok, turn some rows. Now it fits in the timeline but doesn’t have an acceptable user experience? Great, adjust some columns. Keep working that cube as a team until you’ve got it solved!
The responsibilities of The Tripod
Obviously each member has their own responsibilities within the tripod, but the tripod itself has responsibilities as well.
Ok, what do they do?
Represent a shared front to the engineers on the team
Discuss and debate team priorities on a regular basis
Discuss team performance, concerns, and develop plans for how to address any issues
Cover for one another in case of illness / emergency / babies coming early / whatever
When in doubt, unblock the engineers
Collectively take ownership of the goals and results of the team
Challenge each other in a constructive way
How do we do that?
You may find that you need to meet as a tripod on a structure basis (once a week, once a sprint, whatever) in order to stay aligned with one another. Alternatively, you may find that simply working next to each other and chatting in ad-hoc ways may work for you. Either way, it should be discussed and explicitly chosen.
your PM Interview take-home is measuring all the wrong things
The infamous “Product Manager Take-Home Assignment” has gotten on my last nerve. I’ve been asked to do them in the past, and my clients now are often tasked with them as well. Every time I look at one, I’m appalled at what I see—because what’s being asked is not remotely what it’s like to be a PM in real life.
The infamous “Product Manager Take-Home Assignment” has gotten on my last nerve. I’ve been asked to do them in the past, and my clients now are often tasked with them as well. Every time I look at one, I’m appalled at what I see—because what’s being asked is not remotely what it’s like to be a PM in real life.
Why you should ditch your PM take-home assignment
It doesn’t even remotely simulate what it’s like to be a product manager
Sure, the take-home is testing something, but it definitely isn’t testing your day-to-day product management skills.
You may inadvertently be measuring how much time the candidate has, not how qualified the candidate is.
Product managers are high in demand, and often are interviewing at more than one place at a time. With these assignments, interviewing itself can be a full-time job.
You may miss-out on great candidates simply because they don’t have the time to do homework. Maybe because they already have jobs. Maybe because they have families to take care of. No matter how you look at this practice, it is not inclusive. So stop it already.
The first step of being a great product manager is to know your customer.
Without that knowledge, no exercise in the world can make use of a PM’s best asset. Instead, you’re testing a PMs ability to make assumptions about things they have little to no context for.
Your candidates are not unpaid interns.
Homework assignments that involve “real-world examples” from your company are nothing more than free work. Have some respect.
A poorly-structured take-home assignment can actually reflect badly on your product organization.
Why would I want to work at a place that doesn’t fundamentally understand what my role is?
Determined to have a take-home assignment? Here’s how to have a decent one
Do not make your candidates make assumptions about the customers.
If you’re going to give a take-home, you’d better include a treasure trove of (anonymized) customer quotes.
Don’t be stingy—to simulate real life for a PM, they must have access to your knowledge about your customer.
If you can’t share qualitative or quantitative data for some reason, make it up. Make sure every candidate gets the same packet of info.
Do not make your candidates make assumptions about the goals of your company.
Contrary to (apparent) popular belief, individual contributor (IC) product managers are not responsible for setting high-level company goals
While PMs may help define company strategy, it’s critical to give them a little top-down guidance to aim them in the right direction
If you don’t know what the goals of your company are, perhaps you are not ready to hire an IC product manager.
Do not ask a product manager to develop a go to market
A go to market strategy is not the sole responsibility of a product manager
A product manager certainly contributes to this strategy, but relies heavily on other roles (like marketing) to do this
Also… asking anyone to do a go to market in a take home assignment is absolutely inane. Sounds like a great way to have a candidate spin themselves in circles.
Frame the assignment around identifying key customer problems
If a PM knows some customer information and understands the high-level goals of a company, they should be able to dig through said information and identify the main problems that both address customer needs and work toward company goals
They should be able to articulate:
The top pain-points of the customer base
Their recommended prioritization (without any additional inputs)
Next steps for prioritization (e.g. how technical limitations, timelines, etc. might alter their recommendations and prioritization)
Under no circumstances should the assignment be around designing a solution
Wait, let me say that again.
Under no circumstances should the assignment be around designing a solution
“WHY?” you ask. “I WANT TEH WIREFRAMES,” you say. Frankly, my dear, I don’t give a damn. Product managers should not design solutions in isolation. Ever. Ever ever*.
SAY IT WITH ME: Product managers should not design solutions in isolation.
*Exception: You’re a 10-woman startup and everybody’s gotta be scrappy. Ok fine. Move along. This blog in general is not for you.
But back to not assigning a take-home
Behavioral-based interviewing techniques are a gold-standard for a reason. Past performance indicates future behavior. And so goes product. You’ll get a much better sense of how a product manager works and thinks by having them walk you through a past project or two.
Stop wasting your time and the candidates’ time—and stop assigning take-homes.
Are you trying to hire a product manager? Want some help
structuring your interviews? Reach out for some expert assistance.
neapolitan sundae: the three archetypes of product management
Have you ever had a conversation with a product manager where you felt like you were just missing each other completely? That you did product one way, and they did product another way? You both cited articles and sources and were confident you were thinking about product The Right Way™️.
The truth is, while our titles may be the same, fundamentally different types of PMs are needed to keep our product-world running. And they all do product, well, a little differently.
Have you ever had a conversation with a product manager where you felt like you were just missing each other completely? That you did product one way, and they did product another way? You both cited articles and sources and were confident you were thinking about product The Right Way™️.
The truth is, while our titles may be the same, fundamentally different types of PMs are needed to keep our product-world running. And they all do product, well, a little differently.
The Three Archetypes
I like to divide the world of product managers into these three basic types:
customer oriented
consumer oriented
optimization oriented
FOCUSED ON
needs & challenges of existing customers
PRODUCT ORIENTATION
long-term and strategic
DATA PREFERENCES
qualitative feedback from user research over metrics-driven
FOCUSED ON
usage at scale, such as daily active users
PRODUCT ORIENTATION
shorter-term, trend-based
DATA PREFERENCES
quantitative data from a mix of metrics and user research
FOCUSED ON
growth of platform / usage / conversion
PRODUCT ORIENTATION
optimizing existing flows & funnels
DATA PREFERENCES
quantitative, metrics-based data over research or qualitative data
B2who?
There’s yet another lens to add into the mix: your company’s audience. The style of product management at your company or in your organization is directly correlated to the type of audience you serve. Are your customers using your product for fun, or to get their job done? Is the goal of your product to keep your users around longer and more frequently, or to fill a need on a regular basis?
B2C Archetypes
If your audience is mainly people who use your product (or feature area) for fun, for leisure, or to manage something about their personal lives, you’re probably in a B2C (business to consumer) world. PMs who have a consumer oriented mindset are going to be the most successful in this environment, alongside optimization oriented PMs.
B2B Archetypes
If your audience consists of people trying to do their jobs or trying to run their business, you’re probably in a B2B (business to business) world. PMs who work in a customer oriented mindset will thrive in this type of environment. Optimization oriented PMs are also often needed in a B2B context, but to a lesser extent than those in a B2C context.
Double check your work
Note: You don’t have to provide software to corporations or enterprises to fall into a B2B style of product. When I first started working at Patreon, for example, the generally-accepted categorization was that we were a consumer product. However, Patreon is for creators—creators who are trying to run a business, that is. In actuality, my job in particular fit much more into a B2B world.
When assessing whether you are in B2B or B2C context, don’t use how the brand feels as your barometer. It can lead you astray.
kaizen, agile, scrum
We, the people of Tech, are enamored with buzzwords like Agile and Scrum. And yet, we fail to see the direct parallels to industries who have been using Kaizen and Lean for decades.
I started my career as an IT Project Manager at GE Aviation (called Aircraft Engines at the time) in Cincinnati, Ohio. I was thrilled to land such a great job straight out of college, and started in one of their famous leadership programs. Despite this sounding obvious now, GE did an exceptional job at preparing me for my career ahead in ways I’ve only recently come to really appreciate.
A key part of my job at GE was to be a technology partner to various business organizations in the company. I spent time with Sales & Marketing, Services, Engineering, and the Technology Services Group—what I liked to call IT for IT. Our business partners walked us through their incredibly complicated jobs, and we would work with them to identify and implement improvements to the way they worked. It wasn’t always quite problem-first—I didn’t know!—but it was startlingly similar to product management nonetheless.
Learning from the greats
Kaizen
Over the years, well before I arrived, GE spent a lot of time studying Toyota’s methods of operating. If you’ve never heard about Toyota’s famed Kaizen method, you should really spend some time and read up on it. Literally, just google “Toyota kaizen” and a veritable shit-ton of information will pop up. Kaizen simply means continuous improvement.
GE (and, specifically, one-time CEO Jack Welch) saw the incredible benefits Toyota reaped from Kaizen, and folded its concepts inextricably into GE’s cultural fabric. You cannot work at GE without hearing about Kaizen and Lean, just as you cannot work in tech without hearing about disruption. (Oddly, one concept is much more valuable than the other.)
Seeing is believing
I was lucky enough to have an opportunity to tour a Toyota manufacturing floor in Kentucky not once, but twice with other GE employees. It was absolutely fascinating—I loved being on the floor and seeing both the results of Kaizen, and the actual in-process practice of Kaizen. Factory employees are empowered to identify things that are making their job more difficult and be a part of their solutions. I distinctly remember watching a literal robot that carried tools to workers, using a magnet to follow a metal line etched through the floor. That started with the workers. That was Kaizen.
Lean before digitize
While its applications to a manufacturing floor are fairly obvious, I did not work on the floor next to the enormous jet engines. But GE had figured out how to weave the concept into its technology organizations as well.
Lean before digitize
As technology partners, we were often engaged to take a complicated, manual process and build (or buy) a tool to enforce and track that process. As any IT employee knows, we were often challenged to do more with less every year with every new budget. It was therefore our job to eliminate as much waste as possible from our projects. The number one way to eliminate waste? Remove waste from a manual process before building a digital tool to codify it.
Tame that process
I watched a lot of leaders, Six Sigma Blackbelts, and Master Blackbelts facilitate process mapping sessions. They asked critical questions, like… is this approval step necessary? What’s the goal of step x? If we’re gathering that data, what are we doing with it? And, over time, I got pretty good at doing the same. I’d be met with a process, and I’d tear it apart and rebuild it to be the leanest form of itself that still met the business needs.
Get to the point, Erin
I digress. This is not about my ability to tear apart and rebuild a process anew (although I find that stupidly fun). Rather, it’s about learning from old concepts and integrating them into the way we work in this age of technology.
Agile, Scrum, and Kaizen
We, the people of Tech, are enamored with buzzwords like Agile and Scrum. And yet, we fail to see the direct parallels to industries who have been using Kaizen and Lean for decades. Agile is to continuous delivery what Kaizen is to continuous improvement. And Scrum is the join table that binds them together.
Ehh? ehh? I mean… it made sense to me…
Scrum has been widely adopted in software engineering organizations as the process for building products, though ironically it’s often used alongside waterfall methods of product delivery, rather than Agile. Often, though, I walk into organizations that know little about Scrum beyond stand ups, or are worried about adding “too much” process.
Process is not the enemy
But process itself is not the enemy. Stagnant processes—processes that aren’t continuously improving over time—are. Scrum does not prescribe a specific process, rather it gives you the scaffolding of a starting template and the tools to tailor it to your organization.
Just as Toyota empowers its people to call out inefficiencies and solve them, we should be empowering our product engineering teams to do the exact same thing. Are we having a meeting weekly that adds no value? Speak up! Let’s figure out what the original purpose was, and then determine whether it’s still needed. Scrum is just as much about reducing process as it is about adding it.
Designing a process
Let’s say you get it, and your team is ready to embrace process! Where to begin? Well, luckily, process improvement is remarkably similar to product management. Start with some basic questions:
What problem is this process (or step) trying to solve?
Who is the audience?
What’s the current user experience?
What are the unintended consequences of the current process / step?
What are our constraints?
What are possible solutions to the problem this process / step is trying to solve?
Which is the best solution for the problem and user experience?
We’re constantly improving our products, and we should be constantly improving our processes. We have the skills, our people have the drive—they just need the freedom.
Unleash continuous improvement. Embrace Kaizen.
your mission
All good PMs should be systematically trying to work themselves out of a job.
Seriously. Great PMs should use every moment as an opportunity to inspire their team. They should be so passionate about the problem their team needs to solve that the team cannot help but care about the problem.
We tend to think of PMs as jacks of all trades… of great product idea people… of having constant meetings and never-ending to-do lists. And yeah… ok so that’s true… but that’s not the most important part of the job. Even if you’re starting off as a PM and you know all the things you’re supposed to do, you still might be overwhelmed by the sheer volume. How do you know how to prioritize all of these things that seem equally important? It’s a lot.
But, it’s actually pretty simple if you pare it down to the basic things you, as a PM, should be doing.
Know your Customer
Motivate & Inspire your Team
Empower your Team
Remove Obstacles for your Team
Know your Customer
Know Your Customer
I’m not going to spend a lot of time here. That doesn’t mean, however, that you shouldn’t spend a lot of time doing this.
You must talk to customers.
When you’re talking about a problem you’re trying to solve to, well, pretty much anyone, you should be able to name the humans you’ve spoken to that have experienced that problem. Without any prep. You should be able to say, “Oh, yeah I was just talking about this exact problem with Hillary from [famous person’s] team!” or, “Wes described his experience with [feature y] last week on the forums.”
Good politicians do this all the time. Candidates are always talking about [insert first name] from [insert city or state] and their challenges. They use these stories to show that they are in touch with real people and real problems. They use these stories to inspire their teams to help them canvas. These constituent stories are nothing more that customer stories. You, as a PM, should talk about your customer stories just as effortlessly as a candidate running for office.
Motivate & Inspire Your Team
All good PMs should be systematically trying to work themselves out of a job.
Seriously. Great PMs should use every moment as an opportunity to inspire their team. They should be so passionate about the problem their team needs to solve that the team cannot help but care about the problem. The motivation should spread like a god-damned virus. You should hear engineers talking to each other in the hallways about the problems your users are facing.
What do you think the productivity differential is between an engineer who cares about the problem they’re solving and an engineer that is simply writing code to a spec?
I don’t know and, to be honest, I don’t particularly care, because it’s enough for me that humans are enjoying their jobs. Then again we’re PMs, and no matter how human-focused we want to be, at the end of the day there is a company who needs us to get shit done. It’s a rhetorical question. Obviously motivated engineers are way better for a company, as long as you do not exploit that motivation*.
*An aside about Caring and Exploitation
That last bit is important. You want your engineers to be productive while they’re coding… you don’t necessarily want them coding more or for longer hours. And if you find that that’s happening, go stop it. In general, your engineers are probably only coding for maybe 3 hours a day (depending on the day). You should NOT see engineers coding all day every day, because they should also be doing all of this:
Thinking deeply about the problem they’ve solving
Thinking deeply about technical design
Doing code reviews
Interviewing to help your company grow
Cross-pollinating with other engineering teams
Pairing with other engineers
Taking a walk or grabbing a coffee to let their brains marinate
Prioritizing technical debt
Testing the stuff they build
Shit I don’t know… I’m not an engineer. But like… they’ve got stuff to do. Respect it and Get out of their way.
Anyway. Thou shalt not exploit caring.
Empower Your Team
Over time, your product-engineering team will develop its own ability to practically PM itself. A team that works together consistently over time on particular problem spaces builds up domain knowledge in those areas.
Teams become more familiar with the code base for the product areas they work on
Teams begin to see and understand trends in the problems they solve for their users
Teams experience user feedback to the products they ship
A team like this has hit their stride, and all of that “slowing down” from being a part of the solution process is paying off. A PM for an empowered team will still prioritize problems and present those problems. But when it comes to defining a solution, they will simply become a resource.
An empowered team doesn’t even need a PM in the room to work on a solution.
The engineers and designers know enough and have enough experience in the domain to make a kickass product.
Remove Obstacles for Your Team
So you’ve lead a team and they’re empowered and cranking out wonderful products. Don’t get too complacent, because your job has now shifted. Your primary responsibilities are:
Unblock your team
Continue talking to customers
Continue iterating on the long-term vision
Unblock your damned team
Occasionally you may onboard a new face to your team, and during some dark times you may still need to inspire or give a pep talk or two. Your main, day-to-day responsibilities, however, will mostly be making sure the train stays on the rails.
Often PMs are inundated with emails or Slack notifications or whatever the current hotness in productivity is. No matter the tool, prioritize your inbox/notifications/whatever to focus on unblocking your teams first. Is there a comment or question on a JIRA story or github PR? First order of business. Do all the support tickets assigned to your team have appropriate replication steps? Is there a backlog of at least two weeks’ worth of stories written and prepped?
Unblock your team first thing in the morning before you do anything else.
That’s your mission. Choose to accept it.
That’s it. That’s the job. Know your customer, inspire your team, empower your team, then get (everything) out of their way.
Glamorous? Nah. Satisfying to sit back and watch the team do its thing? You’re god-damned right.