I’ve been obsessed with reading articles about product management lately.

There’s so much out there!

Search “how to become a product manager” on Medium and see what I’m talking about:

There are so many articles about product management advice to the point where even the articles that curate articles about product management are too many to count.

What’s gotten me interested in product management?

The more and more I learn about product management, the more I realize that there are similarities between this role and my previous role as an Organization Designer. These similarities then got me to wonder: ok, so what’s different?

For the past three years, I was an Organization Design Consultant at The Ready, where I (alongside some of the best people I know) helped Fortune 500s reinvent their way of working. I played the roles of team coach, facilitator, and even advisor to teams that challenged their current way of working, imagined an ideal way of working, and experimented with different practices, tools, and techniques to help them get there. It was the job that got me to pack my bags and move from California to NYC, and it was damn well worth it.

I want to share eight similarities and six differences that I’ve observed between being a product manager and an org designer.

Keep in mind that these observations come from three years of experience as an org designer and absolutely zero years of experience as a PM. What I’ve learned about product management as of this writing has mainly been from reading, interviewing for PM roles, and having a few close friends who happen to be PMs. I’m sure that once I have more PM experience under my belt, this list would evolve.

Eight ways product managers and org designers are similar

When a PM and an Org Designer both try to facilitate the same team.

1) You’re ruthless about solving real problems.

You often ask “what’s the problem you’re trying to solve?” You have a solid understanding of the principles of lean, agile, and/or human-centered design, and use these practices to solve real problems. You are a ruthless prioritizer. You are outcome-focused, not output-focused. You care about making a positive impact on your customer and business more than the number of features you ship.

2) You know how to run a true experiment.

You know that learning quickly is more beneficial than shipping quickly. You know what makes for a good experiment, and find yourself asking. With your teams, you co-create clear hypotheses about what to build next. You know the dangers of confirmation bias: you care more about proving your hypotheses wrong as quickly as possible, rather than using “experiments” to validate your hypotheses.

3) You can lead without authority.

As a PM, you lead engineers and designers without actually having any positional authority over them (you’re not their boss). As an Org Designer, you’re leading different kinds of client teams — whether they’re a product team with PMs, engineers, and designers, a leadership team, or a coaching cohort who’s mission is to spread new ways of working in their organization. In both roles, you aren’t the manager of these teams and are totally okay with that. You know command-and-control won’t allow these teams to tap into their smarts, leading with trust, bravery, and humility will.

4) You’re always looking to get better as a facilitator.

You’re obsessed with what makes great meetings great. You understand that it’s a leaders’ job to facilitate, not to tell people what to do. You tend to ask questions, write stuff down, and mind the clock. You treat facilitation like a craft. You strike the balance of treating every meeting you facilitate an opportunity to sharpen your craft but ultimately keep the focus on the group as a whole.

5) You’re a generalist (generally).

While you might have deep expertise in a specific skill or subject, you know a little about a lot. You can talk to leaders about what makes good strategy good. You can articulate the difference between good design and bad design. You notice patterns in different subjects and fields, can extrapolate similar principles in different fields, and make connections between seemingly unrelated ideas. And yet you’re eager to go deep and understand every domain’s uniqueness.

6) You work well with folks who have different skills and background than you.

As an org designer, you don’t know everything about the industry of your client. As a PM, you don’t know as much about engineering or UX design as your colleagues. What you do know is how to work with folks who have a different set of skills and background, how to get folks to tap into their expertise, how to help a team be greater than the sum of its parts. You aren’t afraid to ask “dumb” questions. You aren’t afraid to ask what a certain organizational acronym means. You ask your lead engineer to walk you through the technical architecture of your product so you can better understand it. You keep a beginner’s mind.

7) You understand the implications of Conway’s Law.

Conway’s Law states:

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

Or, how we structure teams and teams of teams has a real impact on the products we produce. For example, creating a “platform” development team and an “applications” team will typically lead to a Platform API. Conway’s Law is why companies like Netflix, Spotify, and Amazon structure themselves around small autonomous teams that have a small part of the overall system. These independent teams can own the whole lifecycle of the services they create, giving them a greater degree of autonomy than larger teams with more monolithic codebases.

Whether you’re a PM or an organization designer, you understand that there is a relationship between your team and org design and your product design. And, as James O. Coplien and Neil B. Harrison stated in Organizational Patterns of Agile Software Development:

“If the parts of an organization (e.g., teams, departments, or subdivisions) do not closely reflect the essential parts of the product, or if the relationship between organizations do not reflect the relationships between product parts, then the project will be in trouble.”

8) You learn how to do the job by doing (no matter how many articles you read!).

You get emails and texts from friends about what it takes to get a job like yours, and you have no idea what else to say besides to do the work in their context. You’re adamant about not needing an MBA to know how to do the job. You know that no matter how many articles and books you read, how many workshops you take, how many “brains” you pick, how many meetups you go to, nothing enables you to learn faster than by doing the work and engaging in deliberate practice.

Six (out of many) key differences between product managers and org designers

1) As a PM, you advocate for a clear vision for your product. As an org designer, you help teams co-create that vision themselves.

In my experience as an org designer, I usually remained neutral about the team’s what (what their strategy was) because I coached them on the how (how they would bring their strategy to life, how they test and learn). As a PM, you have a clear vision of your product and are hellbent about communicating that vision to your teams. You know that if you can communicate a clear what, your team will be ready to figure out the how.

2) PMs hedge against indecision, whereas org designers help teams make better decisions.

When I coached teams on decision-making as an org designer, it (typically) was not my role to provide my input towards that decision. My role was to help the team develop their ability to make good, inclusive decisions quickly by introducing different decision-making processes (like the advice process or Integrative Decision-Making), facilitating these processes myself, and helping others facilitate these processes. I supported teams in developing their muscle to bias toward action, not get stuck in consensus, and get the right voices in the room when there was a pressing decision needing to be made.

While PMs can certainly help foster the conditions for their team to make good decisions (I’d argue they should — that’s for a separate piece), in reality, they are often providing their point of view and sometimes making the call themselves. Teams generally look to PMs to help them make decisions for a number of reasons: they have business context, teams are used to PMs making the call, PMs are used to making dozens of decisions a day.

“The decisions PMs make are the ones that unblock their team so they can continue to build. They don’t need to make every decision, but they are responsible for ensuring a decision gets made — whether by them, their team, or their stakeholders. Product managers are the hedge against indecision.”

— Brandon Chu

3) You’re much more data-driven as a PM than as an Org Designer.

While both PMs and Org Designers rely heavily on their intuition, PMs need data to make good decisions about whether their feature that’s intended to increase engagement (or whatever that metric/KPI you’re beholden to) is actually increasing engagement. This is why they often work with data scientists and analysts or know who to use SQL themselves when they need to access data.

I think there’s an opportunity here for Org Designers to use more data (without getting stuck in analysis paralysis). I found myself in my previous role finding opportunities where having data would be helpful, but oftentimes the time it took to get the data my teams and I needed rarely outweighed the benefit of acting upon the information we had (and don’t have) and noticing what emerges as a result of our action to inform what we do next.

4) As an Org Designer, you have the incredible privilege and tough job to coach senior leaders.

As a PM, your ass is on the line with executives if your product isn’t achieving the larger business strategy. You’re often accountable for whether you’re on track with your product roadmap, even when you know you’ll throw out the roadmap out the window once shit hits the fan. Your job depends on you exuding certainty, even when you’re entirely certain.

As an Org Designer, the leaders you work with are bought into changing the way their organizations work. Many have the humility to understand that this requires them to change their own habits and behaviors that even they themselves are used to. Leaders expect you to challenge them and support them in their journey, and this is a beautiful challenge.

5) You (and your product) will benefit if you know a bit about UX as a PM.

You may not necessarily be the one creating wireframes or prototypes on Sketch, but PMs benefit from having a foundational understanding of design. You dance between UX, technology, and the business, and you need to deeply understand your users. That’s where having an understanding of UX comes in.

6) Your end user will differ!

My “end user” as an Org Designer were my clients, which were internal: leaders who wanted to spread a better way of working in their organization, teams who wanted to work more autonomously, cohorts of coaches who would spread the change after our contracts ended. By design, we didn’t interface with our client’s customers.

As a PM, your end users are consumers (or enterprises, depending on your product). Though you have tons of internal stakeholders (executives, your product team, your manager), at the end of the day you’re solving problems for a real, paying customer.

One last similarity between both roles

To summarize, I think there’s one more similarity between both roles that’s worth mentioning:

It’s hard.

I think John Cutler put it best:

“You are in a vague role, expected to cherish the ambiguity. You are thrown into the heart of the organization, and expected to go 90mph (and be a servant leader, and be a shipper, and be a therapist)”

This rings true in my experience as an Org Designer, and I can only imagine it’s a similar (yet different) experience as a PM.

Yet, the difficulty of the job is what makes it fulfilling.

If helping teams ship products weren’t hard, if helping organizations reinvent the way they work weren’t hard, would the job still be worth it?

I’m very appreciative of folks like Kendrick Wang, Willie Tran, Spencer Pitman, and Jody Mak—I’ve learned a ton about product from you.