In a previous newsletter I laid out how product management organizations tend to evolve as startups grow. Today I’d like to share more about what I called “PM Two” – how do you split up responsibilities between multiple product managers?

It’s tempting to carve up the product in ways that line up cleanly with engineering. For example, one PM owns the front-end and the other owns the back-end. Or an iOS PM, an Android PM, and a desktop PM. The benefits here are obvious: each PM takes over a discrete chunk of the architecture, and they probably link up well to tech leads and individual engineers. Perfect, right?

I want you to resist the urge to do this. Who is singularly accountable for the customer experience of the new account signup process, the front-end PM or the back-end PM? It’s a little bit of everyone. And that’s the problem. Inevitably these seams lead to friction and start to show through in your product:

“Organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.” – Melvin Conway

(The title of this newsletter is Steven Sinofsky’s delightful rephrasing of Conway’s Law.)

Organize your product managers around customers, not code repositories. Connect PM areas of ownership to users and their product experiences. Maybe you have a buyer PM and a seller PM instead of back-end and front-end PMs. Or in a healthcare company, you’d have a PM responsible for the patient experience and another for the medical providers. When each PM has discrete ownership over an experience end-to-end, they can understand the customer problems more deeply and go all-in on representing their needs. This is doubly important for companies where PMs need to spend time face-to-face with customers, such as enterprise startups.

Here’s another test: how many PMs need to be in the room? When I work with startups that are experimenting with ways to organize their product team, this ends up being a decisive test. Envision a feature you might want to build, such as rescheduling a doctor appointment. How many PMs need to be in the room when you talk about this feature? How many deciders? Is it one patient experience PM who has the final say? Or an iOS PM, an Android PM, an account system PM, a web PM, and a backend PM… you get the point.

It’s true that aligning your PMs with the user’s view of the world can be messier in other ways. The development work is likely to cut across product surfaces – both the patient and doctor PMs will need something from the iOS engineers, for example. Who takes priority? It’s important that as an organization everyone knows what the priorities are or this gets decided case-by-case in tiny inconsistent transactions. Having this conflict upfront is a feature, not a bug. It’s more desirable to hash this out before engineers write a line of code. You’ll need a good process to make quick prioritization decisions to avoid randomizing your engineering team.

Recently many startups have also tried orienting their PMs around shorter-lived themes or missions, such as “a one-click dinner reservation experience” or “lightning fast photo uploads.” The benefit here is a crystal clear goal that lines up with a customer problem, but it has the potential to generate serious thrash on the engineering side. At a minimum make sure there is at least one dedicated engineer and designer on each mission team.

My last piece of advice when adding that second PM: know that this is temporary, and you’re going to have to change it again. As with any re-org, the biggest mistake you can make is assuming this is the re-org to end all re-orgs and you’ve achieved perfection. Keep track of what’s working well and what isn’t, and be willing to change and adapt based on what you hear from the team. Remember that you’re building a product and a company.

See my follow-up: Don’t Ship the Org Chart, Part 2

Good Reads

What is the best advice you were ever given? This question has been asked again and again on Product Hunt LIVE. The PH team has compiled some of the best answers from startup people, including my own (“Write your resume 10 years from now”).

“If you have half the time to accomplish something, you become hyper-aware of how you’re using that time.” Peter Bregman explains why 30-minute meetings are magical. I also recommend switching from 60-minute to 30-minute meetings in my essay, Meetings That Don’t Suck.

It’s the intersection of business, technology, and user experience, according to Martin Eriksson, who just reposted his influential What is a Product Manager? piece on Medium.

Ask your team: “What do we know to be true?” Mike McCue, Flipboard’s CEO, shares a story from his days running Tellme Networks when the company was faced with an existential crisis. After much angst, he boiled the problem down to first principles and the decision became obvious.

Allowing yourself to be guided by first principles, according to Julie Zhou, is a characteristic of someone with creative confidence. (Creative confidence is an important contributor to what I call Product “Spidey-sense.”) As Julie writes, “A person with creative confidence… understands and accepts that uncertainty, false starts, and mistakes are part of the creative process, but she also projects a sense of stability and progress to those around her.”

“We’re looking for people who have gotten over themselves.” That’s Gregg Popovich, legendary coach of the NBA’s San Antonio Spurs explaining what he looks for in players. He might be talking about basketball, but his advice is golden for any kind of team. “You can talk to somebody for four or five minutes, and you can tell if it’s about them or if they understand that they’re just a piece of the puzzle. So we look for that.” Get over yourself. And Go Warriors.