Blog > analytical skills

Product Managers: How Do You Work on Complex Products?

  • Working in complex environments or complex products are what all Product Managers do.
  • Product Managers at a very high-level manage risks and work to mitigate them.
  • Even seemingly small products can be risky and/or complex.
  • Additional challenges are experienced when the scale is larger or the underlying architecture is large.

Working in complex environments can be challenging.  Working on complex products in complex environments makes it nearly impossible to get one's work done. Trust me -- I've been there.

While here at ProductManagerJobs.com we keep shouting from the rooftops that "no two products or product teams are the same" like a snowflake, we continue to work at peeling away at the art and science of Product Management or some would say the "dark arts".

One of the dark arts of Product Management is that your product isn't just the nice and pretty marketing site or investors deck that you build.  Sure, those always looks neat and tidy but if we look under the hood, we find the layers of layers of processes, documents, conversations, negotiations and burcreaucy.  Whether we thrive in the environment or not, we need to navigate it or else the product you're managing will risk certain death.

Working with Complex Products as a Product Manager

First of all, let's define what a complex product situation looks like.

Here are some characteristics of a complex product setup:

  1. Does your product have multiple "product owners"?
  2. Do you obtain requirements or direction from people people or groups?
  3. Do you have a scrum or agile team that is more than 10 people? (This count should only the core people in your group, like Developers, User Experience Design, Scrum Master, Product Manager).
  4. Are you reliant on teams/people who are subject matter experts outside of your team?  Do you often wait on them for information, need to make requests to them?
  5. Do you have alignment issues with teams outside of your Core team?  Do you often need to communicate timelines to people outside your team?
  6. Do you have to negotiate conflicting standards and provide leadership to come to a decision?

This is not an exhaustive list.  But if you answered 'Yes' to two or more of these, you're likely lucky enough to work in a much more complex situation than others.

Again, not everyone has the benefit of working in an early-stage startup where they get to effectively run the show.  Not everyone gets to start an app in the garage or basement of their parents apartment and sell it to a company for untold millions.  The fact is, we as Product Managers, typically take on the most challenging products, often the product managers who were there before found a better opportunity and left you with the scraps.

One more thing before we move on from the definition of what makes a product complex -- complexity is also existent when the people you deal with are themselves complex.  People -- individuals are complex systems into themselves and put two people on team or in a room and the results are unpredictable.  We must always factor in the human equation too when thinking of complex systems.  After all, product teams are made up of people (at least it still is until the robots take over).

What does Complexity Look like?

 

Complexity is rarely one-dimensional.  Complexity happens when two or more forces act to make the resulting complexity much greater.  It's great than the sum of the parts.

If we look at this sample diagram of complexity, we can see the it extends in two directions:

  1. Scaling Size and Capacity
  2. Handling Technical Debt or Complexity

This might not apply to everyone in every case, but it's important to note that this is something that all product manager face when growing the product or need to scale it appropriate for a larger user base.

Think of a single biological cell.  When you have one singular product team with some influences outside, you can afford to react quickly, make mistakes and get things up to speed.  You're on the same page.

With larger teams as you scale, you'd like to ideally keep the "cell" concept, but that's not always possible.  The smaller teams makes it management but even scaling multiple teams isn't easy as you'll need a culture to be able to support that.  They will also become autonomous.

Likely Problem #1: Cascading Requirements

Requirements are not being told through broken telephone.  If you've ever been to courses so Supply Chain management (luck for you, yours truly has), you've likely played the "beer game" as people often play it Beer as the product.  

The Beer distribution game is like this: 

You play with a 4 players.  You each pretend you own a part of the logistics framework, each taking roles as the manufacturer, distributor, supplier and retailer.  You lose points when you hold too much or too little inventory and you aren't able to communicate to each other what you need or how much to order.  The reality is that you want to keep a small backlog, while still fulfilling orders of your thirsty beer drinkers at the retailer.

The game is to illustrate what is called a "bullwhip" effect.  Small decisions made at the beginning of the chain has massive effects when the end of it causing you to overcorrect or undercorrect, but tough to do to make it the perfect just right (Goldilocks) result.

Complexity is created with these cascading requirements.  The further you are away from the actual production of the widget that more complex it can become.  I would venture to make an inference that creating digital products is similar to this.

Luckily, Agile and Scrum methods have taken their learnings from traditional manufacturing and applied it to software development.  So while we can try to keep the manufacturing or scrum team together, co-locate them, give them autonomy etc., it's still harder when the pipeline and tech stack relies on other teams, other people that's a few teams away.

Likely Problem #2: Complexity from Conway's Law

There's also another way of looking at this through the eyes of the Conway's Law

There is little we can do to not have things permeate to affect the product. Once such situation is the complexity of the organization structure we are in.  Conway who first studied this, provide an observation that the products one creates, eventually becomes a product of the communication structure of the organization.

Effectively, what this Law says that is the way your organization structures is likely the way you're product will end up becoming.

I've had some experience working in complex teams.  I was a product manager for one digital product and it served 2 main business lines or sponsors.  Eventually it grew to a third business and then a fourth.  As we progressed, we diverged in the requirements that were business-specific and as we grew more, the complexity of the side conversations grew to the point where the product did grow into 4 distinct products with each its own product roadmap.

Now, this might just be the fact that when product mature, we go our separate ways but there's no denying that this Law does hold true over hundreds of examples over the years.

Likely Problem #3: Growing Pains

Scale is hard to achieve and the things that one team would do when they are smaller is no longer necessary or needed when things get bigger.  The same goes for the skills of the team -- the product manager who is great at managing a small team and building early-stage products is not the same skill-set needed to run scrum of scrums or need to handle a PO team.