What I Learned From Blair Reeves and Ben Gaines with Their Upcoming Book about Enterprise Product Management

Book Review of Building Products for the Enterprise

Who should read this?

If you’re working on product management for the enterprise software, regardless of your rank in the organization, you might be a product specialist, product manager, group product manager, head of product, principal product manager, or even CPO, you should read this.

If you want to learn from two enterprise product managers, Blair Reeves (SAS Principal Product Manager) and Ben Gaines (Adobe Group Product Manager), who have spent their entire tech careers at the forefront of that very shift to the world of enterprise SaaS, you should read this.

If you finish reading the lines above and keep thinking about “Product Management specifically for the enterprise, huh?”, you should read this.

Already want to read the book without reading the review? Head over to: Building Products for the Enterprise.

Who am I and why do I write this?

Let’s address the elephant in the room: who am I (and why should you trust me)?

Hi — I’m Aero Wong, the Product Baby. I’m honored to have a preview of the book by reading the manuscript before it’s published with O’Reilly, because I’m the host and creator of the Product Manager Summit, the industry-first, free, web conference that brought together 30 leading product leaders from around the globe to conduct masterclasses and expert sessions in Product Management.

Blair Reeves was the only speaker in the summit to lecture about: Enterprise Product Management. I didn’t aim to find only one speaker to hold an expert session toward this topic. I intended to find more, because I was learning — in the enterprise product management. I was working at an OTT solution company. The product I was working on was targeting enterprise customer. I had less than two years of experience in this gig and wanted to find more enterprise product managers who are sharing good content online. But I couldn’t find much.

Blair is the man.

Read. Write. Share. Are the best ways to learn new knowledge that we want to internalize. So, here we are.

Tweet Blair at: https://twitter.com/BlairReeves

Tweet Ben Gaines at: https://twitter.com/BenjaminGaines

How to Navigate this Book Review

I’ve followed Blair’s writing pieces since day one I’m in this gig. I’ve never skip reading one word in his articles, because every single word earns its place. I intend to do the same for this book review.

This is what I do when I read his articles and you should too with this book review. Pencil and notebook ready. Skim the entire article once. Read again from the start, dive deep and note down all the takeaways along the way. Apply the lessons learned on your job. Discuss the topics with your colleagues and other product managers. Take a long walk to reflect. Review the notes and read again the article. Repeat the cycle.

There are seven chapters in the book and I chose eight of my biggest takeaways from the first three chapters.

Chapter 1 — Why Product in the Enterprise is Different

Chapter 2 — Who Are We Building For?

Chapter 3 — Three Types of Knowledge for a Product Manager to Seek

When you read along, you’ll notice I put words in the quote blocks which are the golden nuggets I directly pull out from the book.

This is a quote block.

After all, if you find my takeaways useful, go buy the book, read the remaining chapters, and apply the lessons learned on your job. Then repeat the cycle.

Information is power when it’s acted upon.

Caveat — It Takes Time to Obtain Knowledge

In order to write this book review, I read the manuscript over ten times, rewrite and edit the review over hundred times and take long walks to reflect on the knowledge another hundred times. It takes me a week to write, review, and polish. Because that’s the way how we learn.

Bearing in mind it takes time to obtain knowledge is crucial, as most of the time, we blame ourselves learning not fast enough. We’re guilty about the progress and fall out of the beautiful state which is the alpha state that enables express learning. So, take a deep breath, smile, and read on…

Takeaway 1 — Consumer and Enterprise Product Management are Different

Profound knowledge is any simple distinction, strategy, belief, skill, or tool that, the minute we understand it, we can apply it to make immediate increases in the quality of our lives. The first takeaway is my profound knowledge - the foundation to set the stage to build the tower of enterprise product management.

I used to hire a researcher to provide me all the information online about product management. In order to level up my product skills, I read articles, books, blogs, met other product people, and even created a virtual summit for it. I applied all of lessons learned on my job from these sources. I had some tangible result, but not the quantum breakthrough I’m seeking for.

Not until I read this article written by Blair: Product Management for the Enterprise.

There’re many good content about product management in general; but there’s not much content cater for the specific need of the enterprise product management.

Lately, in listening to a podcast episode where James Altucher interviewed Tony Robbins, there’s a funny conversation between them.

Tony: “What are the two of most recurring stressful thoughts in your life?”

James: “I’m gonna go broke and my girlfriend is gonna cheat on me.”

Tony: “Now, if we ask what percentage of your listeners have had the fear you’re not gonna make the money and you’re gonna go broke?”

James: “100%”

Tony: “What percentage of your listeners do they have the fear their boyfriend or girlfriend may leave them, or die, or cheat on them?”

James: “99.9%”

Tony: “So, those aren’t your thoughts.”

James went speechless and Tony continued, “those thoughts have been around forever. You call them your thoughts as long as you make them your thoughts, it will be extremely hard for you to separate and identify with them.”

I’ve never questioned the 99.9% of the knowledge established in the domain of product management. I always thought product management is the thing. And never realised there’s a subcategory named: enterprise product management. This is the 0.1% knowledge.

I was blind but now I see.

The first product knowledge you need to grab hold on, as an enterprise product manager, is you need to understand there are two types of product management: consumer and enterprise.

Read the article that changes the game: Product Management for the Enterprise.

Or read the direct quote from the book:

Product management is a different beast in enterprise software because of our business model.

In consumer technology, there are lots of revenue models: advertising-supported is obviously very popular, but there are also two-sided marketplaces, affiliate models, direct sales (almost always self-service ones), and much more. In the winner-take-all world we live in today, all of these are fundamentally scale businesses. You have user bases in the millions (or tens, or hundreds thereof), and must make product, pricing, infrastructural and technology decisions accordingly.

In the enterprise market, we operate almost exclusively on a direct-sales model, whether that means selling good old-fashioned licenses or subscriptions (as we do in SaaS). Enterprise is rarely a scale business. Though there are interesting exceptions, we mainly rely on Sales to sell complicated products and solutions to a relatively small (compared to consumer software) group of sophisticated customers for large deal sizes. Those deals are negotiated, budgeted for, implemented and monitored for weeks, months or even years (!). Sales cycles are long and complicated. (You can probably already see some obvious reasons why it can be very difficult for startups to crack this market.)

Takeaway 2 — The Gap Between Them Are Growing

After you can distinguish the difference between consumer and enterprise product management, you’ll notice most of the startup-VC-industrial whirlwind that’s covered breathlessly by the tech press are always consumer-oriented.

Product Management for the Enterprise is a rare creature in the ocean amount of product management content. If you google “enterprise product management”, the first organic result you’ll see is this article.

Why can Blair be the pioneer in sharing enterprise product management advises, providing us the 0.1% knowledge that can enable us to thrive as an enterprise product manager?

Because the gap between customer and enterprise software are growing — we just don’t notice — and he happens to be the insider.

The following statistical analytics is the direct quote from the book:

“As of 2014, a group of 10 companies generated 45% of all global revenue in the enterprise software segment. In fact, just 5 companies — Microsoft, Oracle, IBM, SAP and Symantec — generated 38% of that revenue. Just two companies on that same list, Salesforce (#9) and Google (#20), have been founded in the last 25 years. The overall enterprise software business is very healthy and growing fast while undergoing huge changes, especially in terms of cloud and subscription-based models.”

Blair works as the Principal Product Manager at SAS (#13 on that list above) and Ben works as the Group Product Manager at Adobe (#11). They spotted the growing gap and write a book about it to let us know.

Takeaway 3 — Customers Come First, Users Second

I used to pitch hard to the Senior Manager, “According to the 99.9% of my research toward product management, no product managers work solely in the office cubicle. Let me meet the customers. That’s the simplest and most direct way I can learn their problems that drive our roadmap.” Eventually, he backed down on my persistence and gave me the permission to set up a meeting with the user who uses our backend control panel on a daily basis. I’ve got a shot to chat with the user over an online conference call. I researched the role of the user and her company’s background, reached out to the project managers who serves her to get even more background information, prepared a long list of questions that hopefully can fish out her pain points or problems in using our product, spent a number of hours with the technical lead to study the product’s architecture, and another good number of hours to play with the product’s interface. I finished the call and was over the moon. My notes were all over the page: her pain points, feature requests, a list of problems, etc. I happily consolidated everything and translated them into the product backlog. A year later, they’re still in the backlog.

None of them have been inserted into the roadmap as a development item.

I’m not sure if the Senior Manager intended to have me to practice the interviewing skills or he simply does not know the difference between the customer and user like I did. He had never told me the reasons behind why he didn’t prioritize the backlog items I created into the roadmap. I was confused for months.

Not until I read this from the book:

The big thing that makes “enterprise PM” tricky is knowing who you’re building for. That user, who may spend a substantial chunk of his or her professional life working in your product’s UI, is almost never the same person who pays you for it. They are not your customer; they’re your user. The customers are nearly always your users’ bosses, or even their bosses’ bosses, who are the ones writing the check.

The one I interviewed was a user, not the customer — who cares business value and ROI more than user experience design and any other things.

At the beginning of this year, I reviewed the roadmap items we implemented in the previous year, and noticed the ratio of user and customer-oriented roadmap items is 1:13. Clearly, we built product for customers rather than the users, who we valued the input but not in the same priority bucket.

Takeaway 4 — Problems Are Not Created Equal

I was the first product owner in the company, inherited a backlog for a product with over two hundred items, and we didn’t have a problem-based product roadmap at the time. The backlog was like the wishlist written by a family with ten kids, and even worse, the new wish items are still pouring in. Prioritization — the most important skill of a product manager — was never been easy. Applying the technique of “relentless why” that I learned from a product management guru Daniel Zacarias, I didn’t care if the people probed by me was fatigued by my questions after questions, I wouldn’t let them go until I knew the “why” behind the feature requests — the problems we’re trying to solve.

Finally, looking at the list of problems translating backward from the feature requests, two types of problems were unearthed: customer and user problems. Often time, the customer problems were flowed from the top of the food chain down to the backlog. On the other hand, the user problems are always UI driven; In fact, I have never seen a user problem was registered by a c-level or senior executive so far.

The deep understanding of the problems is the prerequisite of having a better prioritization, because the enterprise software often involves two different sets of problems: user problems and customer problems.

Takeaway 5 — Customer Problems are “Currency”

“User experience design owns the user; product management owns the customers.” is a popular product management maxim. I now believe it’s true due to the nature of the product business we’re in.

Let’s read the direct quote from the book:

The central challenge for enterprise Product Managers is identifying user problems versus customer problems, and clearly understanding which your product addresses. Customer problems are your “currency” as a Product Manager, because it’s only by solving them that you prove the potential for your product to unlock transformational value.

We’re three feet from the gold mine, let’s roll up the sleeves, pick up a spade, and hustle.

The Four Tools of Currency Mining

The One-Sentence Examination

Studying in the math class when I was at high school, I was a bad product manager. I had no interest to dig in the problem behind the questions in test. The way for me to excel on the test was to memorize the formulas that can lead me to the standard answers. If the teacher asked me later how I could solve the problem, “I have no clue,” I’d say. That’s where you don’t wanna end up and the reasons why we dive deep in the first four takeaways before talking about the first tool of currency mining: one-sentence examination.

We know we have defined a customer problem when we can finish the sentence, “As a customer of [your product], we cannot grow as fast as we would like because we can’t _______.” If you come across a product idea that can’t be quickly and clearly related to a customer’s revenue growth, why would you invest to solve it?

Skydive From Vision to Strategy

Vision is the ability to imagine how a country, society, or industry could develop in the future and plan for this. Your company has a company vision; you, as a product manager, should have a product’s vision too.

Company vision

Simply put, what you’re looking for here is to understand the 100,000 feet statement that your company makes in the press, in the company website to communicate the reason for its existence.

For example, Google’s vision is to “organize all of the data in the world and make it accessible for everyone in a useful way”

Product vision

Extending from the Google’s vision example, we can easily see why the Google Maps is part of the endeavor. By collecting massive amounts of geospatial data and making it all available through the medium of a mobile application, Google is trying to realize its concept of bringing the world closer together, of serving as an information hub in the massive library that is the internet.

Product Strategy

Once the product vision is clear, seek to establish the categories of innovation that your product needs to pursue in order to achieve that vision. You will end up with a hierarchy looking something like this:

Corporate Vision

— — Product Vision

— — — — Strategy Element 1

— — — — — — Key Feature 1

— — — — — — Key Feature 2

— — — — — — Key Feature 3

— — — — — — Etc.

— — — — Strategy Element 2

— — — — — — Key Feature 1

— — — — — — Key Feature 2

— — — — — — Key Feature 3

— — — — — — Etc.

— — — — Strategy Element 3

— — — — — — Etc.

Product Metrics

“What gets measured, gets managed.” — Peter Drucker

Product KPI

Key. Performance. Indicators.

Schedule a meeting with your boss. Define the successful metrics for your product, starting from the strategy element level, then to the key feature level. Review them monthly and quarterly.

The KPIs will indicate you which feature to eliminate, which feature to improve, which strategy to let go, and which strategy to embrace.

Product OKR

Objective. Key results.

I should write about the OKR first, then the KPI indeed, as KPI flows from OKR. But I want to stress the importance of process to measure and improve. If the process is correct, the ideal result will inevitably come. The OKR approach exists for more than forty years which was developed by Intel. It’s self-evident this simple and direct approach keeps not only the product manager but the team around to stay focus on the objective and key result. For example, in a discussion with my Senior Manager for the go-to-market strategy, we got clear on the current year key objective is to prepare to enter the OTT market, the key results we’re going after is lead generation, the metrics to define success is then the lead conversion rate, our moves toward the objective becomes crystal clear, from corporate website design to copywriting to product marketing.

The Product Leadership Team

We need massive actions to realise everything we plan. Cascading down from the corporate vision, we set the stage for success, we know why we’re doing what we’re doing, we’re going to figure out the how with the Product Leadership Team (PLT).

A typical setting for the team are the key decision-makers as follow: Development Manager, Product Manager, QA Manager, Operation Manager, etc. (the people involved varies from company to company and you know what I mean). On a weekly basis, the team is then to figure out the how — what we need to do to realize the what — the result would be reviewed in the next week. In accordance with the lessons learned from the previous week, modify the actions for next week. Agile in action.

The formation and execution of the PLT is easier said than done. From the surface, it looks like just a weekly routine to hold a meeting to gather all the key stakeholders to create consensus so that every single one of them can move toward the market in sync with one another. But to make this team effective, as the product manager in the intersection of everything, you’re responsible to translate the customer problem stemming from the corporate vision all the way down to the KPI to the team. Take a look of the illustration:

Takeaway 7 — The Enterprise Product Manager Does Nothing Alone

When you’re the orchestrator, niether you play violin nor saxophone; When you’re an enterprise product manager, niether you code nor create UI. When you’re in a gigantic company like SAS (where the author Blair works) and Adobe (where the author Ben works), it’s very normal. It’s important to understand this.

As we’ve discussed, it is often very difficult for startups to crack the enterprise software space. As a result, you may find yourself doing enterprise product management within your own enterprise — one of hundreds or thousands or even hundreds of thousands of employees who contribute to success, each in his or her own way. It can seem like a maze of directory listings impossible to parse, even if you’ve been at the company for years — let alone if you’re a new employee. How do?

The simple answer is that an enterprise Product Manager does (almost) nothing alone.

Takeaway 8 — I’m Not Working at Facebook

Eight years ago, I watched the movie “social network”; at the time, I wasn’t a product people nor a techie, the image of a bunch of programmers coding in a drunken state painted a picture in my head this is how a technology company operates. Later, the motto of “move fast and break things” reinforces this belief further. But in enterprise product management, it’s a recipe for disaster.

With the obvious exception of early-adopter or beta user scenarios, rolling out bleeding-edge features without adequate testing and QA runs a high risk of delivering a bad experience for your users, who will wonder why they’re paying you so much money for an incomplete product that they can’t trust with their business. Enterprise buyers don’t want half-baked solutions — they expect, and frankly deserve, a well-engineered product.

I’ve never had the authority in the company to enforce the proper QA resources and client-facing documentations in place. But after reading the wisdom from: Building Products for the Enterprise, I try everything I can to influence the company culture that I want to live in.

Is Building Products for the Enterprise for You?

That’s it!

I’ve shared eight of my biggest takeaways from the first three chapters of the book. If you read this far, I believe you’re in the tribe of the enterprise product management as I do.

And you’ll find the following chapters useful too.

Chapter 4 — Organizational Knowledge

Chapter 5 — Product Knowledge

Chapter 6 — Industry Knowledge

Chapter 7 — The Product Managers

If the topic of “Product Management specifically for the enterprise” rings true in your head, pre-order the book here: Building Products for the Enterprise