Don’t Ship the Org Chart, Part 1

How do you divide ownership between PMs?

By Ken Norton

4 min read • Feb 24, 2016

Ken Norton

Executive Coaching for Product Leaders with Ken Norton

Get a product-minded executive coach in your corner to unlock your full capacities as a leader

Learn more »

To see a company's org chart, open their settings panel.

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.

Originally Published: February 24, 2016

Ken Norton is an executive coach who works with product leaders. He spent more than 14 years at Google where he built products used by more than 3 billion people.

  • How to Hire a Product Manager: the Classic Essay

    The classic essay that defined the product manager role

    What is product management? What makes a great product manager, and how do you become one? This is Ken Norton's classic essay on the role of product management that launched thousands of PM careers.

  • 10x Not 10%: Bold Product Strategy and Vision

    Product management by orders of magnitude

    In this ambitious essay, Ken Norton looks at the history of innovation and challenges product managers and product leaders to think bigger, to aim for 10x, not 10%.

  • Please Make Yourself Uncomfortable: Jazz and PMs

    What product managers can learn from jazz musicians

    What can product managers and product leaders learn from jazz, an art form that is all about improvisation, collaboration, and being willing to take risks?

  • Best Books for Product Managers [2024]

    Essential product management reading

    Ken Norton shares his recommended books for product managers. The best books on product leadership, innovation, management, shipping winning products, and design thinking.

  • Building Products at Stripe

    Go deep, move fast, and build multi-decade abstractions

    What is Stripe's product culture like? Interview with a Stripe product leader demonstrate an embrace of going deep, moving fast, and maintaining a multi-decade perspective.

  • It’s Time to Fight for a Dual Product Management Career Path

    Companies should embrace multitrack job ladders for product managers who prefer product leadership to people management

    Companies should embrace multitrack job ladders for product managers who prefer product leadership to people management. A concrete proposal with sample career track is included.

  • Ants & Aliens: Long-Term Product Vision & Strategy

    Why you need a thirty-year product vision (yes, thirty)

    How do you plan for the future and deliver an innovative and compelling product vision that will inspire your team to deliver winning products?

  • Building Products at Airbnb

    Snow White, storytelling, and a relentless focus on experiences

    What is Airbnb's product culture like? Interviews with Airbnb PMs demonstrate an embrace of Snow White, storytelling, and a relentless focus on experiences.