**By [Ken Norton]
https://www.kennorton.com/newsletter/2016-02-24-bringing-the-donuts.html

Ken的文章講得是公司大的架構(gòu)，其實(shí)在小的項(xiàng)目里面也是同樣的問(wèn)題。

1. 把軟件模塊按照公司組織架構(gòu)細(xì)分。誰(shuí)對(duì)最后的產(chǎn)品功能負(fù)責(zé)？
2. 出了問(wèn)題，誰(shuí)對(duì)問(wèn)題定位？問(wèn)題是在設(shè)計(jì)，硬件，軟件？
3. 添加功能，需要很多人才能解決，還是少數(shù)幾個(gè)人就行。工作的效率問(wèn)題。

image

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 “l(fā)ightning 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.