Don’t Ship the Org Chart, Part 1

How do you divide ownership between PMs?

By Ken Norton

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.

What’s it like to move from user research to product management? Mateo Rando, a PM at Spotify summed up what he’s learned. Like anyone moving into PM, he brought with him both strengths and blind spots. It was interesting to match these to my own experience coming from engineering. For example, one of his strengths – comfort working cross-functionally – didn’t come naturally to me. Just goes to show that product management is a melting pot of skills from across the organization.

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 spent more than fourteen years at Google where he led product initiatives for Docs, Calendar, Google Mobile Maps, and GV (formerly Google Ventures).

  • 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?

  • 44 Best Books for Product Managers in 2022

    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.

  • 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?

  • Meetings That Don’t Suck

    Break free from the tyranny of the conference room
    Most meetings suck, but it doesn't have to be that way. Ken Norton shows us how to break free and unsuck our meetings.

  • 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.

  • What Makes A Strong Product Culture?

    How a company's view of technology, product leadership, and empowerment contribute to product success
    Strong product cultures can produce winning products. They're places where product management is practiced (as we define it), where it is valued by the business, and where PMs can thrive and grow.

  • 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.

Executive Coaching

If you are interested in growing as a leader, I offer executive coaching. Schedule a free exploratory session.

Learn more »