Six reasons your product team isn’t scaling (and how to fix it)

I like product management – and I’m not alone. Many of us got into PM roles through a passion for problem solving and a real desire to see a project succeed in the hands of customers. That’s the fun part, and modern methodologies like Agile are continuously evolving to better support customer-driven products.

What hasn’t evolved nearly as much is how we manage and lead product teams – with ten years of experience in this field, I’ve seen that the way we approach organizing product management is still holding us back.

This isn’t just a pet peeve of mine: recognizing this problem, Darrell Rigby, Jeff Sutherland, and Hirotaka Takeuchi published an article in the Harvard Business Review on the need for management organizations and non-technology functions to adopt agile methodologies.

I want to explore how we manage a collection of product teams operating at scale – because this is the critical topic for organizations that are growing from a single product effort into a diverse range of products, and because finding a better model will frankly restore some of the fun of product management!

I first started thinking about this back when I was the only product manager on a startup product that was doing a couple million a year in sales but was struggling to be more than just a collection of customer features. We didn’t spend a lot of time debating whether to do something – just develop a hypothesis, collect enough data to convince ourselves that we were on the right track, build something small and see if it worked.   At that tiny there are a lot of “ones” – one product manager, one lead developer, one marketer, one sales team, one strategy – and that made us nimble, and very fast, but our overall scale was relatively small.

A few years later I’m at Adobe. The big software development shops like Adobe are right now trying to figure out how to beat startups at the innovation game by developing their own in-house entrepreneurialism, building kickstarter programs, reducing team size and giving product people more autonomy.

At Adobe, we were doing this and we had tons of creative product ideas that seemed interesting, but a limited number of coders and thus an intense focus on prioritization.

When resources are tight, they’re valuable, and when they’re valuable decisions tend to get pushed higher in the command-and-control organization. We had senior vice presidents sitting in all-day meetings officiating over the backlogs of each product, approving or rejecting nearly every plan that required dev cycles in the entire company. This kind of activity provides senior leaders with a feeling of control, but throttles the speed of all that great creative energy down to a crawl.

It also has an insidious correlated effect: smart product managers learn to work the command-and-control system in order to be effective, rather than focusing on market data and customer experience. In short order new product pitches begin to reflect the strategy and bias of internal approvers instead of the market. In big companies with mature revenue streams you can kind of get away with this; in mid-size growth companies it spells certain doom.

What we want is a product organization whose product teams have the velocity of a tiny startup and whose leaders can track investments and drive strategy across whole portfolios of work without slowing anything down.

It may help to think about the solution here in two parts. One: how do you structure a product organization at scale?   Two : what process can you use in that organization to make it effective?

Read on for Part I


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s