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 :).

Some principles around PM roles and responsibilities

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.

First, name the categories of PM and PM-adjacent work that could be culprits

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)

1. Vision setting and storytelling
2. Feature opportunity validation
3. Qual and quant research

Moving from idea to execution (Prioritization, problem solving)

1. Clarifying priorities
2. Understanding and mitigating risks
3. Scoping what needs to get built in order to effectively “handoff”

Executing

1. Managing milestones and timelines
2. Scoping, speccing, triaging, testing
3. Unblocking work

Measuring success

1. Setting goals and team plans
2. Articulating measures of success
3. Tracking progress against strategic goals

Bringing others along (stakeholder management and internal communication)

1. Managing up, down, and across, especially if other teams are involved
2. Setting clear expectations and delivering against them
3. Communicating priorities and status updates

Building team cohesion, rituals, culture

1. Determining how work gets done
2. Becoming a learning team together v. a feature factory
3. Internal skill building and sharing
4. (For PM managers: headcount allocation and resourcing)

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.

Focus on one or two big categories of overlap, clarify only the ones that inhibit meaningful progress.

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.

Use the myriad templates out there as a starting point, then modify

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.

Recognize your team’s humanity — rigidity ain’t for everyone.

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:

• What are clarified roles and responsibilities in service to? Are we actually stepping on toes right now? Are we struggling to make decisions effectively? Is there a fraught relationship between engineers, designers, and product managers on a team…and we want role definition as a way of removing that tension? Are our meetings chaotic and unplanned because there’s no clear leader or driver? Clarify what you’re trying to solve by formulating clearer roles and responsibilities. High-functioning teams are able to navigate these things effectively on their own by clarifying a decision-maker when necessary without being overly prescriptive about who owns what. That’s because they have established trust and rapport to have these conversations effectively.
• What is the stage of our company and/or product? Are we early stage enough that it’s all hands on deck for a single product line finding market fit? Or do we have multiple product teams working in parallel on related but independent features? Often a leader’s desire for clearer roles and responsibilities comes from a place of wanting to have control rather than wanting to provide real strategic clarity. Avoid this trap by asking “what hats or roles do we need to play for now, knowing that they’re liking to change as we make progress?”
• Do I need to clarify, or can my team work it out on their own? It’s a common leadership failure mode to require your team to function in the exact same way that you might if you were an IC. Double check that this is something that you need to own versus something that you can let the team figure out organically.
• If I do nothing (we keep the status quo), what really breaks…and how bad is that? If nothing else, this is an important question for your decision-making process. You may find out that there’s something really important that you’re missing, or that it doesn’t matter all that much.

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.