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 –
There are many variants of IC product management roles. Some are heavily customer facing and involve spending a lot of time with marketing, business development, and sales. Many require heavy collaboration with design. Some others have a strong data component.
But, the one common feature across every IC PM role is collaborating with an engineering team. Not only is this is also one of the biggest levers we have in our attempts to solve for velocity, this relation is also central to our day-to-day happiness as PMs. As I shared in “Solving for Feasibilty,” improving our ability as product managers can solve velocity problems we have ~50% of the time. And, the way to do that is by building habits that step-change our collaboration with our engineering team.
As collaboration with engineering is so fundamental to an IC product management role, we’re going to go back to the basics. We will take the 4 core skills we’ve discussed at length – problem finding, problem solving, selling, and building effective teams – and break these down into a collection of habits.
(1) Problem finding: Engage engineering leads early
(2) Selling: Explain “why” – every IC should know why their work matters
(3) Building effective teams: Be a great partner
(4) Problem solving: As this is the most used skill in our collaboration with engineering teams, we’ll cover habits that are important as part of prioritization and development in today’s post. We’ll cover releases in the next post.
(1) Problem finding: Engage engineering leads early
“Engage your cross-functional partners late” – said no cross functional partner ever. :-) This applies to engineering leads as well.
Over time, you’ll have experience partnering with various kinds of engineering leads. I’ve come to think of 3 leaps engineering leads make –
While some leads make these leaps in previous roles, others can make these leaps when we partner with them and engage them in our thought process. That, in turn, results in them pushing us to become better product managers. They do this by ensuring we understand the impact of our decisions.
For example, when our engineering leads push us on whether we feel our problem statements are strong, they’re reminding us of the cost of getting these wrong. I’ve spoken with irate engineering managers who’ve spent months building a product only to realize the product wouldn’t see the light of day.
It doesn’t matter that the reason is executive misalignment or that customers hate the idea of the product. From their perspective, it is months of wasted effort and damaged morale. And rightly so. Product development is expensive. The more we can do to catch problems early, the less the cost of the process.
Engage your engineering leads early.
(2) Selling: Explain “why” – every IC should know why their work matters
A traveler was once passing a man cutting a big rock. She asked him what he was up to. “I’m cutting this rock” – he said.
After walking a few yards, she saw a second man working on another big rock. When she asked him what he was doing, he said – “I am building a roof.”
A few yards further, she saw a third man working on a similarly large rock. As she was still curious what was going on, she asked him as well. “I’m helping build a Jedi temple*” – the third man responded. “It is going to be beautiful when we’re done.”
(*He wasn’t using a light saber – in case you’re wondering)
I think this story is a useful way to think about whether you’re doing a good job selling. If every IC engineer on your team can explain what you are working toward and why their work matters, you’re in good shape.
Else, keep at it. Explain why till you are tired of explaining why. You’ll be surprised just how much of an impact it has. You’ll find team members giving an extra 10% that you never thought possible here and another extra 10% there.
Inspired teams do inspired work.
(3) Building effective teams: Be a great partner to IC engineers
We will be covering building effective teams in more detail in future posts. This section is focused on being a great partner to your IC engineers. And, you can do that by paying attention to the context, trust, and communication trifecta.
The context-trust-communication trifecta is a simple way to think about the health of your team. They are like three legs of a tripod. Understanding this helps us understand why the majority of teams are dysfunctional. Teams work only when all 3 of these are healthy.
(a) Provide Context: In addition to sharing why what you do matters, use team meetings to share context. This includes any change in priorities that you’ve heard from the leadership, any key changes in strategy in the broader organization, important pattern changes in business metrics, and/or updates about related initiatives that partner teams are working on. Encourage engineering leads and other cross-functional partners to do the same. Shared context helps everyone make more informed decisions.
(b) Invest in building Trust: Invest one team meeting every quarter/few months to do something different. Play a fun game or organize an ice-breaker. The most powerful exercise involve members of the team sharing their stories. Getting to know each others helps build understanding and trust.
(c) Prioritize communication and responsiveness: IC engineering time is the most valuable time in software companies. Internalizing that idea means ensuring IC engineers on your product team are never blocked. While good problem finding and product specs help us with this, we’ll also need to be available for our engineers as problem solving partners when they face inevitable blocking issues.
This is why co-location is powerful for product teams. No amount of structured communication can replace walking over to a partner’s desk and solving the problem on a whiteboard. But, as we’re all in a virtual world for the next months, committing to a reasonable response time on Slack/email is an important replacement.
This doesn’t mean reacting to every ping and never making time for deep thought. It just means setting clear expectations on when you’re unavailable and responding to folks every few hours to ensure no one is blocked.
As I mentioned at the start of this section, all of the above constitute the basics of building a healthy partnership with our IC engineers. We’ll cover this in more detail in future posts.
4) Problem solving:
a) Prioritization – Invest in foundations/problem prevention (a.k.a “Be a Lannister and pay off your tech debts” in a post on “5 habits that build a high velocity product team” )
When was the last time your team had an urgent bug? I assume you celebrated the folks who burned the midnight oil to solve it?
Acknowledging and appreciating such efforts is good. But, we provide more leverage to our teams when we use such issues to prioritize upstream/preventative bets. Attempting to squeeze every inch of engineering capacity in the quarter to move metrics is a short-term efficiency focused game. The goal isn’t efficiency, it is leverage.
To enable high velocity product development, we need to free engineering time from constantly dealing with urgent issues. And, we can do do that by marking off a proportion of our engineering capacity for foundational efforts.
This investment turns out to be one of the easiest things we can do to help create happy engineering teams. Such efforts don’t just reduce painful on-call shifts (they do that). They are often the source of intellectually stimulating work that can often provide leverage to other engineering teams as well.
Finally, while we can run with a ~25% allocation as a rule-of-thumb, this can go up in some quarters depending on the nature of the team. Typically, the more backend work involved, the more it is likely we’ll need to make large investments and ensure the engineering team has the space and autonomy to build scalable systems.
b) Development:
i) Aim for leverage
Efficiency is minimizing effort for a given impact. Leverage is maximizing impact for a given effort.
Aiming for leverage means 2 things in the development phase –
When Jeff Bezos mandated that every Amazon team would expose their data and functionality via APIs in 2002, he explicitly prioritized leverage at Amazon.
Of course, Amazon’s example won’t be relevant to every company and team. You are not going to be able to prioritize leverage if you are barely managing to survive or struggling to find product market fit. Shortcuts are inevitable.
But, every shortcut racks up tech debt. So, if you have the luxury to take a bit of extra time to build it right or are part of a large company where a leveraged solution can have massive cross-team impact, it is worth the wait.
ii) Document everything
You’ve probably done lot of documentation in the problem finding stage – with a strategy doc, roadmap, and a product spec. But, for large product releases, I’ve found it helpful to have an additional doc – a “plan” spreadsheet.
Unless you’ve got superhuman attention to detail, you’ll inevitable find a need to incorporate more business logic as you discover various edge/stress cases. These edge/stress cases may just be lines on a document to a PM. But, to an engineer, it could be the start of years of pain when services breakdown, angry users flood the support channels, and when executives criticize the craftsmanship of the product. Stress cases are important and we need to be as thoughtful about our decision making in dealing with these as with our P0 product requirements.
Every time you make a decision or update the logic, document it in your plan spreadsheet along with other decisions you make as you move towards a major release. We’ll spend more time on this spreadsheet in the next post.
The process will ensure you don’t make one-off decisions in a slack thread that is buried somewhere. It will also force you to simplify business logic and variants. That, in turn, will reduce long term maintenance costs and improve your team’s velocity.
c) Ramp/Release: This area is large enough to warrant its own post. So, we’ll cover this next week.
I hope this was helpful.
