A note for new subscribers: This post is part of a series on my notes on technology product management (this is what I do for a living). You might notice that these posts often link to older posts in the series on LinkedIn even though they are all available on this blog. That is intended for folks who only want to follow future product management related posts. Finally, for all those of you who don’t build tech products for a living, I believe many of these notes have broader applicability. And, I hope you find that to be the case as well…
A quick overview of what we’ve covered on “Notes on Product Management” so far –
Every once a while, we’re going to find ourselves involved in a project that is under senior executive scrutiny. These begin with an exchange that might look something like this.
Executive: Initiative X is a key priority. I’d like to start meeting with the team regularly to understand progress.
Product team: Yayy! What we’re doing is important. This’ll be a chance to show awesome we are.
Executive: When is the initiative scheduled to go live?
Product team: 12 weeks from now.
Executive: I’d like us to find a way to ship this in 6 weeks. Let’s start meeting weekly starting next week.
Product team: Oh crap.
:-)
The exchange above was meant to illustrate the key difference in any project involving executives – URGENCY. If that isn’t evident the moment an executive wants to get involved, I hope it will be going forward.
That doesn’t mean we shortcut the product development process. The steps in the process remain.
We just have to learn to get it all done at 2-3x the speed.
Why projects with executive involvement are both a blessing and a curse
I think it’s important to start here because executive projects look all sunshine and roses from the outside for the uninitiated. They come with two obvious benefits – high visibility and an ability to accelerate impact from our work by cutting through any bureaucracy.
That said, they have an equal and opposite flip side. It can and does go horribly wrong from time to time. And, the best way to understand why is to imagine the product team as a custom-built car on a busy road.
Executives typically want that car to navigate the road safely at 2x the speed the car may be used to. Now, if all the parts of the car work together as a well oiled machine, the car will withstand the test just fine. But, for cars with malfunctioning parts, this pressure test can have disastrous consequences.
High visibility projects can thus shine light on both the good and bad aspects of a team very quickly.
There’s another hidden cost – as preparing for meetings with executives takes effort, it isn’t always worth the trouble for the team. Such meetings only become worth the trouble in 2 cases –
a) The team needs help with making decisions that are existential and/or irreversible and/or critical to the future of the company
b) The team needs help with aligning various teams in the organization
All this gets to a counter intuitive idea – regular meetings with executives to review your project should never be the goal for a product team. Instead, it should be to embody the desired amount of rigor and urgency to win their trust to operate independently.
So, once you get to a point where you feel the trade-offs aren’t worth it, it is just as important to ask for these meetings to end. Good teams show up well and even emerge stronger with executive scrutiny. Great teams don’t need it.
With that said, let’s move onto dealing with the situation we’re in – regular check in meetings with one or more executives.
3 tips to making the best use of executive interest in your product/project
(1) Start with the problem statement – the fundamentals matter more than ever.
The number one derailer in an executive review is a lack of clarity on the problem statement. In the majority of instances, the culprit is the product team that ends up sacrificing rigor in the interest of speed. That is an example of a false choice – speed can never be an excuse for less rigor.
In some instances, however, it can also be the executive who unwittingly pushes the team toward the solution before validating the problem. This can be a tricky situation for the team. But, I think the onus is still on the team to go back to the problem statement and call out the assumptions being made in jumping to the solutions.
Again, speed and urgency cannot come at the expense of rigor. Sacrificing rigor always comes back to hurt the product and the team.
(2) Take the time to understand both the product outcomes and culture outcomes.
The product outcomes/success metrics are often obvious – this project may be critical to driving revenue or engagement. But, other times it isn’t. Don’t be afraid to clarify the expected outcomes.
I recognize I am cheating a bit here as this is just another way to be aligned on the problem statement -> hypothesis -> success metrics (i.e. the fundamentals mentioned above). This just underscores how critical it is.
However, once you make 100% sure you’re aligned on the product outcomes, it is also helpful to understand what the culture outcomes are. When executives lean in on projects, they’re often attempting to use these projects as an example of the culture change they seek to make. For example, the executive might want to try out a new approach to product reviews or may want your team to be an example of how a team can collaborate/operate with urgency.
Culture outcomes aren’t always explicit. So, the onus is on the team to read the signs and deliver.
(3) Use the room to surface the hardest problems you are dealing with
There’s a fork here –
(i) For projects in early stages, use the time to ask all the toughest questions pertaining to the problem statement, hypothesis, assumptions, and the most challenging flows/design trade-offs. Of course, you don’t just ask the executives for answers here. You go in with your point of view and see if the executive is aligned with your perspective.
(ii) For projects in execution, create simple docs/slides that share progress toward ETAs and bring forth all the hairiest disagreements and decisions the working team is facing. Getting unblocked is what makes these meetings worth it. Creating picture perfect slides is a waste of time.
In short – don’t try to look good. Just focus on doing your best to make progress.
An important note here on collaborating with partner teams: If your project involves multiple teams, it is important to surface problems without throwing peers/partner teams under the bus. This sounds counter intuitive as it is tempting to think about such projects as a “blank check” to bulldoze other teams into getting what you want.
But, if it isn’t evident already – the “blank check” is a myth. While that can work in the short term, that is a sure-fire way to destroy your credibility with your peers. The goal is to persuade peers and partner teams on the merits of the argument, not because some executive said so.
So, the way to use executive interest in projects is to a) persuade peers/partner teams about the importance of the problem you’re solving and b) share the limelight with them by bringing them along into your executive reviews and making progress as one team.
Now that we’ve gone through tips on how to do these well, I wanted to make sure we cover 3 common mistakes.
3 ways to mess things up
(1) Not demonstrating urgency.
Here are three common ways teams show a lack of urgency:
(i) Wasting time in meetings by bringing poorly synthesized materials – if you need more than 2 pages or 10 slides to make your point, there’s room to be crisper. Meetings with multiple senior executives in the room are expensive – it is on the team to make them count.
(ii) Asking questions and entertaining doubt without making forward progress – As I’ve said multiple times, it is critical to ask questions. But, it is also vital to do this while continuing to make as much forward progress as possible. At the end of the day, if your Head of Product believes something is important and wants you to deliver, get it done already.
(iii) Padding ETAs to get to high confidence and/or to attempt to under promise and over deliver – This is a bad idea. I’d go as far as saying you want to be as aggressive as possible with your ETAs. Better to showcase urgency early and be a bit late. Executives understand things going wrong – but it is hard to excuse a lack of desire to move quickly on something important.
(2) Covering up misalignment within the working team.
Sometimes, teams worry about how executives might perceive misalignment. I remember a situation where we worked very hard to conceal misalignment. It resulted in a completely disjointed discussion and a failed meeting.
The purpose of such meetings is to have the hard conversations and emerge with clarity. Again, don’t worry about looking good. Just focus on doing your best to make progress.
(3) Expecting kudos and pats on the back.
Any team that goes in attempting to engineer kudos and pats on the back generally fails. Go to these meetings to get hard feedback and work through challenging problems. Any celebration of progress happens best when it ensues vs. when it is being pursued.
Additionally, beware celebrating “good meetings,” executive praise, and/or some arbitrary internal milestone. Product teams win when our users win. Everything else is gravy.
