Now Serving 1 Billion Stakeholders

How to develop products in a large company and remain sane

Photo by CHUTTERSNAP on Unsplash

(I wrote an original version of this post to my teams at work about 2 years ago, but the lessons apply to any large, distributed organization. I’ve edited the original to be more concise.)

Oh my, you’ve grown

As a company grows in size, the number of dependencies and distributed teams fundamentally changes how a product manager needs to approach communication.

In a small team or company you may be able to simply agree on something between 5 people in a room and execute. Everyone has shared context and can verbally hash out disagreements and opinions.

As a company reaches scale, with distributed teams and increasingly specialized cross-functional members, the methods you use to reach consensus and communicate must also scale. Otherwise you will find yourself repeating the same thing over and over, and likely being blocked repeatedly along your journey.

I’ve seen teams struggle with this transition, and only came to consciously understand the issue myself by observing it a few times. Here are a few lessons I’ve learned on communicating and gaining alignment when developing a new product in a large organization.

1) Written, not verbal, communication

This is the key difference between ‘5 people in a room’ and scalable teams.

With a small team, for many decisions you can update and explain your plans verbally and save yourself the effort of more documentation. However, once you get beyond a small group, or expand beyond one office, verbal communication has to be augmented with documentation because you won’t have the time to explain everything repeatedly across people, offices, and timezones. You can try, but you will quickly find yourself exhausted and frustrated.

(BTW, even with a small team documenting is key. Otherwise, you risk countless episodes of 3 blind men and the elephant.)

2) Explaining ‘why us, why now’

When you start out on a new project, communicating the ‘Why’ is more important than the ‘How’. This is particularly true in a larger organization which lacks shared context. I often see teams jump into a solution and try to get approval to pursue a solution before they’ve got buy-in on the ‘Why’.

3) Sell your vision with shareable storytelling

With a new product, you are often creating a vision out of nothing. As a PM, you need to paint a vision of the future you will create. This means telling a compelling story, describing a product and user journey that everyone wants to build and use.

For scale, it is critical that this is documented and easily shareable. When someone asks what this project is all about, you should be able to send them a link and follow up verbally later.

4) Does your product manager lean towards vision or execution

At the risk of oversimplifying, I’ve observed that PMs naturally fall into two categories: vision oriented and execution oriented. Those who are good at creative vision are often weak in details and last-mile execution and vice versa.

As organizations grow, you’ll find more of the execution types because that’s what’s required to run a large machine. Both capabilities can be learned but a manager shouldn’t just expect one type of PM to be good at the other. As a manager, think about your team makeup and coach accordingly.

5) Working through complex decisions

In addition to documentation, this is the second-biggest difference between small and large organizations. At scale, decisions get more complicated.

As a PM, much of your job should be to think. To think about options, tradeoffs, and future scenarios. Yet the best ideas are the result of multiple perspectives, and the larger a project you work on the more people you will need to align to your goals. Complex decisions with no clear answer often trip people up. Here a few things I’ve found helpful:

1) Break a problem into workstreams

If a project or topic is sufficiently large or complex, break it into workstreams. Tackle each of these with their own timeline and milestones. Communicate that rough timeline and when you’re targeting to answer certain questions by.

2) Gather and share data

Get everyone on the same page about the data. This may be industry metrics, product metrics, etc. This is a critical and often rushed aspect of complex decisions. Spend the time to ensure stakeholders have a shared understanding of the situation before jumping into solutions.

3) Slides, docs, both? Choose the right one

Slides are great tools for guiding a live discussion. Documents are great tools for asynchronous commenting and longer-lived decisions. In both cases your goals are similar:

  • Structure data and thoughts around a topic
  • Guide a group through a complex topic or decision
  • Communicate plans and decisions in a more scalable way than 1:1s meetings

4) Lay out options

Lay out the options you could take and get people up-to-speed. Some issues require more time for a group to discuss in the beginning — know where you are in the cycle before rushing to ask for a decision.

5) Assert an answer, forget your ego

Assert an answer and back up with reason and data.

By asserting an answer your audience will be more likely to react and engage because they may disagree. It’s ok to not go down the asserted path! The point is not to be correct in your answer, the point is to generate robust discussion and move closer to a final answer.

To this end, use and abuse ‘The Strawman’. This gives egos an out and helps the group understand this is a draft answer, not final. The floor should be littered with the hay of those Strawmen whom the team has torn up. That’s their purpose.

6) Identify the stakeholders

Identify who needs to be in the decision process. This isn’t always simple to answer because it depends on a number of factors: topics, team size, dependencies, maturity of project, and importance of the decision, to name a few.

7) Make decisions: Impact and Reversibility

A useful heuristic for decisions uses two axises: Impact and reversibility. If a decision has a small impact and/or is reversible, make it quick and with a minimum of stakeholders. If it has large impact and/or is irreversible, then take more time with wider buy-in.

8) Document decisions

Lastly, document decisions and the reasoning behind them in a place the team agrees upon. It could be in your PRD or a decisions log. You’ll thank yourself in the future when a question comes up, possibly by someone new or who doesn’t have context.

It takes more effort

There’s no denying that doing new things is harder in a large organization — there are simply more people, more dependencies, more consequences. But there are advantages too — more perspectives and more hands across which to spread the work!

Regardless, the end goal is the same — build a great product and ship it.

Good luck.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store