I have written before about crafting a vision and developing a strategy. In this post I will write about switching into execution mode. As a product manager, you don’t directly build the product. You create artifacts that enable engineers and designers to build the product. It can be easy to fall into the trap of believing that vision decks, strategy memos, and product requirements documents are the ultimate deliverables of the PM. However, these are just the tools that help you do your real job: build and deliver the actual product to your customers via your cross-functional peers (engineering, design, marketing, sales, etc).
What is “execution”?
Execution is turning your vision, strategies, and PRDs into an actual product, launching the product to users, getting feedback on whether the product solved the user’s problems, and iterating. A lot of ink has been spilled about the standard execution toolkit: OKRs, roadmaps, Gantt charts, stand-ups, schedules, etc. These are important, but the most important tool for successful execution is mindset.
An execution state of mind
I’ve seen some PMs think that once they have written the PRD, their job is complete and they can hand over execution to the TPM and engineering. This is a mistake. While it is true that the engineering manager and TPM will play bigger roles during the development phase, the PM cannot simply peace out. I would argue that 60-80% of a PM’s time over the course of a typical year is spent on execution. Ultimately, the PM will be held accountable if the product is delayed or does not meet the feature requirements or quality bar.
The best PMs are absolutely unstoppable at getting stuff done. There is a big mindset shift in going from a vision and PRD to execution. You are operating at the highest altitude when defining a vision and medium altitude when writing a PRD. You are abstracted from the details and can operate in a pure intellectual playground. Execution is different. Solid execution requires that you drill down into details. These details will be messy and full of unknowns. You must get under the hood and get grease and grime on your hands.
Embrace agency. The most important thing is to deeply internalize that you almost always have agency. It is really easy to attribute delays or under-delivery of your project to things “outside of your control”. Perhaps a team you had a critical dependency on is late. Perhaps half your engineering team took vacation during the same critical two weeks. Perhaps a different company that owes you a code library or hardware component is late.
All of these things have happened to me. Whenever you feel like the outcome is not in your hands, ask yourself, “Have I taken every possible action to solve this issue?”. Did you escalate to the VP of the dependency team? Did you align on coverage with your engineering manager for the critical periods in the schedule? Did you have a second source supplier? Did you ask your executive team to contact the partner company executives and light a fire on that end?
Know your product. You should know the status of any aspect of your product in intimate detail. Some products are too complex for any single person to keep entirely in their head. In these cases, you should be able to get an answer to any status question for any subsystem or sub-component within a day or so.
Channel the executive team. Your executive team (VP, Directors, etc) will expect you to channel their point of view. This comes with a lot of indirect authority, but also puts the PM in a difficult spot. The PM does not have any formal authority over the engineering and design teams, but will be expected to hold these peers accountable. The fastest way to PM failure is to try to “boss” your peers around. Instead, try using the following tools.
The execution toolkit
OK, so you’re in the zone to execute like a machine. What tools do you pull out of your PM toolbox and arrange on your workbench?
OKRs and DRIs. You did write OKRs, align them with your cross-functional peers, reviewed and signed-off with your dependencies, and identified a DRI for each Key Result right? Make sure to regularly check-in on your OKRs with your teams. The check-in cadence will depend on the type of project. Regardless of whether the check-in is once a quarter, once a month, or once a week, treat the check-in seriously. OKR check-ins must never be perfunctory. Always drill down into the Objectives that are not on track to understand why. Ask the DRI what levers would get it back on track.
Granular status checkins. If your project merits OKR checkins only at a coarse level (say once a half or once a quarter), you will want more granular workstream status updates on a weekly or biweekly basis. Waiting a whole quarter to find out that something is late, low quality, or de-featured is a sure way to a delayed launch. I don’t care whether you call these “stand-ups”, “weekly snippets”, “sprints”, etc. What is important is that you have your finger on the pulse of the project at a very tactical level.
Precision questions. I wrote above that you need to channel the exec team to hold teams accountable, but unlike the executives, you don’t have direct authority over your peer teams. The way to do this is to use “precision questioning”. Ask crisp, clear, and specific questions. It’s important to do this collaboratively and not come across as an interrogator. How is our progress bar looking? What are the blockers? What are we doing to get through the blockers? How can I help with that? Can the exec team do anything to help us move faster?
Reward honesty. Some teams may be rightfully worried that they might be the long pole on a project. In the limit, this can manifest as teams not being honest about the true status of their deliverables. This should be alarming to the product manager. To guard against this, always celebrate teams that flag delays and challenges. You want folks to feel psychologically safe in bringing up difficult conversations. You cannot fix a problem that you don’t even know exists.
Public progress bar. Maintain a public and visible state of progress. How many tasks left? How many bugs to fix? Grab a large 65″ monitor, place it where everyone can see it, and throw up a dashboard with these progress metrics. Ensure the dashboard is updated in real time.
Internalize the iron triangle. Understand the features vs schedule vs quality trade-off. When push comes to shove (and it always does!), be ready to articulate use case trade-offs. Your use cases and product requirements should be down-scalable in a way that retains product coherency. Steven Sinofsky’s post linked above goes into detail on how to do this properly.
Judiciously hit the afterburners. I have never been on a project that did not have crunch times. It is really important to develop to accurately identify these periods in the schedule. When you enter one of these periods, rally the team to turn on their afterburners. This metaphor is chosen intentionally. Afterburners let a jet plane go supersonic for short but critical periods of time at the cost greatly increased fuel consumption (yes, the metaphor breaks down for supercruise!). You cannot push a team to have their afterburners on all the time because they will run out of fuel and burn out. On the other hand, teams that do not fire up the afterburners at critical periods will probably fail to deliver.
Hope these tips help you deliver on your next big project!