It’s very exciting that as a startup, you’re ready to bring on a PM into the organization. Let’s start with some high-level principles first because this question depends on so many factors. I’ll say outright: there is no one right way to do this, and just as you get it “right,” something will change within your org. People will want more definition around roles, and then they’ll want more freedom. Rinse and repeat. So just know: your mileage may vary, and this is all part of the fun :).
1. First, recognize that the role of a PM will differ within every organization. There’s no one-size-fits-all PM.
The fun part is that you can define it at your org in a way that makes sense for your business and product. For example, some PMs act more as GMs responsible for a business line. Other PMs act more as growth leaders with a strong understanding of acquisition or retention strategies. Other PMs will act more as ship-captains who are excellent at defining a destination and helping steer the ship towards it. It sounds like you’ve identified there’s a need for a dedicated role, so start by getting explicit with what that need is within your company, and how you imagine the PM fitting in. What do they need to be really excellent at, and what’s a nice to have? Why do you need this new role right now?
2. Don’t get too stressed about overlapping responsibilities — if successful, everyone’s responsibilities are going to change pretty soon anyway.
It sounds like you work at an early-stage company, which is always fun (and chaotic). Recognize that shifts in roles and responsibilities are part of the territory of early-stage startups. Instead of getting overly specific about roles and responsibilities, I’d focus on clarifying just enough that it unblocks great work. Avoid the intellectual exercise of a perfect spreadsheet of names and responsibilities, because it’ll be outdated quickly anyway.
3. Existing team skills matter! Your team has a specific skill makeup that no listicle can predict.
Ultimately, you know your team. Some designers are absolutely amazing at product strategy. Other designers are more skilled at creating novel solutions to complex problems. Other designers are incredible at building prototypes and doing validation testing. Sometimes the best way to split up roles (and to hire) is based on where you have strengths and gaps on your specific team (and what people are excited about or dreading owning!). One way to avoid overlapping responsibilities is actually to help people be able to focus on what they’re really great at or energized by, and hiring in PMs who complement the skills gaps not covered by the existing team.
Okay, with that said, here’s how I’d break down this question in more detail.
Product development is cyclical and simple, but not easy. Often PMs are responsible for overseeing the full development cycle because building meaningful stuff is complex, and it’s usually beneficial to have one person at the helm who can see the full system in action.
That said, PMs are never working alone in any of the 6 categories of this cycle. Let’s walk through them each so that you can hone in on which areas may lead to the most unproductive overlap for your team.
Figuring out what to build in the first place (Product strategy and vision)
Moving from idea to execution (Prioritization, problem solving)
Executing
Measuring success
Bringing others along (stakeholder management and internal communication)
Building team cohesion, rituals, culture
I’m going to guess that some of these pose concerns for you, and other are less troubling right now. Some of these categories have more obvious overlap (PMs, designers, and engineers are all responsible for execution!), and some have less obvious overlap (PMs tend to be responsible for clarifying what success looks like, but designers and engineers both need that to effectively do their work). This brings me to my next piece of advice.
Once you’ve clarified which of the one or two categories above has the most important overlap, you can clarify roles and responsibilities just enough that it enables good progress.
As a PM, I’ve never worked on a team where it was only the PMs responsibility to figure out what to build. Sure, I may be driving that decision and gathering all the necessary inputs to it, but the rest of my team shares the same overarching goal that I do: to build the right, high-value product for customers and the business.
Am I technically responsible for figuring out what to build? Yes. Am I the only one contributing to it? No. Do I really need to clarify that engineers also have a responsibility to help build the right thing? Not on a high-functioning team.
It’s not that useful to say that PMs are responsible for figuring out what to build. It’s more useful to say that I’m responsible for figuring out what to build, and I’ll do that by involving a lot of people and different inputs…including engineers, designers, analysts, marketers, customers, etc.
Let loosen on the reins of total definition. Instead, focus on the ones where there’s likely heavy overlap. Then, clarify who is ultimately responsible for progress, who is heavily involved, and who is only lightly involved. John Cutler’s got a great visual breakdown of a couple of examples of how this could look, but recognize that they’re just examples.
There’s no shortage of existing models out there of how to divvy up responsibilities. Here are a handful that you can use as a starting template.- Stripe’s model of what a PM does- Coda’s RACI matrix and template- Intercom’s product principles (including that nobody says “it’s not my job”)- John Cutler’s description of The Weeds (three common overlapping areas for eng, design and PM)
Once you’ve got a template you like, then you’ll want to modify things based on what you know about your team and your org. I’ll share some questions to help with that next.
Take this as one person’s opinion, but I’m not a big fan of trying to overly segment roles and responsibilities. It can lead to single points of failure (e.g, I’m the only one who knows how to do this thing because it’s MY role and responsibility) when instead it’s better to build redundancy into teams (e.g, we all know the general premise of how to solve most problems…even if someone else on the team is faster or better at it than I am).
Rigid role boundaries can also be disempowering for a lot of people who are interested in getting their hands dirty in different types of problems. No high-functioning team wins because of roles and responsibilities. They win because they know how to execute well together against meaningful and complex problems. For some, that executing well requires role clarity. For others, they can function much more organically. Neither is wrong.
To gut check your own needs, here are some reflection questions you can ask yourself:
I’ll end by saying this: the best teams I’ve worked on share product, UX, tech, business, marketing, and data as vocabulary that everyone has basic fluency in. We learn from each other, and then we figure out what we need to lean into to execute effectively. With that, my bias is to create the environment where the biggest responsibility — to build a kickass product and learn a ton in the process — is shared. The rest of the roles and responsibilities should be in service to that.
You can apply to a Guided Sprint and we’ll make sure you get the most value out of your coaching experience and being part of our community.
We want to make sure you don’t miss out on any of our free events and career resources, so follow Scale Higher on LinkedIn. Hope to see you at our events soon! 😊