PMs in developer tooling

I've now been a PM for more than 18 months, and it's finally going well! I did spend the first year or so struggling to find my footing. It was mostly due to a lot of nostalgia, misconceptions about the job and a strong belief in how the developer <--> PM dynamic should look like.

These are my personal opinions, and not that of my employer. And these might be better suited to startups than scaleups or bigger companies, though I refuse to believe that.

A lot of this also applies to developer tooling that the people building the product are also dogfooding on a regular basis. I don't know if you can build insurance or real-estate software without a PM.

The ideal world

I am sure I am romanticising things a little, but this is as I remember them.

Grafana Labs is my first full-time job, right out of university. It was less than 30 people and a true startup. The product I mainly worked on was hosted Prometheus (based on Cortex / Mimir) but I also helped launch our hosted Logs product based on Grafana Loki. We didn't have a PM for the products in the first three years after launch.

Our engineers were the PMs for the product. Some engineers were more involved in product decisions than others, but the general question of what to build next came from engineers. This was possible due to a few different reasons:

1. We were dogfooding Mimir and Loki internally. They were both critical to our development workflow and were using both products 100s of times weekly.
2. Our engineers were speaking to customers regularly and were closely involved in the sales and post-sales cycles. I've written about it here: Engineering should talk to sales (A story of Grafana Labs).
3. We owned the success of our products. Atleast thats how it felt. We wanted hosted Prometheus and hosted Logs to be successful and understood what success means and how the product was performing. We understood why we won deals and why we lost them.

This created a unique environment that accelerated our time to product-market-fit. Because we were using the products heavily, we had an opinion on whats missing and what to build next. Because were were also talking to customers a lot, we knew what the market wanted.

And this is how we did planning:

1. A few items MUST be implemented because they were promised to customers.
2. Everything else is put on a sheet and voted on by engineers. And because engineers were using the product and talking to customers, we roughly ended up voting on the "right" things.

It's not perfect

Did we get everything right? Ofcourse not! But we got more things right than wrong. We also had the massive advantage of selling to engineers that resembled us and had a lot of the same problems. And because we were also using the product ourselves, this created a lot of empathy for customers and helped us prioritise the right things.

Finally, this was not for every engineer on the team. There were definitely some who were more product focused than others. There were some who didn't speak to customers at all and focused mainly on the engineering aspects. But being product focused and talking to customers was an important part of the career ladder and strongly encouraged.

PMs are important

So if engineers are product focused, do we even need PMs? The answer is Yes, but not to build the product itself. A lot of my time right now is spent on launching, marketing, pricing of the product itself. I also find myself spending time teaching Go-To-Market (GTM) how to sell the product I am the PM for. These were things we never needed to focus on because our leadership (VPs, CTO, CEO) took care of them. We were small and early enough that every product had personal attention for the C-levels.

Finally, as the product matured and grew, so did the team. Once you're 15+ engineers, you'll likely split into two teams with different focus areas and need a lot more coordination. At this point, you'll also have a lot more customers that a dedicated PM for the product makes sense. This came around the 3 year mark for both hosted Metrics and hosted Logs which is when they got their PM. Honestly, it might have been better to have a PM a little earlier.

But it's always better to have a PM too late than too early.

Fighting natural tendencies is futile

Last year, I was the PM in a new team that was building something completely greenfield. The PMs grew faster than engineers, partly because I switched from engineer to PM in that team reducing the number of engineers and increasing the number of PMs.

This created an environment where the engineers were focused on engineering and completely left the product space to the PMs. For example, when doing roadmap planning for my team, I got enough blank stares that made it clear that most engineers on the team don't have an opinion on what features are more important than others. The PMs spent a lot of time explaining the feature requirements to engineers which also made it clear that engineers didn't have enough intuition for what we were building. We didn't dogfood the product which didn't help.

There were a few engineers who got it but there were enough that didn't that it was concerning. But I don't blame the engineers here. They had A LOT going on too, and because they had enough PMs assigned, they naturally tended to offload a lot of the product thinking to us. We, as PMs, have tried many times to include them into the product design process, by asking them to comment on the product DNAs, including them in customer calls, etc. But none of the efforts ever really worked in my opinion because we were trying to fight natural tendencies.

I spent enough time fighting the status-quo than actually getting PM work done which wasn't a great experience. We had a reorg that drastically increased the number of engineers per PM which made things much better imo.

Building teams for success

Product is a team job. Everyone on the team should own all things product and it's success. However, this doesn't come naturally to all engineers, but a few engineers excel at this. These engineers challenge you and it's a joy to be a PM on teams where they exist. These engineers treat bad UX as bugs and work directly with customers to make sure they are happy.

They have strong opinions on where the product should head and I needed to come prepared with evidence to convince them of my view point. And they talk to enough customers and users, that more often than not, I was the one who was convinced otherwise.

They are hard to find though. It's not reasonable to expect to fill a whole team with engineers wearing the product hat, but you need to have enough of them for the product to be successful. They will own the product and it's success and once they do it for a few years, they will continue to own it even when the PM shows up.

If you introduce a PM right at the start of the product, the PM will do most of the talking to customers, and there is a high chance that the engineers won't put on the product hat as much.

PM for Startups vs Scaleups?

It's easy to expect startup engineers to wear multiple hats, but is it reasonable to expect the same when we're 1200+ people? I think so.

I don't think an engineers job should be restricted to knocking out tickets without understanding the wider context. It honestly sounds boring and something I would personally never sign up for.

Finally if we move into a world that is purely driven by PMs without engineers having strong opinions, or talking to customers or being involved in sales-cycles, I think we lose a big chunk of what makes us "special" at Grafana Labs.

If that sounds too dramatic, well, remember that this whole blogpost is my personal opinion rooted in nostalgia.

It's not easy

I am now the PM for a startup we acquired late last year. This is a team of engineers that built the product with care and everyone of them was involved in the sales cycles pre-acquisition. They understand what resonates and what doesn't and deeply understand how their customers use the product. Being a PM for them is a joy. Everytime I have a feature request, they want me to explain "what the user is trying to achieve" before getting into the feature itself.

However, I find us slowly settling into a rhythm where I am gradually doing more and more of the talking to customers. The engineers are getting feedback but second hand through me and don't really talk to customers directly. I think that is risky and I might start taking a step back here to create a vaccuum that the engineers fill in.

If I end up being the only person talking to users then I'll be best positioned to plan the roadmap and that's plain stupid. I strongly believe that engineers who dogfood and who also understand the system internals intricately can make better decisions if they also talk to users.

However, it's not as simple as asking engineers to step up, as that won't hold long-term. I need to deliberately create a vaccuum that engineers are forced to fill. For example, by not sharing my opinion on what to build next or deliberately not attending a few customer calls without engineers backing me up. It's tricky and easy to get wrong, but that's what I'll be working on for the next few months!