Product Thesis

It is performance review season at my employer, so giving and receiving feedback is top of mind. I will not belabor the thousands of quality pages that have been written on this topic. See Radical Candor, Crucial Conversations, What Got You Here Won’t Get You There, and many other resources on this topic.

No matter how much I internalize that feedback truly is a gift, it still takes conscious effort to tamp down the defensiveness, urge to “explain”, or jump to counter-feedback. It is easy to forget in the moment that the other person has no obligation to give you the feedback, that it took courage to give you the feedback, and that they probably spent a good chunk of time choosing their words carefully so that it would be well received. Any response other than, “Thank you for that feedback. I will reflect on it”, is doing yourself and the other person a disservice.

So how do you keep the negativity at bay and the positivity in play? I’ve found the following tactics to be helpful.

Take a breath. If your first urge is to defend yourself, explain yourself, or attempt to contextualize, then take a breath, pause, and go to the next step.

Craft an “auto-response” that is genuine to you. Always be ready with your own version of “Thank you, I will reflect on that”. You have to mean it and you really have to think upon the feedback. The reason to have an “auto-response” ready is that any criticism, even if it is constructive, can feeling like an attack. Even the perception of being attacked triggers the fight-or-flight response. The fight-or-flight response is an obsolete evolutionary vestige in our context; we are no longer stalked by lions on the savannah. During the response, the amygdala and hypothalamus in the brain trigger the endocrine system to pump adrenaline into the bloodstream. This makes it even harder for the neocortex to process the information analytically and recognize the feedback for the gift that it is. The auto-response buys you time to get your reptilian brain under control so that your neocortex can go back to processing the information in an objective way.

Reflect. Reflecting on the feedback doesn’t mean you have to agree with it. It just means that you will make a genuine effort to understand that something you said or did was perceived in a particular way by another person. After genuine reflection, you still have the agency to decide whether to adjust your own behavior.

Follow up. After reflecting, you can be in one of three states. First, you may realize that you do need to adjust your behavior. Let the other person know and thank them again. If you want, you can tell them what steps you are taking to address the issue. If they are feeling generous, they might offer to help you monitor your progress or even give you advice.

Second, you may decide that you didn’t quite understand the feedback. You can ask the other person if they are willing to go into more depth with you to help you understand. If you do this, recognize that the other person has no obligation to do this. Any additional time they spend with you on the topic is a gift on top of a gift. If they do offer to talk in more detail, ask them for examples of the behavior in question, what they would have preferred to see instead, and if they have tips on how you can address the issue.

Third, you may decide that you understand the feedback but disagree with it. In this case, still recognize that it took courage and care from the other person to bring this to you. Be grateful for that and at the very least, empathize that an action of yours is being perceived in a negative way by another person. You may disagree with the feedback but you cannot “disagree” with how another person is feeling. They feel what they feel, and they have every right to feel what they are feeling. You don’t have any right to invalidate their feelings.

There is one exception to the above guidance. Some people (and sadly, some organizations) use feedback as a weapon to cut others down instead of as a gift to build others up. If you find yourself in one of these organizations, get out as soon as you can.

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!