5 Steps to building a "10x" Product Management Team

Recently, there was a popular thread on Twitter talking about “10x Engineers”. It started like this:

And here are a couple of the tweets describing what a 10x Engineer looks like:

The full thread is here for your reading pleasure. And just to be clear, this is NOT satire. It seems that Mr. Kirani was dead serious with his tweets.

Now this blog post is not about criticizing or analyzing the 10x Engineer criteria. Twitter did a good job there. But it got me thinking about the idea of 10x Product Managers and 10x Product Management teams.

I did in fact tweet my own definition of a 10x Product Manager.

While easy to tweet, this is pretty hard to achieve. It’s almost impossible to only focus on the smallest, most valuable tasks and ignore the vast majority of others. And literally getting 10x the results on any initiative compared to your peers is pretty rare.

What does “10x” actually mean?

Let’s start by defining “10x”. Of course, it literally means ten times; so are we talking about someone who puts in 10 times the effort, does 10 times the work, or has 10 times the impact of the “average” person?

That’s clearly not the case. It does NOT literally mean 10 times the effort, output or outcomes of an average person.

So “10x” is clearly a metaphor for a CONSISTENTLY outstanding top performer who succeeds DESPITE obstacles or other challenges.

Now, in all my years working in high-tech, I can think of a very small number of such people. They didn’t deliver ten times what other people did, but they were consistently well above average and often EXCELLED way above others in what they did.

I’ve met some “10x” sales people. They understood how to grow, not just close, deals. They always exceed quota, went to sales club, were at the top of their ranks, closed the largest deals and did it without being overly demanding or arrogant.

I’ve also met a few “10x” engineers. They were wickedly smart and solved tough problems in intelligent, efficient and sometimes novel ways that made the products they worked on measurably much better.

But have I met any 10x product managers? I’ve meet some very good ones, They were smart, hardworking, focused, worked well cross-functionally and made great decisions that enabled their products to overachieve.

But Product Management is a team sport. While 10x sales reps are focused on their individual quota, and 10x engineers are focused on their own code, a 10x Product Manager can only succeed if their product(s) and supporting cross-functional teams succeed.

So instead of talking about “10x” Product Managers, let’s talk about what it takes to create a 10x Product Management team.

What does a “10x” team look like?

Before getting into the details of a “10x” Product Management team, let’s look at an example of “10x” team in the real world.

Now the following example has been used in many contexts, so don’t roll your eyes, but I believe that really understanding what Billy Beane did with the Oakland Athletics (As) gives deep insight into how to create a consistently outstanding and resilient team. So let’s dig in to the details.

If you work in Product Management and haven’t read Moneyball, my question is why not?

If you’ve seen the movie, that doesn’t count. The movie doesn’t get into the nitty gritty details of what Beane actually did with the Oakland As to make them a top performing team.

The short version of the story follows:

Beane was General Manager of a Major League Baseball team that had one of the lowest payrolls in all of baseball. And there was a general belief that you needed to spend money (big money) on the best players (typically top batters and pitchers) to win games and contend for the championship. This is how teams like the NY Yankees, Boston Red Sox etc. operated.

But Beane didn’t have the luxury of a big bank account to spend from. So he had two choices. He could accept that fact that he had a small payroll and accept that his team would never be more than mediocre. Or he could think and act differently, and maximize every aspect of his operation to make the most of his meagre payroll. Clearly he chose the latter. And what he did is the story of the book.

To give some clear context, the following chart shows the total payroll of each MLB team in 2001. You can see The NY Yankees, Boston Red Sox and LA Angels on the left, each with a team payroll about $110,000,000. And second from the right (in red) is the Oakland As, with a total payroll of about $37,000,000. i.e. 1/3 that of the top 3 teams.

And here are the number of games won by each team at the end of the 2001 regular season:

Oakland won over 100 games that season – the second best record in all of baseball, ahead of the Yankees and well ahead of the Red Sox and Angels. And the team to the left of Oakland; that’s the Seattle Mariners. They won a record-tying 116 games, but they had a payroll more than 2x that of the As.

But Oakland didn’t perform well just in that 1 season. Over 12 seasons, from 1998-2009, Oakland spent the 6th LOWEST amount on player salaries, yet had the sixth HIGHEST number of wins. They won their division 4 times, and made the playoffs 4 times in those years. No other team with as small a payroll had any similar kind of record.

What did Billy Beane do differently?

Oakland was the scrappy startup of Major League Baseball that figured out a different way to win. Billy Beane had been a major league player and then a baseball scout for Oakland before moving into management. He understood baseball deeply (had deep domain knowledge) and saw problems with how teams were managed, and decided to find ways to address those problems.

This included every part of baseball management, from scouting minor league players, to making trades, to training and developing minor league players, to how teams and players operated during each game.

In short, Beane took a sport with a lot of long held assumptions on how to win, and turned it inside out. He took a metrics and process optimization based approach to running his organization.

Although Oakland had the same goal as every other team – win as many games as possible – they took a very different approach to hitting that (North Star) metric.

Oakland couldn’t afford amazing pitchers (to shut down opponents’ offence) nor amazing sluggers who could hit large numbers doubles, triples and home runs. So they focused on the statistic called On Base Percentage (OBP)

Traditional baseball thinking was that sluggers (e.g. home run hitters) were a requirement to drive runs in and win games.

Beane took a different approach. To score the most runs in a game, you need to maximize getting on base safely, whether it was a single, double, a walk, getting hit by a pitch etc. Getting on base (e.g. safely to first base) means you didn’t get out. And the more people who can get on base, and promote other players already on base, the more potential to score runs.

It’s a fundamentally different, but clearly logical perspective to take, especially if you don’t have the luxury (and budget) to sign home run hitters.

But it didn’t happen automatically. A batter’s natural instinct is to swing hard at the ball. Oakland taught their batters how not to swing hard, but to work the pitcher to get on base safely. Not hitting the ball and getting a walk, while not glamorous, gave the same result as hitting the ball and running safely to first base.

In that 2001 season, Oakland led ALL TEAMS in both walks (640) and players hit by a pitches (88). Both resulted in the same outcome: getting to first base safely. [1]

In summary, Oakland make a combination of changes to their organization and operation to maximize their wins:

Beane, the General Manager, understood all aspects of the game (playing, scouting, managing etc.)
Oakland had a very clear strategy and process on how to win games (their North Star metric)
Maximizing On Base Percentage (OBP) was their input metric to achieving their goal.
They created a very structured approach to recruiting, drafting and developing young players.
They developed player skills to align with the strategy (i.e. maximizing OBP)
Players who couldn’t adapt were traded or released
They had a metrics/measurement driven approach to how they played games, called plays, arranged their lineup etc.
They continuously improved their processes through a practice of measurement and refinement.

This is what made Oakland a consistently winning “10x” team that performed well above expectations based on how much they spent.

How to apply this to Product Management teams

I hope you can see where I’m going with this. To me, the parallels between what Beane did and what Product Management teams must do is abundantly clear.

Product success comes from getting the right people on the team, understanding their strengths/weaknesses, developing them as needed and then executing on a series of well-defined and continuously improving measurable processes. Do that over a period of time and maximize your chances of continuously achieving product success.

1. Understand what Product Management is

A great team can only be built if there is a clear and deep understanding of what they need to do. In Product Management, this means being consistently effective at driving product success. a leader who clearly understands what Product Management is, what its goals are, and how to define it within the context of that company.

This is critical. Often product leaders (VPs, CPOs etc.) don’t have a clear understanding of what Product Management is. They may have come from a different space (Engineering, Design, Marketing etc.) and often, their view of product management is skewed by that. Or, their Product experience came from companies that had it wrong, and they don’t have any other baselines to work from.

Product Management is often viewed as a “work with Engineering to build the product” function. It’s not. That’s part of it, but far from all of it. This would be akin to saying that baseball is a hit the ball and run sport.

Product Management is cross-functional business and technology management focused on driving product success across the entire product lifecycle

I highlight “cross-functional” because that is the one factor that makes product management difficult and is what is often overlooked, except through lip service statements like “hub of the wheel”. Yes, it aligns with the picture below, but it needs to be embodied in the role in a way that maximizes product success.

The reason this is so important is because without a clear understanding of what product management is, and how it must function, it’s impossible to build a team to execute and deliver what the company needs.

Remember that Billy Beane was a player, a scout and assistant GM before moving into the general manager role. He saw and understood major league baseball from many perspectives. This gave him the insight and vision to do what was needed at Oakland.

2. Recruit and develop the right team

This seems obvious, and in theory it is what everyone should be doing. But in reality it’s generally done very poorly, and it’s actually quite difficult in Product Management.

First, unlike baseball where the game is well understood, the positions are well defined, the required skills are well defined, the players develop those skills in the minor leagues and the game doesn’t change much from league to league, Product Management is VERY different.

Product Management is often NOT well understood in companies, the roles are not well defined, people still struggle in understanding the needed skills, there are virtually no formal education paths to learn and develop in it. Given those factors, how do you recruit the right people?

If you have a leader who understands the function of product management and the benefits it can provide, then she can implement it and deliver benefits to the company as it grows.

Part of the problem is how Product Management evolves in companies. In a startup, a founder (let’s call her Yasmin) typically assumes the figurative “Head of Product” role, driving product vision, definition etc.

Communication and feedback loops are tight, there’s a lot of learning, experimenting, and course correction etc. going on. Things are going well.

As the company grows, some formalism becomes necessary and a full-time Product Manager is hired or promoted from within. Let’s call him Masahiko.

But a lot of startups make a number of mistakes when hiring their first product manager

Masahiko is bright and has been a Sales Engineer at the company for 2 years so has domain knowledge and knows the product reasonably well, but this is his first job in Product Management. Masahiko will take over the requirements gathering/definition and working with Engineering responsibility from Yasmin so she can focus more of her time on a new product idea and helping scale other parts of the business.

This can work, but unfortunately what it does is implicitly define those tasks (requirements, working with Engineering) as the focus of Product Managers in the company. As the company grows, the next PM hire is Anastasia from Customer Support who is making a lateral move.

Anastasia is enthusiastic and has done a stellar job supporting early customers and quickly resolving their issues. She understands the product well and is quite technical. Anastasia is also new to Product Management but wants to learn and grow. Anastasia will help Mashiko by taking on some of the work with Engineering.

You see the cycle. Product Managers are primarily focused on working with Engineering. They often act as “Product Owners” on a Scrum team, or worse, Project Manager/Scrum Master as well, and have little time to do the important work, such as external customer and market research, defining and driving strategy, working cross-functionally with other teams to bring alignment across the company etc.

You cannot be a cross-functional leader if you spend the majority of your time within one part of the organization.

So how should you recruit?

First start by defining roles based on future value and not just immediate need. i.e. they are not just (or primarily) focused on working with Engineering.

Product Managers should be focused on driving future product success. That means:

They need to be able to understand how to perform customer and market research in a systematic and efficient way.
They need to be able to understand business objectives and goals and define strategies to help achieve those goals.
They need to understand how to properly position and message what is being built so that the value can be communicated effectively to the market.
They need to be able to work cross-functionally (internally and externally) to align teams to market, sell, support and implement the products
And yes, they need to be able to work with Engineering to ensure what is built is what is needed by the market.

I often use the following Venn diagram to represent the overall role.

Product Management sits at the intersection of:

Business Objectives
Market Needs
Product Capabilities
Organizational Alignment

This is a broad cross-section of areas and it’s unlikely you’ll find a perfect candidate. Companies often look for a “rockstar” to fill the role. But even if they find someone, it’s not possible to repeat that process for future hires.

Product Management Skills

I use the following high-level categories to outline the key skill areas for Product Managers. The emphasis on each category will vary based on the company, product and market, but these categories can be applied to virtually any Product Management role.

Business & Strategy — product success is the foundation for business success and so a clear understanding of business objectives and strategy and how to align that to your products to maximize results are critical. Analytical skills are also part of overall business skills included in this area.
Domain Knowledge — includes but is not limited to deep understanding of the market state and trends, competitors, customer problems and use cases.
Technology & Design — without being a technologist, technology product managers need to understand the software development process, software architecture, and UI/UX concepts to the level that they can have the needed discussion with technical teams and make good decisions that benefit the business, customers and the product as a whole.
Systems & Processes — PMs should be proficient in key product processes such as discovery, roadmapping, betas, launch etc. Also, as cross functional managers, PMs need to be able to see how and where systems and processes that affect product success can be improved. Are Marketing/Sales working efficiently WRT the product plans/goals; are Services/Support in synch etc. The flow from concept to development to market should be as frictionless as possible. Product Management plays a key role in making this happen.
Leadership and Communication — Without a doubt, the most important aspects for Product Management are the abilities to lead and communicate effectively. Without these skills, they simply become tacticians often at the mercy of other larger teams (and let’s be honest, EVERY team in the company is larger than the PM team).
Other Soft Skills — There are a myriad of other soft skills and abilities that are beneficial to Product Managers. These include analytic skills, negotiation/influence, prioritization, decision making, people management (managing up/down/laterally) etc.

Here’s a sample breakout of how these skills could be applied to the roles of Product Manager, Technical Product Manager and Product Marketing Manager. Note the variance in different categories. Your definitions may vary, but the point is that there are variances based on focus areas and skill requirements.

Companies should hire people with a good mix of skills to address current needs, but train and develop them to improve areas of weakness. This latter part is critical because it’s where most companies fail. They hire smart people and put them into the role but don’t actively assess or train them in their areas of weakness.

3. Define and continuously improve Product processes

This is probably the weakest area I’ve seen across companies. They hire smart people but never formally define processes to follow. When I ask Product Managers which of the processes they use is best defined and is followed consistently, the most common response is “the Agile process”. [The second most common response is “We don’t have process.“]

And when I ask why the Agile process is the best defined process, the reason is that someone else (i.e. engineering) defined it and implemented it and so that’s what Product Managers follow.

Think about that. Why are there no (native) Product Management processes as well defined and followed as the Agile process? All other departments — Marketing, Sales, Support, Finance etc — have processes they follow. Is Product Management so different that native PM processes aren’t important?

If we look back at the Billy Beane’s example, the change they made that had the biggest impact on their success was defining, using and optimizing their processes: how they scouted, how they recruited, how they trained, how they played etc. They measured their success and failure and continuously improved. They had to. And their success didn’t go unnoticed by other teams, who started adopting their metrics-driven practices, but the As continued to improve and stayed competitive with teams with far greater payrolls.

Good process can accelerate success

Process is important. It optimizes how you can achieve results and GOOD processes can bring incredible efficiencies and gains to work that people do.

Now, everyone seems to be hot and heavy on “outcomes” these days:

“We’re focused on improving outcomes.“
“We have a North Start Metric and supporting OKRs.“
“Teams are outcome-driven. They are autonomous and figure out the best way to achieve their goals.“

These statements are all good in theory, but WHAT you do and HOW you do it are critical to efficiently achieving those outcomes.

As a simple example, think of weight-loss. It’s great to have a goal to lose 10 or 15 pounds. But losing that weight is not easy. There are better and worse ways to do it. And it’s not simply losing the weight, but keeping it off that’s critical. Can you figure it out yourself? Possibly. But are there defined steps and processes to follow that will increase your chances of achieving your desired outcome? Absolutely.

The same applies to product processes. They are not trivial by any means.

Customer, market and competitive research is complex. Executing that research efficiently and extracting valuable insights from that research is difficult and yet is a critical to downstream success.
Defining clear strategy and implementing the supporting tactics to achieve results takes skill and effort.
Product roadmaps that support well-defined strategies aren’t simply the result of a few hours in front of PowerPoint.
Creating great positioning, messaging and value propositions for products and using it to align Marketing, Sales and other teams is both an art and a science that few companies do well.
Launching products with impact and sustaining that through customer acquisition and growth in the face of competition and shifting markets is challenging for the best of companies.

To effectively compete and win, it’s critical to define these processes, teach the Product Managers how to execute on them and then measure outcomes and continuously improve.

It’s an evolving process, but just like Billy Beane’s competitors in Major League Baseball, your own competitors will not stand still. It only benefits you to get and stay ahead of them.

4. Create differentiated roles to provide focus and scale

A team is not just a set of players. It’s a group of people with complementary skills who can achieve more together than separately. There are these kinds of teams in virtually every part of the company, but for some reason, you rarely see that in Product Management.

Typically, even in larger companies, the Product Management org is populated by many individual contributor product managers overseeing individual products or sometimes parts of very large products, along with their managers (e.g. Directors, VPs etc.). e.g. something like this:

These organizations vary in size, but each individual contributor product manager has roughly the same focus and responsibilities for their respective products. The challenge with this structure is that it limits the ability to scale because each PM has a broad set of cross-functional responsibilities and they have to effectively time-split across them.

To provide focus and scale to the PM team, it’s important to create differentiated roles and create “mini-teams” within PM when warranted. In the early stages of a product it may be possible for a single individual to manage all cross-functional aspects of a product, but as the product matures and its market grows, so does the complexity in managing it.

It’s best to create differentiated roles such as Technical Product Manager, Product Marketer etc. and build that mini-team focused on going deep to drive product success. The specific RACI for that team can vary from company to company or product to product, but at a high level would look something like this:

The horizontal axis moves from Technical to Business; the vertical axis from Product to Market. The various company functions are placed (roughly) where they intersect on those two axes.

The Technical Product Manager is clearly in the bottom left quadrant, technical and close to the Product working with Engineering, Customer Support, Presales etc.
The Product Marketing Manager is less on the technical but balanced within Product and Market and working closely with Sales and Marketing
The Product Manager is a true product leader focused more on business success but still somewhat balanced between product and market, working most with Executives, Sales, Marketing etc.

These three roles are a singular product team from a Product Management perspective. They provide coverage, focus, domain expertise and allow the team to scale much more effectively than a single individual trying to do everything.

5. Implement Aligned Autonomy for these teams

There’s a lot of chatter on the Web about creating autonomous teams. In short, aligned autonomy means that teams are given difficult problems to solve or objectives to reach, not solutions to implement or actions to execute.

This requires giving the Product Management team the freedom to get out of the office, interact with customers, partners, prospects etc. to understand market, customer and use problems, objectives, workflows and constraints. Once they have this information, they will be equipped with deep insights to work on whatever problems or challenges that will drive business and product success.

Now this makes a LOT of sense, particularly if you’ve hired good people, structured teams, and trained them on good processes to use. Challenge your teams with stretch goals and objectives. This applies not only to your Product Management “mini-team”, but also to the broader product team in general. Use whatever framework (OKR, North Star Metric etc.) is appropriate.

The following video gives a good explanation of the concept.

This step is critical. A great team (on paper) that isn’t aligned on a common goal will never succeed. They will diverge and work at cross-purposes to each other. Having common goals and share commitment to those goals is what will ultimately enable team to perform at their best.

Think of every “team building” exercise you can; whether it’s an escape room, whitewater rafting, or constructing and racing a cardboard go-cart (I participated in that one once). They all have one thing in common. They align the team members on common goals and team members work cooperatively to find the best solutions to the challenges given to them.

There’s no reason not to apply that same approach when the people return to the office.

Summary

So here are the 5 steps mentioned above:

Understand what Product Management is
Recruit and develop the right team
Define and continuously improve product processes
Create differentiated roles to provide focus and scale
Implement aligned autonomy for these teams

Clearly this is not simple nor is it something that can be implemented in short order. No team goes from 1x to 10x immediately, and it’s not a step function. Continuous improvement and active involvement by product leadership (Directors, VPs, CPOs etc.) are key.

Product Management’s cross-functional role is central to product success and company success. And by working to create high performing teams, companies have the opportunity to accelerate that success and stay ahead of competitors.

A little feedback please

Since you’ve read this far, why not give me a little anonymous feedback on the article. 3 short questions, it’ll only take a minute, and it’ll put a smile on my face. What could be better than that? Click here.

Saeed Khan is a founder of Transformation Labs and has worked for over 20 years in high-technology companies building and managing market leading products. He speaks regularly at industry events on the topic of product management and product leadership. You can contact him via Twitter @saeedwkhan or via the Contact Us page.

[1] https://www.baseball-reference.com/leagues/AL/2001.shtml