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 –
One of the most common questions posed to product teams – “How can we go faster?”
Default response – “We need more resources.”
It is a perfectly logical response to that sometimes dreaded question.
The only problem is that it is right only around 30% of the time at best (anecdotal estimation). Assuming your company has a good engineering hiring bar and decent processes, the reality is that more accurate answers probably are – a) “We need more executive/cross-org alignment” or b) “I need to become a better product manager.”
If the answer in your situation is b), that is a painful pill to swallow. It hurts. But, after acknowledging that, the next question is – how do we move forward?
Today’s note offers a path to just that.
Solving for feasibility
A product manager brings together a cross-functional team to build products that are valuable, usable, and feasible.
Once we find a valuable problem to solve and figure out a usable solution, the final step is solving for feasibility. Feasibility means shipping a quality product as quickly as possible with the engineers on our team.
It is important to recognize here that feasibility is the minimum bar for a product team. Velocity is the goal. In the long run, velocity is an important source of the team and organization’s competitive advantage. (The previous post in this series is all about velocity in product teams – so, I won’t belabor this point)
So, how do we increase the velocity of the engineering team? I think there are 5 levers under 2 buckets:
a) Adding new folks
(1) Increasing the hiring/performance bar
(2) Increasing resourcing
b) Enabling existing folks to move faster
(3) Simplifying engineering processes
(4) Reducing exec misalignment
(5) Improving our product management abilities
Two of these – (1) Increasing the hiring/performance bar and (3) Simplifying engineering processes – are in the domain of how to run a good engineering organization. We won’t discuss as much because our influence as IC PMs is limited. That said, there are ways we can contribute:
(2) Increasing resources
As I mentioned at the start of this post, this is the most common lever product teams focus on. This is probably the right lever 30% of the time. And, it is definitely the right lever if you are leading a high performing team working on important projects with complete executive alignment that need to be developed faster.
If this is you, there are 3 things to keep in mind:
(1) Make your ask as soon as you realize the resource gap. Unless you’re in hyper growth, it typically takes a few attempts before resources come your way. And, it also takes a few extra months to hire the right folks. So, get ahead of the game.
(2) Tie your resource ask to concrete outcomes – typically improvements to y/y growth on metrics that matter. Using commonly used/true north metrics helps the executives involved prioritize your ask relative to others (and there always are others).
(3) The most helpful tool in your team’s arsenal is the reputation of punching above your weight. If you have proven your ability to do more with less in the past, it becomes easier for executives to trust you. If you aren’t there yet, don’t be surprised if you aren’t getting the resources you need. You will need to work on that first.
An important, if obvious, point to make here is that the culture of your team will change as the team grows. An engineering team I worked with grew from 6 to over 15 engineers in 12 months. Challenges with scaling the culture are real – we’ll cover this in next week’s post. This isn’t an argument against asking for resources – it is just a heads up that your role and responsibilities will change significantly.
(4) Reducing exec misalignment
Executive misalignment stunts velocity and damages morale. Executive misalignment plays out in many ways – slow funding decisions, uncoordinated efforts across teams, unnecessary internal competition and politicking, and so on.
I called out this lever as one you can influence. Your influence will vary depending on the culture of the company –
PM roles come with a reputation of having decision making power. This reputation leads a lot of PMs astray. That’s because some of the highest value work an IC PM does is to call out the importance of the decision, lay out the framework, options, and make a recommendation for product leaders to decide. IC PMs are thus decision enablers vs. decision makers on the decisions that matter. Embracing that role goes a long way in reducing executive misalignment and improving the quality of decisions in your organization.
(5) Improving our product management abilities
It is not possible to do justice to our most important lever in this post. So, we’ll cover this in two posts over the next two weeks. But, I’d like to leave you with a recent example that will explain why I believe this is the most important lever we have.
One of the flows in a project I’m working on involves a few permutations. While we did spend time on mapping these permutations when we were designing the flows, multiple permutations stirs that tingling sensation within. That sensation is a sign that we need to take the time to work out the possibilities. That, in turn, will help us build the product right. For example, if there’s a lot of business logic, we’ll make sure this logic is handled in the API layer instead of the clients.
I have my excuses for ignoring that tingling sensation here. But, they are excuses. All that matters is that I didn’t invest the time to bring the team together to map it out and document our plan.
Luckily, we’ve been in the process of rigorous testing and identified an issue through that process. But, reworking this involves a lot of wasted work. If doing it right took us about 5 engineering weeks, the reworked flow is going to end up taking 2x the time.
It sucks. We could all look around wondering why we didn’t catch this. But, the buck stops with me. And, it hurts to know that I wasted 6 weeks of engineering time.
This is how poor product management hurts a company. In every software company, engineering time is the most valuable time. And, poor problem finding and problem solving can result in a LOT of wasted engineering time. Some wasted time is unavoidable on a large project. But, wastage can go out of hand. It is the responsibility of senior PMs and product leadership to keep a close eye on this.
I am past the stage where such mistakes resulted in moments of debilitating imposter syndrome. That is useless – I have learnt that. When these things happen, I repeat this line to myself – “Do not fear mistakes. Fear only the absence of a creative, constructive, and corrective response to these mistakes.” I read this line over a decade ago in my favorite book (Stephen Covey’s 7 Habits) and I still find it comforting and useful.
I now focus on using the pain to improve in my abilities. In this case, the lesson learnt is to not ignore that tingling sensation – that is experience telling me to pay attention. It is also a reminder to not fall for the pretext that there isn’t enough time to get it right.
After all, if we don’t have the time now to do it right, how will we have the time to do it twice?
