Building and Scaling a Product Org (with an Emphasis on Enterprise Tech Companies)

Why do we need product management?

Product management is a semi-scientific process to create a product that takes into account engineering capabilities, customer desires, and profitability – finance knows how to make money, engineers know what they can build, and sales know what the customer asks for. Product managers provide a central point to combine these perspectives and champion building software the world wants and will pay for.

Product management is most important for companies building software to sell it – plenty of software is made with no intention to sell it—at government agencies, for internal use, or at companies that aren’t software-first (e.g. airlines). If you don’t have to sell software, quality and market fit don’t matter as much and there is less need for software product managers.

Avoid disorganized development – your CFO, CEO, and Head of Sales each believe they know what the market wants, but they have significant sampling biases. Product managers bring discipline to the process.

What are the core responsibilities of product management?

Product managers switch between three lenses:

Desirability – product pulls together many conversations with potential users to discover and prioritize ideas. Most of the time, potential customers don’t know what they really need, so product proactively draws out root issues and problems from customer complaints or seemingly-simple suggestions.
Feasibility – with an idea of what the market may want, product managers work with engineering and design to figure out what’s feasible and realize the best version of the product.
Viability – what is the user’s willingness to pay? Are there enough potential customers? When the numbers are crunched, is this a profitable enterprise?

Key product activities include:

Discovery and validation – before committing expensive engineering, product does a lot of homework to gauge how good an idea is. In partnership with design, they talk to many prospective customers — clarifying problems, showing sketches, asking a lot of questions, and trialing prices. Even though we get emotionally committed to our ideas, most are not what the world wants – or will pay for.
Prioritization and roadmapping – in a typical company, the stakeholders will never agree on strategy. So rather than cajoling them into agreement, it’s about coalition-making and alignment – driving and pushing until there is a plan. Sales wants whatever they heard about this morning; marketing wants something that will get headlines; engineering wants to fix technical debt; support wants all effort against current bugs. Product sits in the middle and creates a balanced plan.
Product launch – this is heavily dependent on learnings from discovery. A good launch borrows all the language that end-users used to describe their problem. The launch is all about communicating who the product is for, why they want it specifically, and how it will improve their lives.
Ongoing curation of the product based on direct customer feedback – PMs need to speak to actual customers every week. If you’re not talking to at least one customer a week (not including sales calls or demos), then you haven’t earned an opinion. A PM needs to constantly gather information to make decisions about their portfolio of products: which to end support on, which features to add, etc. They have a long-term vision of the product and every release, sprint, or month, make improvements based on feedback measurements and ongoing interviews with users.

How should you approach planning and prioritization?

A healthy engineering team will spend:

~50% of their time on customer-visible features
~30-40% on infrastructure (security, scalability, usability, failover, etc.)
~10%+ on discovery, long-term R&D, and future work

Segment your engineering budget and stakeholder requests into buckets and allocate according to the most important items in each – bucket your budget into the categories above, then line up the stakeholders for each category. Some back-of-the-envelope analysis can quickly sort $100,000 ideas from $100 ideas in each segment. Pretty quickly, you can winnow the list to the most important ideas in an unemotional way. The segmentation and allocation of the engineering budget allow you to accomplish something in every category and balance stakeholder demands.

Four different kinds of roadmaps:

3-month roadmap (detailed)
6-month rough plan
1-year set of broad high-level initiatives, hopes, and dreams
5-year company vision

Aim to get 90% right for what you’re building this quarter and 65-70% for next quarter – beyond that you’re going to be a lot less accurate. Companies with a precise two-year roadmap don’t understand how the world works. We don’t blindly and uncritically follow our roadmaps, we expect them to change many times during the year.

What’s the difference between product and project/program management?

Project and program managers manage the production of software – they have to figure out where we are in the building and shipping cycle, look at PERT charts, forecast when the engineering will finish, and if it will have all of the features a product manager committed to. Project and program managers are closer to the engineering org because most of the issues and people involved are in engineering. They do a lot of dependency management–moving people around and shifting resources between priorities to get things done on time.

Product managers manage what gets built, for what business reasons – product managers look at whether the software will make money, whether customers will pay for it and like it. Product managers also have to figure out what to do when project managers tell them software will be late. (Hint: it’s always late). Then, the product manager makes a call: either ship with fewer features, or wait and get more in there.

When do you need to hire your first product manager?

Your first product manager is typically between employee 12-20 – at that point, you have ~6 people on the engineering team and they’re wasting a lot of effort getting interrupted by product responsibilities, using poor specs, and ignoring some end users. Everything that product managers do becomes critical. If you hire a product manager with only 3 engineers, you’ll have to find something else for that person to do with part of their time.

If any of your founders have a product background, hiring a product manager can be delayed – in the beginning, product is handled by whoever knows what they’re doing or thinks they do. One of the founders will have to play product manager whether you like it or not.

Typical organizations have 1 product manager for roughly every 8 developers/designers – when your ‘maker’ team gets to ~8, you probably should have hired your product manager three months ago.

When hiring your first product manager what should you look for (and where)?

Hire someone with five or more years of actual product management experience on a commercial product – it takes ~5 years of experience as a product manager to be good. Don’t hire users, engineers, salespeople, or someone with a two-day product manager class certificate. Those are the wrong profiles without the time in grade as a product manager.

It’s more important to hire for product manager experience than for expertise in a specific product – look for experience as a product manager for a successful product that sold for money. This is even more urgent when hiring for Head of Product. It’s not necessary to hire someone with a technical degree or MBA but they’re handy.

Look for empathy, humility, and honesty – they’re hard to measure, but in every interview, I ask what didn’t go well in their last company and last couple of products. They fail if they throw shade on a prior company or coworkers. If they do it once, they’ll do it again. I’m always listening for “we” when it goes well, and “I” when it doesn’t.

Look for well-roundedness – product managers sit between a lot of different functions and must navigate conversations with all of them. They have to be students of human behavior and of how other departments work. They have no authority, only responsibility—nobody works for them and nobody takes orders from them. They have to be able to get the org to do the right things in the absence of authority.

You can spruce up titles for more senior product managers – some people get hung up on that manager title, as that tends to be a junior title, but product managers aren’t junior. You can have product managers, then senior product managers, and after a long tenure as an individual contributor they might become distinguished product managers.

What mistakes do organizations make when hiring for and installing a product management function?

Mistakes when hiring for Product Manager:

Hiring someone who’s never been a product manager before – this is the biggest mistake you can make. You can’t bring in a newly minted MBA with course credits in product management. Installing a first-time product manager, especially as a first product hire, and expecting them to ramp up on a complex strategic job, the organization, and the product/tech is unreasonable.
Over-indexing on subject matter expertise – you want someone who knows how to be a product manager, not necessarily someone who knows your product. Avoid hiring customers, salespeople etc., who know your industry but don’t already know how to do product management.
Hiring engineers who haven’t been product managers – engineers, as a group, are trained to believe they already know the answer, and trying to get them to interview users about things they don’t understand can waste a lot of time.
Hiring a product owner – especially if they come from non-software companies like banks or airlines, they are product managers. Someone from “the business” tells them what to do and they execute. They have little decision-making authority and no access to the market or users. Product owners rarely have the essential experience of bringing a revenue software product to market.
Avoid “two-in-the-box” – some companies pair a product owner and a product manager, but it’s not a recipe for success. One won’t know how anything gets built, and the other won’t know what should be built. You’re taking one job, breaking it in half, and putting in two people neither of whom have the right training or incentives.

Mistakes when developing the product management function:

Sales retains decision-making authority that should go to product – this is particularly common in a sales-led org. Sales might make a commitment to get a sale and tell engineering: “Hey we need this by Friday.” That’s a recipe for high churn and turnover on the product team because it makes it impossible to deliver solid products over time.
Founders hang on to product too long – it’s difficult for founders to let product managers do their jobs. There’s a survivorship bias because the founders handled product and were successful so far. But they need to let product managers do their work.
Pushing for a definite roadmap that stretches longer than 3-6 months – this often comes from the finance team. They want to know exactly how much revenue a feature will bring in next year—but we are forecasting into an uncertain future and the further out we go, the less certain we are. Three-year plans are mostly fiction. If you get fired for saying that, then I guess the company didn’t really want product management.

How do you onboard a new product hire?

Have them use the product without any training or manuals – they’ll discover things that have been ignored internally but frustrate every first-time customer or user. The first 3-4 weeks as product manager are a special opportunity as they’ll be naive in advantageous ways and see things you miss once you’ve learned the workarounds.

They should meet and talk to everyone – talk to sales and marketing, sit in on support calls, and absorb everyone’s thoughts before forming opinions about who’s smart and who’s not.

Don’t make promises in the first 3-4 weeks – there’s a big distinction between listening to what sales or marketing says and agreeing to do it. Most of what a brand new product manager wants to promise will be wrong. They should sit in on meetings and think about how to make friends, influence people and form connections, and learn as much as they can.

A veteran product manager will have a three-month ramp – it takes about three months to learn the product and the organization, and meet all of the relevant people. If it’s your first product job, it can take two years or more.

How many product management employees do you need?

One product manager per eight engineering employees – this is a rule of thumb for a typical org. If you haven’t found product market fit, you’ll need more product management relative to engineering. If you’re milking your customers as you sunset a legacy product, you probably don’t need as many product managers.

Very technical products still need product managers – if your product is an API, you don’t want your API engineering team explaining to Product Marketing all the benefits, use cases, pricing, packaging, and sales considerations. Engineers are not product managers and vice-versa. It might be even more important for highly technical products to have product management, or else engineers go build a bunch of APIs without any consideration for how to make money off of them.

What are the roles on a product team and what are their responsibilities?

Assign each PM a piece of the product – divide the product in ways that are meaningful for the customers and the business case (rather than chopping up the product in ways that are meaningful for the codebase). If you’ve chopped up the product so that there isn’t a product manager who can appeal to the buyer or user, then your messaging and marketing will be broken. You won’t know what to build or say.

A Director of Product can manage up to five product managers – six if they’re really good. They will manage and be contributors to their product teams. Above that, a VP of Product can usually manage up to four directors.

Smaller companies can put a player-coach in the head of product role – in a company with only 20 engineers and 3 product managers, you might have someone working day-to-day on a piece of product but also overseeing PMs and reporting to the CEO.

CPOs shouldn’t be individual contributors – someone with a Chief Product Officer title is not an individual contributor, in the same way that the Head of Engineering actually does very little engineering. It’s mostly organizational alignment, product/company strategy, HR, hiring, etc.

How do you reduce the distance between customer feedback and developers and designers?

Developers and designers need to hear directly from users – it motivates them to see the concerns of real people using what they build. If they hear live from customers, they feel like real members of the team, they care more about the product, and might not leave for $2,000 raises. If it’s always the Product Manager writing a ticket, they just feel like code monkeys in the back.

Invite one member of your design team and your engineering team to listen in on each customer call – product managers should do interviews every week with real users, and should invite designers and engineers (in rotation) to listen in.

Don’t be too quick to give developers the mic to talk – they tend to say things like, “No problem, we’ll have that to you by Tuesday,” or, “that’s a stupid idea, and here’s why.” Instead, let them contribute questions or send chat messages to the PM (or designer) conducting the interview. Having engineers and developers live on the call makes your conversation smarter. They’ll ask great questions you wouldn’t have thought of.

What are the most important things to get right?

Build the right things – the primary product management problem is: are we building the right things? The engineering problem is: are we building things right?

What are common pitfalls?

Thinking you’re the expert – understand what motivates all stakeholders, and don’t speak down to them. Don’t act like you’re the smartest person in the room. Stay humble and hungry.

Don’t fall into the trap of thinking there’s one universal roadmap – engineers need a detailed roadmap and salespeople should get some much higher-level. By the way, the definition of a millisecond is the time between sending an internal-only roadmap to an enterprise sales team (marked “internal only, not for customers”) when it gets mailed out to customers.