Product Management: It’s a System for Business Success, not Product Features

Far too many people think Product Management is about delivering product features. It’s not. It’s about setting the company up for ongoing business success.

It feels odd to have to say it, but I will:

Product Management is about driving product success, not delivering product features.

It is my observation that far too many companies struggle with business success because they don’t have a clear connection between what they do in Product and what they want to do in business. Perhaps it’s time to fix that.

Recently, AirBnB’s CEO Brian Chesky gave a talk at the Config 2023 Conference and mentioned something about Product Management that got a LOT of people talking.

The screenshot above captures the moment (out of context of course) where he said what got lots of tongues wagging and fingers typing.

“…actually we got rid of the classic Product Management function” — Brian Chesky

You can see the whole interaction here. It’s at 10:47 of the video. Note the applause from the audience when he says he got rid of Product Management. Seems there were more than a few Product Management skeptics in that audience.

But Chesky didn’t say what “classic Product Management” is. Given other things he said, I would assume it might be primarily delivery focused work — which is really not what Product Management is, but I’ll get into that.

If you listen to the whole talk, you can see that what Chesky is describing is a model for his company to operate, and addressing dysfunctions he saw in the company. In a nutshell Chesky says he:

• Integrated all the disparate roadmaps into a single overall company roadmap (implying lack of unified product vision)
• Stipulated that only a fraction of the roadmap (10%) would be delivered, (thus putting focus on a small number of big initiatives).
• Wanted people to ship things they were proud of (focus on quality and not quantity)
• Elevated Designers to the level of Product Managers (he himself has a Design background).
• Merged Product Management and Product Marketing to make it more business focused. (Moved it away from feature delivery)
• Wanted to implement an “integrated approach” so a small group can have visibility across the entire company and make key decisions, a-la Apple. (centralized decision making)

Note: all of this, as well as many other changes, were made during the early parts of the pandemic where AirBnB’s business fell off a cliff and people were wondering whether they would even remain in business. i.e. it was an existential crisis for AirBnb, and as CEO, Chesky had to make changes.

BTW, another couple of quotes by Chesky in the same talk are:

“Make no mistake; Product Managers are critical, but they shouldn’t be doing the job of a Designer” — Brian Chesky

“Product Marketing is Product Management plus outbound marketing…It’s an extremely influential function. They will work with the Designers and us to identify what is the project, what are the goals…” — Brian Chesky

I agree with the first statement that Product Managers are critical and they shouldn’t be doing the job of Designers. Product Management and Design are complementary and should work together.

I don’t quite agree with Chesky’s definition of Product Marketing. But that’s not to say that Chesky is wrong, as Product Management and Product Marketing are definitely inter-related.

In fact, I see it as the inverse of Chesky’s definition. I wrote the following in this article on Product Marketing:

Product Marketing is strategic marketing at the product or product-line level. Product Marketing, as an overall function, is in fact a part of the overall function of Product Management.

i.e. We both see them as related, but I see Product Marketing as a part of OVERALL Product Management and not the other way around as Chesky does.

Regardless, Chesky is doing what he believes is best for AirBnB. Not only is that his right, but that is his obligation as CEO. And we will all see if he succeeds or not via the financial results of the company.

But for the rest of us, it’s important to understand what Product Management is and why it’s important to company success.

So, what exactly is Product Management?

I answered that question in detail in an article entitled So, What exactly is Software Product Management. 😃 But if you want the shorter answer, let me summarize:

Product Management is cross-functional business and technology management focused on creating and delivering products that meet or exceed their business goals and objectives.

There’s a lot packed into that sentence, but the key words are:

• cross-functional
• business and technology management
• creating and delivering products
• exceeding business goals and objectives.

I dig into this in the article mentioned above, but it should be clear that Product Management is closely tied to organizational (i.e. cross-functional) business success at the product level, and is not just about building and delivering features and functionality.

Also, that cross-functional aspect is critical. Product Management is not another silo, but a layer across the business connecting Engineering, Marketing, Sales, Finance, Support etc.

Product Management is a system for driving business success. It’s about achieving positive product outcomes (success), NOT ongoing product outputs (delivery); because business success COMES from product success.

Product Management is a System Across the Organization

The word “system” is key here. Product Management is NOT simply a set of actions performed to achieve certain goals. By it’s very nature it is cross-functional, and thus the interaction with other parts of the organization is critical to the function.

And that interaction must be structured and performed in a systematic way that continuously leads to the outcomes the company needs. That’s why I use the word “system”. It’s not ad-hoc, or loosely structured or something equivalent; it can’t be.

Photo by Wilhelm Gunkel on Unsplash

A Example of a Working System

I first became a Product Manager in 1997. It was at a self-funded software company in Toronto called KL Group (KLG).

KLG built development tools and libraries for enterprise software developers. Although I didn’t realize it at the time, it was a remarkably well run small company with few of the dysfunctions that we see of many companies that size today. It wasn’t perfect of course and had issues and challenges, but overall, especially when I looked back, it had a LOT of great qualities that others would have been smart to emulate.

Well-defined Product Management

First, I’ll start with Product Management. There was a well defined Product Management function. Product Management was central to the way the company worked and the President had a good sense for what it should be, and ran it from a business perspective. i.e. it wasn’t just about what to build, but about driving business results through products.

There was a CLEAR connection between business goals and product goals, and how the company planned to achieve them

I came in as a rookie Product Manager taking over a Unix product line that generated a majority of the company’s revenue and ALL of it’s profit. Initially there were 2 Product Managers — me on the Unix (and a couple of small Windows) products, and another PM on the Java products. The PM team eventually grew to 4 or 5 PMs.

We received initial training at the ONLY training that existed back then — Pragmatic Marketing. I’ll be honest, I was not very impressed by the 2-day Pragmatic workshop we attended. But that diverged from almost everyone else who attended from our company. 🙄

Beyond that initial training, we did talk a lot internally about how we could be better at our jobs and improve the function. There weren’t online Product Management forums, meetups or communities back then, nor was there much about software Product Management written on the Internet, so we only had our coworkers to commiserate with and discuss things with.

Clear Objectives and Authority

We had clear objectives — revenue AND profitability numbers — we were measured against. But we also had visibility into and authority over many (but not all) aspects of investment and spend for our products. i.e. the objectives came with enough authority to impact what needed to be done to achieve the objectives.

This is a VERY important point as you need both, the objectives AND the authority. A lot of Product Managers don’t have both and this is VERY problematic as it means they don’t really have the ability to impact the change needed to achieve those objectives.

e.g. I had authority over a decent portion of marketing spend. I decided where to run print ads to drive awareness and evaluations. I could run experiments with online advertising and double down on what worked. I ran direct mail campaigns to targeted prospects and tracked response rates. And of course we had trade shows and other events we attended.

I had a really great holistic view of the marketing landscape and it’s impact on the business success of my products.

Clear Strategic Focus

The company strategy was clear. We were focused on empowering enterprise developers (core market segment) and saw the Java market as the focus for future growth.

The Unix products (the original products of the company) served a relatively mature market and didn’t have a LOT of investment going into them. The profits from the Unix products (my products) were being used to fund the development of a number of Java products that had yet to break even.

My mandate was clear and simple (in theory):

Maximize profits on the Unix products so the company could invest those profits into the Java products as that was where the company’s future growth would be.

In order to maximize profits, I had to have a REALLY clear understanding of the state of the business of my products — there were 5 individual products that were also sold together as a bundle.

This also meant having a clear understanding of variable costs (headcount and marketing were the two major ones) as well as revenues of each of the products and the bundle.

Detailed View of Finances

We had a great Finance team who provided monthly and quarterly reports slicing and dicing the data by product, region, direct revenue, reseller revenue, license vs. maintenance, departmental expenses, including breakout of marketing expenses etc. We also had access to cleansed data of ALL transactions for our products that we could pull into Excel and run almost any analysis we wanted. Pivot Tables were my best friend back then.

And yes, I said monthly and quarterly reports. This was 1997–1999, so real-time dashboards etc. weren’t a thing (yet). My products were literally packaged in boxes with printed manuals and software CDs, and shipped (Fedex, UPS etc.) to customers.

And to be honest, we didn’t need real-time revenue data. The decisions we were making didn’t need it. But every month, when the monthly reports came out, I’d definitely pore over the data in detail. And those Quarterly reports — they were gold with LOTS of detail and comparisons to plan etc. Very useful.

Robust Product Evaluation Data

We had downloadable evaluation copies, and had a small but great IT team who not only created and maintained the eval system, but also provided daily data on downloads, referral source, contact info etc.

This data gave us great insight into which marketing programs were working, which weren’t, where we might need to spend more (or less), pay more attention, tweak messaging etc.

For the late 90s, this was, IMHO, a pretty sophisticated setup, and quite honestly, was more data than I had in companies I worked in for most of the early 2000s.

Direct involvement in Pricing, Licensing and Packaging

I was also involved in pricing, licensing and packaging discussions as well as activities with our reseller partners. I worked on updating SKUs and pricing when we had major new releases. We created sales bundles and worked with our Channel Manager to ensure our resellers were contributing at levels that justified the costs/margins given to them.

The pricing and packaging work required a real understanding of how we were selling, to whom, who our competition was, their strenghts/weaknesses etc. and the needs/goals of our partners. In later years, I rarely had this kind of insight at other companies.

Internal Education and Training

Product Managers were responsible for internal training of Sales, Support and Marketing. We worked with our development teams to create and deliver that. We weren’t a big company, so this wasn’t an enormous task, but it was critical in enabling them to do their jobs effectively. We also held regular lunch-and-learn sessions to share new information such as new pricing or to hear feedback from these teams on new products or other issues

This kept people within the company (Product Managers included) aligned with each other. It didn’t solve all issues, but this ongoing communication process built real rapport and made information flow much easier.

Business Planning and Feedback Loops

We held biweekly or sometimes weekly cross-functional operational level meetings for each product line. These meetings included Product Management, Engineering, Sales, Marketing and Support (if I recall correctly). These were mid-level managers and individual contributors. There were no executives or management as these meetings.

We’d focus on operational level issues tied to product releases, marketing campaigns or events, sales and customer support issues. It was a great way to share the state of the product and create and maintain common context across teams. I’ve implemented this kind of meeting in EVERY company I’ve worked in and strongly recommend this to all my clients as a way to stay aligned and have a “no surprises” culture when it comes to product success.

Probably the most important and valuable activity we performed as Product Managers was annual business planning and quarterly business reviews.

We were responsible for putting together annual plans, based on growth/revenue targets that were given to us by the executives. We had some input into the target, but the numbers that came down, if I recall, were not outlandish or unattainable.

The annual plans we created defined key marketing, development or other activities, deliverables and expenditures each quarter. They were reviewed by the executive team and feedback was given, often requiring rework. It was a tough process, but it made sense and again, brought alignment across products and leadership team members.

Quarterly Business Reviews

We also had Quarterly Business Reviews (QBRs). At the end of each quarter, once the quarterly reports came out, we’d sit with the execs to review the results, compare to plan, identify any issues, understand why, make adjustments to our next quarter’s plan etc. This kept us all clear on where we were, what was working and what wasn’t, and what changes were needed.

I’ve never seen this level of discussion in any other company I worked in. A couple did have something similar, though far less comprehensive.

The overall benefit to ME as a Product Manager was that I had a ROCK SOLID understanding of the state of the business for my products,

This informed my decision making AND reduced the HIPPO impact, because THEY had the same business context as well.

i.e. we (executives on down) were aligned on what we were doing, why we were doing it and how well things were doing.

The random (HIPPO) ideas etc. didn’t come up (very much) because there was confidence that the path ahead was the right path forward and we all — Leadership team and PMs — had agreed to it.

Working with Engineering

I’ve saved this one for last because it doesn’t really need much coverage. Of course Product Management worked with Engineering. I had the benefit of working with some great Development Managers, some of whom I still keep in touch with to this day.

If I could speak for them, I’d like to believe they knew my focus was Product Success, which went well beyond what capabilities we were adding to the product. And I’d hope they also understood the key role they played in that.

This was before the days of Agile (late 90s), but we certainly didn’t work in a waterfall method. Yes, we planned releases that comprised several months (3–6 months depending on the release) of work, but we spoke regularly, made adjustments where needed and released good quality product to market.

Keep in mind we were shipping boxed product directly to customers or via resellers, so even if we had continuous integration etc. we could only ship — yes, literally ship — after significant functionality had been added.

Implementing the System

As you can see above, all teams, Product Management, Marketing, Sales, Finance, Engineering, Support etc. worked together. It was a key goal to keep everyone aligned, but the alignment started at the VERY top of the company with the Executive Team, and worked down from there.

As Product Managers, we weren’t in a silo, only working on “the product” with Engineering. We were effectively Business Managers truly working cross-functionally to drive our products to success.

Sometimes, I think Product Managers should be called Product Success Managers because that is what what we do — or should be doing.

I mean we have Customer Success Managers right? And their job is to ensure customers are successful, so why not apply that same nomenclature to Product Managers who should be focused on ensuring product success.

The system I worked in included data — we had it in the late 90s, so why not today—through the detailed reports and online data we collected.

We had context and market understanding through regular contact with customers and partners.

We had well defined roles and responsibilities, AND accountability for the work we were tasked to do.

We were aligned internally on business objectives via PARTICIPATORY business planning.

i.e. As Product Managers, we were participants in that planning, not handed down pronouncements from above and told to execute.

We had a truly 360-view of the product and used that to inform our decision making.

It took hard work to implement and run that system, but it was both efficient and effective in moving the company forward and achieving business results.

I look back at that job as the model for Product Management that more companies should adopt. Unfortunately over the last decade, the role has shifted HEAVILY away from a business focus to a feature delivery focus, much to the detriment of Product Managers and the companies they work in.

But the momentum may be shifting, and people like Chesky, who are looking to move businesses towards a more sustainable and focused approach, moving Product Management to more business-centric approach may be leading the way.

NOTE: If you’d like help setting up a product management system that aligns product with business to drive real financial results, contact me.

UPDATE: Nov. 12, 2023. Chesky’s original comments were from July 2023, and this post was originally written then. Lenny’s Podcast interviewed Chesky in Nov 2023. Chesky explained what he did with the Product Management function. Essentially he integrated the building and the go-to-market aspects so Product needs to be thinking about BOTH. Yup. THAT’s actual Product Management. You can see the episode here:

A little feedback please

If you’ve read this far, thank you. I’d like some feedback on the article to make it better. It should take just 1 minute, but will really be valuable to me. Thanks in advance.

===> Click Here <===