The Problem with Product Management

No surprise, it's a people problem. And a structural one. (#51)

Two words come to mind when I think about the definition of a product manager: Architect and Craftsperson.

Architect: A person who plans, designs and oversees the construction of buildings.

Craftsperson: A person who is skilled in a particular craft; an artisan.

I found this article on architecture quite interesting and relevant:

Architecture has come to be seen as a profession somewhat removed from the actual act of building. Practical knowledge previously gained from experiential learning and apprenticeship has gradually been replaced by theories about technique and form. This distinction between designer and builder has created a role for the architect that is somewhat akin to the conductor of an orchestra, who is charged with using Big Picture thinking to create the plan that everyone else will follow. Although this reduction of the architect’s role in the overall process has led to more theory and art, and less hands-on production, there is no doubt that the architect must still maintain an understanding of and connection to the materials of which any structure is built. A great architect is both a designer and a craftsman who has a decent understanding of every step of the building process, human behaviors and patterns, precision engineering, and a lot more… Their agenda is not personal expression, but rather to achieve the highest level of form and function. They have a deep respect for design processes and for the journey itself, not just the result.

A great architect is both a designer and a craftsman who has a decent understanding of every step of the building process, human behaviours and patterns, precision engineering and a lot more.

That sounds a lot like a product manager.

What the heck is product management, anyway?

People struggle to define product management. Companies define the role differently, making it even more confusing.

This is what you’ll find on Wikipedia:

Product management is the business process of planning, developing, launching, and managing a product or service. It includes the entire lifecycle of a product, from ideation to development to go to market. Product managers are responsible for ensuring that a product meets the needs of its target market and contributes to the business strategy, while managing a product or products at all stages of the product lifecycle.

That makes sense, but there’s a ton to unpack there.

• Designers design (agreed!)

• Developers develop (yup!)

• Product managers … ? (oh fuck)

There’s a common belief that product managers are influencers, but not owners.

Most of the time people don’t report to them, so they can’t tell people what to do. Instead they have to cajole, guide, influence, etc. Two things:

1. Does it have to be this way?

2. Does it surprise you that companies are rethinking product management?

I’m not suggesting product managers be put in charge or have design and/or engineering reports, but influence isn’t enough.

Tell me if this sounds familiar:

1. Two founders start a company (say one is the CEO and one is the CTO).

2. CEO owns product initially, but as they get traction and raise capital, they decide it’s time to hire more people.

3. They start by hiring a few more engineers and a designer. The CEO still owns product, but she’s also raising more funds, doing sales, managing the contract bookkeeper and accounting, dealing with partners, etc. The company is divided into two buckets: Tech and Everything Else.

4. The company raises a big round and goes into a hiring blitz. The CEO needs to delegate. She hires an executive leadership team to take over marketing, sales, operations and … product. Her job is now managing “all the things” but through the people she’s put in place. And now there are departments, which eventually become silos.

5. With more people, more projects are spun up. “Imagine what we can do with 5 more engineers,” the new VP Engineering says. The VP Product pipes up, “I need 4 product managers to do everything on the roadmap.” The CEO is committed to empowering her people so she approves the spend. Eventually someone says, “We need to reorg too.” That’s a good point. With all these people we can’t just have Tech + Everything Else. We have to onboard new people quickly and put them on teams in the right way so they hit the ground running.

6. After a period of time (give it 6-12 months) of excitement and ramping up, the CEO notices that things have slowed down. There are more people doing more things but less is being shipped. She’s receiving a bunch of reports, and she checks in weekly with her executive team, but she’s honestly not quite sure what’s happening in each department. She can’t tell who is making decisions or if any decisions are being made at all. People aren’t completely transparent with her. Product blames Engineering and wants more control. Engineering is tired of debating with Design. Sales wants to own the roadmap. Marketing wants to implement a complex attribution system so they can count the leads they generate. The CEO remembers the days when her and the CTO had an idea, validated it quickly with users, built it overnight and shipped it. She remembers when speed was her only legitimate competitive advantage…and today? She’s not sure.

This isn’t a teardown of raising capital (although one might argue that raising too much too quickly leads to a lot of trouble). It’s the classic problem of scale. In the story above what’s also important to recognize is that even while the CEO starts to notice issues, she’s so busy managing things she can’t get into the weeds. On top of that everyone is still coming to her and asking for more headcount.

If the answer to every problem is “hire more people” you’re doomed. ☠️

Everyone that’s built a startup from a few people to hundreds will tell you that things “fall apart” as they hit major milestones in team size. In my experience when you go from 0 to 20 employees things get difficult. It gets worse from 20 to 50, or 50 to 100. If you go from a couple founders to 100 employees quickly the strain is incredible. I can’t imagine what it’s like going from 100 to 500 employees, or 500 to 1000, etc.

I’ve experienced the rapid employee growth problem a few times.

At VarageSale we went from ~20 to ~100 employees very quickly after raising $30M. We were in scale mode, hiring developers, designers and product managers. The coordination and management of the people was a near full-time job, which didn’t leave a lot of time for figuring out the product roadmap, making sure we were prioritizing properly or being able to take a step back and see the “forest from the trees.” Not surprisingly, everything slowed down. We were spending a ton more money but not making enough progress. Shipping new features was a struggle. Politics emerged. Tensions bubbled between teams. We did off-sites (sigh). The founder got frustrated and decided to step back into product and tech. Etc. And that’s only with 100 employees! (btw, we still managed to ship some amazing stuff which I’m still proud and happy about, but the grind is real.)

VarageSale’s team structure

We had a handful of cross-functional teams (each w/ product, design, engineering & QA), and each team focused on a part of the customer journey; i.e. Acquisition, Activation, Retention, Monetization.

The product manager on each team was the team lead. We told teams that this didn’t have to be the case but it’s the way it went, although some of the designers wanted to lead or co-lead. The team members didn’t report to the team lead in terms of their career, performance reviews, etc. but they were held accountable by them for their work. We also had “guilds” (i.e. the tech team was a guild that would collaborate around best practices, new tech, etc. and report to the VP Engineering).

I thought the structure worked reasonably well, but keeping everyone coordinated was a challenge. In some cases there was tension around which team owned what. It’s not always easy to define whether something is tied to “activation” or “retention.” Certain features played a role in both, so teams stumbled into each other intentionally or otherwise. This was true in terms of ownership, responsibility, accountability and in the code base.

We wanted teams obsessing over specific aspects of the user experience with key metrics. The activation team knew they needed to get more first time users engaged quickly. The retention team knew they were measured on repeat usage. But it was far from a perfect system. I’d be open to trying it again, but I’d also want to experiment with other approaches. There’s no perfect system.

Other startups I’ve worked with have similarly slowed down and found themselves meandering. It’s usually around the time that the founder/CEO steps out of the day-to-day execution work. One founder I know quite well told me, “Every time someone came to complain about something the request was, ‘We need to hire more people.’ We had the capital, so I agreed.” They’ve since gone from ~100 employees to half that. And they’re moving 5x as fast.

No one will ever care as much as the founder or be as decisive

At some point, founders realize that no one will care as much as they do. When it’s a small team that’s not the case, because everyone is “in it together” trying to win. There should be no politics, bullshit or anything else in a 5-10 person company. Everyone should be perfectly aligned and the cycle times between the founder and the team are so short everyone feels like they’re 100% part of everything.

But that’s a moment in time. As the company grows, people still join because of the mission, but they’re not as connected. They’re focused on their own career path (which is completely reasonable!) and optimizing their own success. The company they’ve joined is winning or has already won (or that’s the perception), and they want to help, but also ride the coattails. Again, this is completely understandable. I don’t begrudge anyone for this, except founders might not fully realize it’s happening. They’re still climbing the mountain, striving for the top, with a “never say die” attitude and a “we haven’t won, we’ve only begun!” perspective. Except as they add more people, they’re dragging a much bigger (more complex) weight behind them.

As teams grow, decisions get more complex.

Who is actually in charge? Who is accountable? Who makes the tough choices? The CEO is delegating so she’s encouraged her leadership team to encourage their teams to be more decisive. But team members are hesitating because they don’t want to step on people’s toes (the culture is collaborative after all!), or they don’t want to stick their necks out and make a mistake (even though the culture says it encourages experimentation, does it really?)

Product managers get particularly caught in the crossfire. Product CEOs bring in product managers under the belief that they’ll lead product and make decisions. But product managers don’t have direct reports. They’re influencers, remember? So instead product managers rely on frameworks and process to make the decisions for them. This is where Lean, Agile, Scrum, A/B testing, metrics, etc. come to the forefront. None of these are bad—except when used so rigidly that all instinct is removed. When that happens, product managers become project managers, further enforcing the belief that they’re not builders and shouldn’t have a say in what gets done (except for managing the timeline).

When data rules everything, product managers worry that they’ll never have enough to make the right decision. So they hesitate even more, slow things down, and try to follow a strict process that surely will spit out the right answer. Right? Right? Please be right…Product managers lose their ability to use their gut or conviction, to have a craftsperson’s artistic flair.

Everyone wants to build great products, but we don’t agree on how

The crux of the challenge is that no one has a perfect solution for building great products. We have a bunch of ingredients, but no defined recipe for exactly how much of each to use. Here’s how I think about this dilemma:

• We need quantitative data; but we also need qualitative data

• We need to listen to the customer; but the customer isn’t always right

• We need process to scale how we build product; but if we follow a process blindly we’ll fail

• We need a vision; but we also need to figure out how to get there

• We want to experiment; but we’re scared to be wrong (let’s face it, no one gets promoted for failing all the time, even if they’re learning a lot)

• We want a culture of collaboration; but taken to an extreme and we’re not sure who is steering the ship anymore

• We want to be empowered; but we also like being given clear direction

• We want to empower employees; but we need them all rowing in the same direction

• We can’t rely exclusively on the craftsperson’s flair of the CEO; but the CEO was the person with the original vision

• We need more people to achieve scale; but the more people we add the harder everything gets

• We need product managers; but we’re not sure what they should be doing and what they should own

Founders are stepping back in

Recently there’s been a lot of hubbub over companies such as Airbnb and Snapchat restructuring product management.

These companies are not eliminating product managers. They are trying to solve for the problems they’re facing (mostly speed of decision-making & execution) by evolving the product manager role.

Founders are rejecting the blanket, generic advice that they need to delegate everything. Instead they’re saying, “Nope. I know what I’m doing and what I’m good at, and I need to get back to that.”

I applaud the shift.

In one of the best podcast episodes I’ve ever listened to, Brian Chesky, CEO/co-founder at Airbnb talks about the changes at the company. I encourage every founder, product manager, startup employee and investor to listen to this episode.

About 31 minutes in Brian says something that I 100% believe in, which is that CEOs/founders need to be in the weeds. Founders start in the weeds and everything is successful (or not) because of them. Then they scaled, hired a bunch of people, created hierarchy and got out of the details. Result: the company slowed and stumbled. Get back in!

Brian beautifully articulates the difference between being involved in the details and micromanaging. He needs to be in the weeds to drive alignment. He needs to be in the weeds to give the team (which is still 7,000 people!) access to his vision and how he believes the company should operate and execute.

It sounds like Brian now has the whole company aligned on a single roadmap, with new team structures (organized functionally) and rowing together. It took two years. And it’s only possible because he stepped in as the CEO/founder and took charge.

5 Things I Believe Product Managers Should be Doing

Product management is a tough thing to define. But here are five things I believe every product manager needs to have a chance at being successful:

1. You have to build product. Back to the definition of an architect-craftsperson; if all you’re doing is coordinating others, you’re not a product manager. You have to be able to craft something, which means you have skills related to building, including defining and clarifying scope, prototyping, mapping systems, etc.

2. You care deeply about the product you’re building. This isn’t a requirement for everyone, but for product managers it’s important. You’re channeling the founders’s vision, trying to mold hunks of clay into something valuable. The nebulous nature of the role requires a level of caring that drives inspiration and willingness to make bold bets. You have to stand for something.

3. You understand the product deeply. Use the product you’re building. Get to know all its nooks and crannies. Find where the skeletons are buried. Your job is to understand it all and connect the dots between engineering, design, customer service, sales, etc. That way you can problem solve and adapt the roadmap when a developer tells you something is going to take a month. Or you can articulate clearly to a salesperson why a feature is being built a certain way. The worst product managers point fingers at everyone else and say, “Ask that team.” That’s not product management.

4. You use the right level of process to keep things moving. Process zealots kill companies. But you can’t just fly by the seat of your pants either. You need to achieve the right balance for how your company is structured and does things. That means having a big toolbox at your disposal and using the right tools for the job. I’ve never seen a product manager (or a VP Product) go from one company to another, deploy the exact same process/toolkit and be successful. That doesn’t mean process is bad, it means you have to adapt company by company.

5. You need the stick as much as the carrot. Product managers that only use carrots will fail. You can’t reward, cajole and influence your way to victory because it gets too complicated. Things slow down too much. At some point you need a stick. If you don’t have access to a stick (because you’re not allowed to use one) then you work at a company that doesn’t really appreciate product management. IMO, founders/CEOs that step back in and take an active role in the details are, initially, using a stick. They have to apply pressure and reestablish how things are going to be done. You can’t do that delicately.

Companies need product management and product managers. I don’t love the title “product management” but I haven’t come up with anything significantly better. Perhaps “product builder” although that is also nebulous (compared with designer and developer). Or maybe, “product architect.”

I’m comfortable with a degree of ambiguity because it’ll always exist in startups. Instead of railing against it and trying to put product management in a perfectly defined box, I try and stick with the core principles defined above and recognize quickly when things are slowing down. The worst situation is when your startup is scaling and you don’t identify the problem quickly, or you ignore it, hoping it’ll go away. It won’t. If things are slow now, regardless of your startup’s size, they’re going to stay slow. Get in there and fix it.

---