When should an open source or developer tools company hire their first product manager?
When should an open source or developer tools company hire their first product manager?
I get this question routinely from companies I advise and invest in. I wanted to gather my thoughts after conversations with several others and catalog them for future reference.
Note: There are no hard and fast rules here. I’ve seen a PM be one of the first hires, I’ve seen a PM be a hire around 50 people. This is just a perspective.
The big question - what's the charter⛵️?
Startups, especially open source ones, need to be crystal clear on the product management charter. It's one thing if you've got a fully proprietary product. Drop a PM into a product area, give them some customers to talk to, they should be able to help right away.
Pre-product market fit startups are different.
Open Source startups are different.
Bringing in a PM with the wrong context, understanding, and perspective is going to cause a lot more pain than problems that it solves. A PM before you're ready is probably going to slow things down.
The bigger question - what's the problem you want a product manager to solve?
Too many startups hire a product manager before they're ready. I've seen startups with the following problems think they need one or more product managers. These problems can manifest as 'product management problems' and this leads you to think that you need to hire a PM when in fact you could get by with a variety of other roles or simply enable your team with more skills.
🚚Operational - Do you need someone to help run a process, ask the right questions, ensure we're on the right track?
👨✈️Enterprise / Security - Do you need someone with knowledge of the enterprise space? That understands the nuances of building infrastructure products for the enterprise?
📦Packaging / Pricing / Managed Service - Do you need someone who's going to help formalize your offering? Someone who's going to make sure you've got the right boxes checked and avoid blindspots when you're packaging up your product for the market?
📈Growth - Are you looking for someone who will help market and grow the product? Who can talk about what you're building to the right people?
🤝GTM / Customer Engagement - Are you looking for someone who can work with customers? Close Deals? Run a sales process?
🏗️Business Development - Are you looking for someone that can engage with partners? Ensure your message is clear?
👷♀️Sales Engineering - Someone to help customers succeed on the product?
👯Community Management - Do you need someone who's looking at the community, understanding who's coming in, and can help foster that community?
👩🏻💻Developer Relations - Do you need someone who will manage relationships with developers? Someone who will write tutorials, marketing material?
👩🏫User Enablement / Customer Engagement - Someone that can help hand hold user and channel feedback back to the engineering team that they couldn't get otherwise?
In general, generalists are more valuable at startups, especially pre-PMF. Hiring too specialized of a PM, too early, is going to cause trouble. You hire generalists to help to get to PMF. Once you've got that, then you can start to specialize.
Some roles that are solutions to the above are:
Program Management - Someone that can help operationally, maybe do a little bit of business development if guided by a founder, so support or user engagement. In general, these folks need a system to operate in or drive. No system, not effective.
Product Management - Someone that can help with managed service creation, pricing, packaging? Can take on some basic business development, and some customer engagement?
Product Marketing / Marketing - Someone that can help position your product in the marketplace and run a process to do that - in particular with respect to a managed service / priced offering. Someone who can help with understanding how customers are thinking about the product and using their language to position your offering.
Developer Relations / Community Management - Someone who can engage the primarily open source community? Someone who's going to do roadshows about your product and help spread the word? Someone who's going to help with open source growth?
Sales Engineering / Sales - Someone who's going to sit with customers and help them design the solution. This works especially if you're building a platform or more platform oriented product.
Common pitfalls for issues that could be addressed by PM, but maybe shouldn't be
Pitfall 1: 🗺️Strategy - "We need someone to own the strategy, we should hire a PM."
Founders must own startup strategy prior to scale mode when parts of strategy can be farmed out to ICs with more experience. An IC PM (depending on experience) can help inform strategy. They’re not going to define it.
Especially for engineering products or open source projects, part of the founders or early engineers job is to evangelize, stay close to customers and users and ensure you're building the right thing.
Caveat 1- you're looking to hire a head of PM and you've got product out in the market / already have some resemblance of PMF and are entering optimization / growth mode.
Caveat 2- you're at a growth stage / expansion stage and now you need to find new channels, partnerships, relationships to manage.
Pitfall 2: 👎Bad Features - "The engineers are building the wrong thing, we should hire a PM."
If you’re still in the building open source phase, then this is an engineering problem. You cannot farm out customer empathy to the PM. Your engineers in open source must connect closely with end users.
Do not outsource customer empathy to product management. It. will. not. work.
Open source communities don't look to product managers for leadership. They look to other engineers. There are so few PMs that operate in this arena and the stakes are too high for the company for a PM to be charged with this, especially in the early days.
At Anyscale and Databricks this was true. The open source product work was driven by product oriented engineers. They connect better with the community, they understand the technology deeper. It’s just better.
Before you hire a PM to solve this problem, ensure you've got a culture of user intimacy to build the right thing. This is something I do with companies that I advise. Teach your engineers some basic PM skills to fill gaps. This can go a long way.
Caveat 1 - If you're building the wrong things for your managed product in the enterprise then a PM can help. Engineers can work well with engineers to build great developer tools, PMs need to help package all of that up. Additionally, PMs can help inform this strategy as well, you just can't delegate customer intimacy fully to them.
Pitfall 3: 👩💼Sales - "Let's hire a PM to help run early sales and work with customers"
Some product managers can take on some early sales duties. I did some early sales at Anyscale. If you can find a PM to do it, great. However, these kinds of PMs aren't common.
If a PM is going to be eyes and ears helping a founder on the ground figure out sales - that makes a lot of sense. If it's to scale sales or run a deal process, you're going to need someone with that experience because them learning it on the job is high risk. Hire a sales person when you need someone to run a true sales process.
Caveat - there's a difference between product discovery and sales. Do you understand the problem enough to be selling based on it or are you discovering the actual pain points? Be careful about whether you need to sell or run customer discovery to understand the issues at hand to move in the right direction.
Pitfall 4: 🤔Confused Open Source Users - "We should hire a PM, our open source users are confused about what we're building."
As with Pitfall 2, finding a PM for open source is going to be exceptionally hard. At Databricks, I played that role for a year or two (at least for parts of open source). That was when I had just written a book on the topic and we were well into scale mode. The founders were the ‘real’ visionaries here.
At Anyscale, I could hang, but at the end of the day technical founders and engineers drive the open source vision. PMs can inform that vision, gather data, and make decisions, but engineers should be hugging the open source community.
They can help with strategy, corporate development, help be eyes and ears. But delegating open source too quickly to product management is like to cause more confusion, not less.
Caveat - Equipping early engineers with PM skills is a great workaround. Do this.
Pitfall 5: (Proprietary) 🖼️Product Positioning - "We need to figure out how to talk about our product."
If you're already succeeding in open source and this is just a product problem, then hiring a PM can make sense. However, you might be able to get pretty far by hiring someone for product marketing or marketing.
At Anyscale, it took us a couple of iterations to find the person for marketing (same applies for Databricks). You might need more help here that you think is a PM problem, but is really a marketing problem. PM can help fill the gap for a bit, but you'll have to hire real marketing at some point.
What did this look like at Databricks when I joined and as we scaled?
This is at ~80 people
The founders and early engineers are an exceptional bunch. They had incredible product sense for what needed to be built and how to build it. Spark Summits proved that year in and year out.
During the early time, PM was more focused on packaging and early platform work. Less on ensuring that we're building the right thing in open source - because the founders were so on point with doing that. PMs worked closely with the field and shared information about what was going on.
So much of the success we saw was due to the founding team being so close to customers. They still are. Matei, Reynold, Ali and the other founders and founding engineers just knew the customer's technical challenges better than anyone else.
At Databricks, we had some challenges around what exactly the PM role was / is and this migrated over time as people joined and left.
The founders determined the vision for the product in the early stages. PMs were a data point. PMs got on the ground with customers to ensure that overall we were building the right things (e.g., data gathering, validation, fulfilling checkboxes of founder vision) and that the products we were building were right but it was founder conviction and decision making that determined direction. As the company grew, PMs played a greater role in this process.
It wasn't perfect, but it worked.
What did this look like at Anyscale when I joined and as we scaled?
This is at ~10 people
In the early days, I (as first PM) played the role of sales and GTM. I hired and managed solutions architects and sales people in the early days. I developed customer relationships.
Sure, I helped scope what we're going to build - at least helped deliver customer conversations and requirements. But at the end of the day, I'm not going to tell one of the best engineers in the valley how to build out hardware agnostic distributed systems or to design deep ML tuning algorithms. I can tell them what people need from it, I can help guide experience, but they've got to know what they can deliver and how to deliver it.
I was focused on packaging the product up and working with early customers. Those relationships were key to informing our roadmap and ensuring that we're on the right track. I focused
This was far more GTM oriented than Databricks but this is also because Databricks has many more founders than Anyscale does, so there weren't enough to go around.
My Recommendation ✅
You should push out the hiring of a PM until you've got:
Need help with packaging and some strategy operations because you’ve got something people like.
Needs for moving from open source to a managed service, you've got strong open source momentum and have a clear strategy for how you want to approach building for the next couple of years. You've got a first iteration of the product and want someone on the ground to be close to your initial customers
Need help with founder-led sales and GTM - someone to work with marketing on rolling out the product and sales to ensure that the right product is being shipped. This is anticipation of more formal marketing hires, product marketing hires, and sales engineering hires.
What are the implications or downsides of pushing out PM hiring?
Well the CEO and founder of Linear stated in well in a recent Lenny's Newsletter ...
It means that engineers and designers do have to play the role of the PM, which includes communicating, talking to users and stakeholders. This means that engineers and designers are not purely coding or designing, which can sometimes feel like it slows things down. Personally, I believe often it’s better to go slow to go fast, meaning we generally get projects done right the first time, with minimal fixes later. The second downside is that it’s harder to hire for these roles, as many people don’t have experience working this way.
In the beginning of your startup unless you already have insane traction and growth, you're going to want to speed up iterations and sometimes that means slowing things down.
Make high quality decisions. That doesn't mean move slower. It means move deliberately. Slow is smooth, smooth is fast.
When you have a culture of customer intimacy, it's going to be even easier to hire a product manager to help guide things because the existing organization will be able to (1) evaluate candidates better, ensuring a culture fit and (2) have an appreciation for the role because they've been doing some of the work themselves.
Some broader context on the product management role today…
This section is a bit more for operational nerds but I find it interesting so here it is. Feel free to stop reading if you don't care.
One of the big challenges with product management is captured well by the CEO of Linear.
In other companies, I’d often see that the PM is or becomes the de facto decision-maker for the team. When that’s the case, it’s almost like you outsource all the thinking to the PM, and the rest of the team—engineers and designers—just execute based on that thinking. I think it’s a waste of opportunity and talent.
Do not put PMs solely on the hook for building great product. Don’t make them be the only ones to make decisions or guide the product.
Your team needs to be obsessed over the customer and user. They need to be close to those users, especially at the beginning of your product. If you are outsourcing all the thinking to the PM, you will likely fail.
In my experience, the above is a huge issue in PM today. People wash their hands of responsibility and you end up in a world of finger pointing where PMs, leadership, engineering, marketing - everyone is blaming one another when it's a culture / system problem where thinking is outsourced instead of collaborative.
It's happening at larger companies too
At airbnb, they're redefining the classic product management function. See ~10:40 in the video below.
TL;DR is that Airbnb is moving the PM organization to something more like product marketing and empowering designers and engineers to build product. Sound familiar?
Think about the parallels for open source! What if you were empowering your engineers to (a) be more customer focused but also (b) take responsibility for improving the product?
so what can that look like
That's what Linear has done. While Linear isn't open source, the principle is the same.
Nick, founder of Elementl/Dagster Labs, discovered the same thing.
Builders cannot outsource product thinking and customer empathy to PMs.
Repeat after me.
Builders cannot outsource product thinking and customer empathy to PMs.
Hiring a head of PM who plays more of a GM role for the product makes perfect sense. They understand the business metrics, the growth, the packaging, but individual IC PM style decisions are well delegated to the team. That's empowering for everyone.
We were able to achieve some of that at Anyscale and I believe this style of decision making was one of the reasons that Databricks was able to build such a customer obsessed culture, especially on the open source side. Engineers were not off the hook for making product decisions.
Empower your best to make product decisions, don't just ship the org chart.
Thanks to Srinath Shankar, Cat Wu, and Nick Schrock for reading drafts of this post.