First Few PMs (DevTools)
Two more nuances to the role
Welcome back! You subscribed more for writing on Product, startups, DevRel, and VC. Past topics have been doing product as a founder, the first few PM hires, and writing a PM job description. Finding it useful? Please share with a friend so they can subscribe! For the next post we'll be back to the regular Friday schedule (March 11th).
🇺🇦 There was a lot going on last week. I don't have much to add on top of what has been said about the world situation. If you're still looking for ways to get involved and help with Ukraine - Shomik rounded up some resources for supporting Ukraine, and Ed shared this one. To add to the list of ways to contribute, Olga, who I've known for a long time is working to support her community.
Today, I spend most of my time with developer-facing companies. These companies have software developers as their primary users, and have some aspects of consumer and some aspects of enterprise companies (Lee went into that here and here, and I hope to dive into in the future). For this week, I wanted to add two nuances for the first few PM hires at devtools companies, because the role tends to be particularly controversial.
🎟 Proof of Work, not Proof of Worth
Shreyas' great thread on Proof of Worth tasks for PMs resurfaced this week.
While I've said before that it's not necessarily important for a PM to have a technical background, and that technical curiosity is more important. We also often include technical contributions as one of these “proof of worth” tasks. Devtools can be a (semi) exception to both of these.
I’m repeating myself, but it's crucial for the PM to understand the users to be able to illuminate the difference between what the users do and the early product intuition.
In devtools, the fastest way to do this is usually to build something using the tool. This can look a different depending on the exact tool - using the API for an API company, re-hosting an old project for a hosting service, swapping in a new database for an old project, or building a new side project with the tool as part of the stack.
In addition to building personal knowledge and providing some starting empathy with users, doing this tends to create an immediate team bond. It provides an artifact that the PM and existing team can talk together about, and a tangible set of examples the PM can draw from. It opens up conversations about intent and usability. To be able to hit the ground running with this work, an early devtools PM should come in with the basics of being able to build software. It's nearly impossible to be learning a new tool while also learning about an editor, what REST is, and how to use Github from the CLI or the app.
In rare cases, teams will think “we don’t need them to use the product, we have plenty of engineers.” This is usually a signal that the team is thinking about hiring a project management, not someone who deeply empathizes with the users. I’d be suspect of a team that doesn’t expect the proof of work.
More common is the opposite, which veers into Shreyas’ ideas around proof of worth. The early devtools PM is not an extra engineer. They do not necessarily need to contribute to the core codebase, or know the deeper nuances of the tools outside of the one the company makes. Beyond the ability to use the tool, asking for continual proof of technical credibility becomes too much.
👩💻 Who is the user? Crossing the Chasm
Most devtools are founded by developers looking to solve their own problem, and the earliest engineering hires are drawn to the company because they liked using the open source project or the product.
In this early stage, the easiest way to make decisions is just for each person to do it as they build, especially for small changes and bugs. Since this works early on, it leads to the common pushback:
We’re all the users, and we’re part of our community. We don't need some extra product person to talk to the user for us. We know more than they do.
That's true, but only to a point. As the company succeeds, more and more developers use the tool. Developers who care about a tool so much that they want to work on it full time are not the same as developers who just want to get something done. There's a selection bias.
The more successful the company is, the more the gap between the internal employee users and the external users widens.
This isn't a small distinction, it's the difference between the "innovators" and the "early majority" from Crossing the Chasm.1
A new product management hire is often the first person to see this tension.
For the team to be successful, they must understand the nuance of how external developers are both similar to and different from themselves.
The best case scenario allows these teams to work more quickly (product doesn't have to be involved in every small choice) while still keeping in mind the broader developer user base. When this doesn’t happen, the new PM becomes Cassandra. They share the issues but the team refuses to see that not all developers are the same. This can be company ruining.
As a result of these two challenges, the first PM for a dev tools company can be an extremely tough role to hire for!
If you're particularly interested in developer tooling PM jobs, please send me an email. I usually have a few opportunities for first PM or first PM leader floating around and I'd be happy to see if there's a good match.
Classic chasm graphic from Strategies for Influence.