A summary of “Building Products for the Enterprise”

Thomas Ziegelbecker

·

Follow

Published in

Product Coalition

·

18 min read

·

Apr 22, 2022

--

Listen

Share

Finally, “Building for Business: Product Management in Enterprise Software” is a truly B2B-focused Product Management book, written by Blair Reeves (Salesforce) and Benjamin Gaines (Adobe) for “all the ones who aren’t part of the Silicon Valley startup bread”.

As argued in the intro of the book, even though enterprise software makes up a big share of the total software market, most Product Management books still focus on consumer products only as well as ignore that enterprise software products are built and distributed very differently.

To make up for it, Ben and Blair look at these differences, educate you on how Product Management in enterprise software works as well as guide you on how to succeed within it. In my opinion, they did an amazing job at covering all this within just 190 pages and 9 chapters:

• Chapter 1: Why Product Management in the Enterprise is different
• Chapter 2: Who are we building for
• Chapter 3: Three types of knowledge for a Product Manager to seek. Introduces the three types, while they are covered in more detail in later chapters, which is why I skipped it in this summary.
• Chapter 4: Organizational knowledge
• Chapter 5: Product Knowledge
• Chapter 6: Building better products with data
• Chapter 7: Industry knowledge
• Chapter 8: The Product Managers
• Chapter 9: Conclusions summarizes the main takeaways of the book, which is why I skipped it in this summary.

The heart of the book comprises the following types of knowledge that every Product Manager should acquire, as Ben and Blair promote:

• Organizational knowledge is about how your company works and helps you find the information needed to get your job done.
• Product knowledge covers your product’s benefits and limitations. Ben and Blair state, “the main goal is to know enough to empathize with your users/customers and to help create solutions to their problems”.
• Industry knowledge means having a deep understanding of your customers and your market’s unsolved problems.

Chapter 1: Why Product Management in the Enterprise is different

First, Ben and Blair explain what a Product Manager (PM) is.

“…the Product Manager is a sheepdog…”

As a sheepdog, a Product Manager is “right at the nexus of all other teams” where he or she “leads in defining the product vision, establishing the operational plan to get there, and then executing on it”.
To execute well a Product Manager “harnesses incentives built into all of the other teams and aligns them toward a single destination”, Ben and Blair describe.

But why is working in enterprise software now different?

According to the authors, it’s mainly because of three reasons:

• The business model: SaaS often works on a direct-sales model and Sales most often “sell a complex product to a relatively small group of customers for large deal sizes”.
• Product specialization: “very tailored to solve a specific technical or business need” that becomes complicated quickly.
• The customer vs. the user: the one buying your product isn’t the same one who pays for it. A user with expectations towards a great design and experience doesn’t care about the same as the customer, who cares about the return on investment. So it’s crucial to understand both, your users and customers as well as how they interact and influence each other.

Chapter 2: Who are we building for

The chapter starts with two tenets for Product Management:

“Shipping a product is the process of deciding what you are going to build, and why.”

According to Ben and Blair, this requires “a realistic sense of how the company should decide what to create”. Yet, only a few have this “sense” when coming into Product, they argue. This is the case because PMs are often faced with too many requests from too many sides. To not try to please everyone, Ben and Blair advise “staying the course, given your strategy is sound”.

“Product Management is about solving customer problems.”

To make sure your strategy is sound you need to continuously “figure out who you are building for”, Ben and Blair point out. This not just helps you to get a deep understanding of your customer’s problems but allows you to communicate these problems well to your teams.

From user problems to customer problems

In enterprise software, you differentiate between the ones who buy your product (i.e., customers) and the ones who actually use your product (i.e., users). Therefore, Ben and Blair differentiate between customer and user problems. User problems are described as “minor improvements and user design or user experience related” and customer problems as “What keeps our CEO awake at night”.

While they believe that user problems are important and shouldn’t be ignored, they see customer problems as more valuable to be solved because they represent “broader challenges that make your product truly indispensable”.

To gather customer problems, Ben and Blair suggest extensively studying your customers and market, while watching out for resurfacing problems across customers. These problems indicate a “big opportunity” (i.e., a market problem) and should be leveraged to shape your product vision and direction.

From customer problems to a product vision

Getting from an identified customer problem to a solution, a Product Manager has to align teams such that they understand the value of solving these problems, which as Ben and Blair describe can be done in three steps:

1. Define a product vision that is “a bridge between your company vision and what your teams do every day and demonstrates how your product will help to achieve the company vision”.
2. Establish clear metrics of success. Define Key Performance Indicators (KPIs) for your releases and put mechanisms in place to track them.
   To more easily define KPIs, Ben and Blair advise defining Objectives and Key Results (OKRs) first and then deriving your KPIs from these goals.
3. Create a core team that is accountable for product success. Since in an enterprise company there are different product lines and competing priorities one needs to organize and align. This means making sure everyone understands the connection between your product vision, your strategy, your OKRs, your customer problems, and your solutions.
   Ben and Blair particularly advocate using the “Product leadership team (PLT)” for alignment, which consists of participants from different departments and “rules on project proposals and tries to reach consensus among teams and departments”.

Chapter 4: Organizational knowledge

To make your product successful you need to understand how your organization works to best navigate through it. For this, Ben and Blair examine how Product Management relates to the following roles.

Development

Ben and Blair characterize Development as the ones who build the product and Product Management as the one who tells Development where to go.
In growing companies, Product Management usually steps in to address business, market, and customer demands so that Development can become more focused. To achieve this, the authors describe and divide responsibilities from sprint planning to execution.

For example, during planning, the most important aspect for a Product Manager is to make sure that the customer problems you want to tackle with an epic, as well as the value of solving them, is clear. Additionally, a Product Manager should be available whenever questions arise from developers and provide them with the necessary context to answer them.

However, like so many other authors, Ben and Blair warn to come up with solutions for such epics but instead let the teams figure out the solutions themselves. Yet, they also urge you to hold these teams accountable to timelines and commitments by making sure they stay focussed on the valuable parts.

Design

“The relationship between product management and design is what makes the difference between an average UX and the kind that delights users”

Ben and Blair claim that bringing together Design and Development while providing them with an understanding of the customer problem and the market opportunity, is the main responsibility of a PM.
In this respect, one of the main challenges for a PM is to bridge the gap between how the product is bought (customers) and how its used (users).

In general, if a PM makes sure that all involved stay focused on solving the most valuable problems first, a good designer will take it from there.
To provide this focus, Ben and Blair, for example, propose establishing core tenets together with Product Design. Because such tenets make it easier to return back whenever the team drifts away in sessions. Since I’ve already experienced several times how such tenets make discussions way more efficient I can only urge you to define them as well.

Ultimately, Ben and Blair suggest involving designers early on, ideally already when creating your strategy and roadmap, because, and I agree with that, “good design takes time”. Thus, the sooner you involve them the better.

Executive (execs)

As Ben and Blair state, “we all work for someone” and that someone wants to get answers to questions around:

• status — How are we doing?
• roadmap — Where are we headed?
• strategy — Are we doing the right things?

With respect to status, executives’ primary interest lies in sales and/or user growth data, where they most care about metrics such as closed deals, average deal size, or seller feedback.
To provide answers to roadmap questions, Ben and Blair advise having a quarterly high-level roadmap with the most important milestones on it.
For selling items on it, Ben and Blair suggest telling a story about your customer problems, where you blend personas and data in a narrative in such a way that your executives can empathize with them.
Finally, for answering strategy questions, they suggest laying your strategy out in the context of your executive’s broader vision so that they see how your projects influence your executive’s world. For example, by relating what you communicate to the most important business metrics like ARR or bookings.

Marketing

Ben and Blair claim that great marketing is like “a jetpack for your product”. To best collaborate with Marketing, Ben and Blair suggest for Product Managers to be the “go-to contact for expertise on the product” and to meet Marketing at least weekly or bi-weekly “to guide them”.
While both should rival for a deep understanding of customers and their problems, Marketing should own and create narratives around the product.
These narratives can then be used externally when talking to the customers or internally when talking to other teams. In cases you don’t have a dedicated role in marketing, Ben and Blair suggest having at least a basic sales kit that answers fundamental questions about what the product is, what its key benefits are, and core messaging.

Tips for communicating with Marketing include involving them early and often to perfect your messages for sales and producing succinct sound bites rather than technical specifications. To help them tell the story, provide them with needed context to understand your customers’ problem, your value proposition, details about your solution, and customer examples.

Sales

Ben and Blair claim that shipping is only the start for a Product Manager, as opposed to consumer software, and thus advocate not just establishing a strong relationship with Sales but also understanding the sales- and product hand-off process. For instance, they mention participating in big sales deals or RFPs, as good starting points for that.
To acquire a deeper understanding, Ben and Blair recommend interviewing Sales and asking them about their incentives as well as what, how, and where they sell your product. Also knowing at which stage prospects decide not to buy is something important that Sales can help you with.
Besides such activities to get an understanding of processes, Ben and Blair provide a great overview of the different roles in Sales and explain how you might best engage with them during interaction points such as roadmap presentations or when answering technical questions.

Tips for communicating with Sales include helping your Sales reps translate “what a feature does” into “how a feature wins” (e.g. by using case studies, or examples from references with ROI). Most importantly you should be transparent and offer them insights into why you aren’t building things they requested to build trust. E.g., delivering their request means deprioritizing bigger things all customers would benefit from.

Chapter 5: Product Knowledge

Product knowledge, as Ben and Blair describe, is “The elements of how your product is planned, launched, maintained, and sometimes, withdrawn from the market”. To acquire it, you simply start using your product “as closely as possible, as your customers do”, as Ben and Blair explain.
This includes understanding the architecture of your product as well as knowing important collateral such as the product documentation.
Learning all this should help you demonstrate your product’s main functions in front of your customers. For instance, one of Ben and Blair’s team regularly met up every Friday over chips and whiskey, where they use the product according to real-world scenarios gathered from customer interviews.

One interesting belief raised by the authors is that to penetrate an enterprise software market you require Sales, since “one does not growth hack their way into the enterprise tier”, the authors state, and list “higher complexity” and “longer sales cycles”, as the main reasons. As an aid to the longer sales cycles, they advise gathering feedback from customers and prospects before a release. For example, by using a “preview” or “early adopter” program.
In addition, they advocate making feedback gathering a regular exercise, not just on a release basis, and call this “long-cycle discovery”. They claim that this helps discover “revenue-generating products” rather than focusing too much on releasing new features for existing products, which usually only add minor value and are “revenue-neutral”.

Building the product roadmap

The roadmap is “the most visible part of your work” that serves internal and external purposes such as “Clarification on high-level goals and alignment..” or “Communicating new upcoming capabilities”. Besides these purposes, Ben and Blair point out that customers and prospects do not just buy your product as it exists today but invest in its development and its vision. Thus, Ben and Blair see a roadmap as a tool to demonstrate your customer’s and prospects’ return on investment and therefore recommend putting items on it that address both, your existing customers (to retain them) and your prospects (to sell them on your vision). In terms of commitments on your roadmap, Ben and Blair advise to “underpromise and overdeliver”.

The role of customer input on the roadmap

While customer feedback is important and should influence your roadmap, it should not become a wishlist for your customers.
A good way of gathering that feedback, as Ben and Blair mention, is the Customer advisory board (CAB), where a collection of executives of your customers are brought together and where you can present your roadmap, solicit feedback, and validate the business value proposition for solutions.

The planning process

“it’s probably impossible to predict much of anything beyond 12 or 18 months in the tech industry”

Given the quote, Ben and Blair believe that a one-year product roadmap is just right because anything beyond will change anyways. They also provide a good reference process in the book you can follow and learn from.

Measuring success

Measuring means answering how your product is doing and defining what success or failure means. For this, Ben and Blaire recommend tracking and improving metrics within the area of sales, users (e.g., user growth), and engagement (e.g., actual user adoption and usage) and illustrate what results and combinations of thereof could potentially mean.
For example, growing sales metrics while user and engagement metrics aren’t growing, might mean that your Unique Selling Proposition (USP) resonates with your customers, while the value of your product isn’t clear to your users.
To validate such a hypothesis, Ben and Blair also provide follow-up questions for each such scenario described.

Planning the product end-of-life

To avoid losing customers when migrating them over, Ben and Blair argue to plan your product end-of-life (EOL) carefully together with internal departments such as Sales. They particularly recommend teaming up with Marketing, who can assist to develop announcement plans and communicate the EOL to customers. Such communication should at least include an explanation for the EOL decision, a walk-through of the migration plan, and how you intend to assist. They also provide guidance on how to migrate customers to either a successor product or a selected competitor as well as thoughts about how to overcome more complex migration scenarios (e.g., by using professional services).

Chapter 6: Building better products with data

“Analyzing data to understand how people actually buy, implement, use, and retain your product is your best chance to build the right thing quickly”

In this section, Ben and Blair elaborate on the different kinds of data one can and should leverage when building products. They particularly argue that building products based on qualitative data (aka feedback) only has the following two big limitations:

• What customers say, for example in surveys or customer calls, is not always what they do.
• While observing your customer during user tests or customer calls is very valuable “it doesn’t scale” since you’d need to watch “at least several dozen users try to accomplish similar results” and even from many users “it is difficult to draw widespread conclusions from observation alone.”

To come around these limitations, they advocate using more quantitative data because it not just allows seeing broader trends in your user base but also scales better than qualitative data (often called feedback).

“The best enterprise product managers are capable analysts who can ask good questions (and pose hypotheses) and then answers those questions (and attempt to invalidate those hypotheses) using data.”

The reason why measuring and data analysis is still more popular with consumer software products is because quantitative data is more easily available and at a greater scale when compared to enterprise products. Conversely, with enterprise products, you usually have more direct contact with your customers and therefore gathering qualitative feedback is easier.
They also provide a good overview of the following different qualitative and quantitative sources from which to gather feedback:

• Product usage data. To get started good questions include “Which features produce usage, which can be retired?”, or “Which settings are used and make a difference?”. Follow-up questions could be “How do users break out into discrete groups/clusters along their journey?” or “How do your most habitual users differ from others?”.
• Sales and finance. While sales data is often part of your product goals, according to Ben and Blair, it’s important to know important sales KPIs such as bookings, revenue, or retention attrition.
  Whenever you are not on track, Ben and Blair advise using basic sales and finance data such as customer-by-product, annular recurring revenue, location, or other sales team attributes to get to the core of it.
• Industry data Among other things, Ben and Blair mention your Total Addressable Market size, as an important metric to know and track as well as industry studies or competitive intelligence.
• Testing data. Here the authors elaborate on why doing A/B tests can be limited for enterprise software products, which is mainly because enterprise customers don’t expect any unannounced changes as well as discrepancies in the UI. Therefore, Ben and Blair suggest starting testing with statistically significant but small groups of users and focusing on minor changes first, or, using a “preview” or “early adopter” program.
  For more extensive changes they recommend using prototypes to allow users to explore them before they are built into the product and not risk alienating them.

Chapter 7: Industry knowledge

Industry knowledge is something “…that both new and experienced product managers in an industry will need to continually strive to obtain, especially given the pace of technological change…”. Ben and Blair further divide it into market knowledge and customer knowledge.

The basics of your market (market knowledge)

Market knowledge is what guides you in the process of defining and maintaining your product vision and helps you explain why what you offer is valuable. It answers “What is the market in which we operate going to require of us in order to grow our business? and consists of:

• The Total Addressable Market (TAM), defines where you play and represents “the value to your customers of solving a problem” and “the value to your own company of solving that problem”.
  Yet, Ben and Blair warn that with each new feature or product this number updates! To determine it, they advise you to first conduct your own analysis or to leverage analysts like IDC. For example, you can use “…your competitor’s financial statements or funding, and work backward to guess at a revenue”, Ben and Blair suggest
  Using the TAM alone, however, isn’t enough to decide which market to enter. Therefore, Ben and Blair advocate factoring in the Compound Annual Growth Rate (CAGR), which is the rate of growth for any such market. They finally illustrate, based on an example, how a smaller market, with an initially smaller TAM but a higher CAGR, can easily outgrow a bigger market over time.
• Market drivers are important to find your market and to see how major trends within it “affect how people think about your product and industry”. To find them, Ben and Blair suggest looking at the world around you. For instance, looking at other industries might let you “find emerging markets or emerging personas in existing markets”.
• The most common problems your customers face can be gathered by regularly talking to your customers and by making sure they open up.
  Only then do you learn what’s on their minds, understand what’s preventing the majority to grow, and how you can help them, they claim.
• Your competitive landscape is important. However, Ben and Blair emphasize that you should neither obsess about your competition and their strategy nor should you ignore them. For them, it comes down to knowing “Who you compete with”, “Why the others win…”, and “What their strengths are”. They recommend using a SWOT analysis to answer these questions.

Ben and Blair also demonstrate how vital it is to apply a “soft mind”, which means to stay “humble and receptive enough to know that the only constant in tech is change”.

“Break all the rules, it helps to first master them.”

Therefore, they constantly challenge what you know about your market and underline the necessity to continuously revisit the tenants thereof.

Learning your market (customer knowledge)

Customer knowledge answers which problems customers face within your industry and tells you more about their personas to better empathize with them. It is bout figuring out what your customers do and why they do it so that you find “what keeps them up at night”. Because these stories usually indicate big, high-value topics that customers would also pay for.

For this, they recommend scheduling and running at least 6 customer meetings each quarter, where you bring your engineers and designers along so they can experience true pain and frustration. Such meetings can fall into either of the following categories:

• Discovery interviews to better understand the challenges of your customers and what prevents them from growing. While each customer is unique, these interviews are perfect to find patterns across customers. However, it is important to not focus solely on acute problems but to look for problems of tomorrow. So instead of asking them for what they want you ask them for what they want to achieve and where they struggle to get there. They suggest starting with general questions, listening, and following up with refined questions based on their responses.
  Doing this will increase the odds of finding their true business needs, not their wants or wishes.
  To make this easier, Ben and Blair advise “talking to a variety of personas” and “to prepare and bring a series of general questions”. They offer a great set of sample questions in the book.
• Observation is a great alternative because interviews alone won’t tell you what end-users really do, but often only what they say they do, as Ben and Blair point out. Thus, sitting with your users and seeing how they interact with your product, is more sufficient to see where your users run into issues and to notice flaws with your end-user experience.
• Quarterly business reviews are regular checks in with your customers which are led by your account team or Customer success and PMs are usually invited to present and discuss their product updates. If these meetings are done well and at scale, they allow you to ask probing questions related to your product updates, turning these meetings into customer problem discovery sessions (i.e., finding new use cases, exposing yourself, and building your brand). They perfectly allow internalizing your product vision and strategy as well as practice explaining them.
• User testing and prototyping meetings are always tied to features or projects and are where you show mocks or even interactive prototypes of what you are going to build to an end-user. The main purpose of these tests is to gather early feedback, making sure that your envisioned solution actually solves the problem. Because as Ben and Blair note, without such tests you are just guessing, and potentially wrong half of the time.

Because it usually doesn’t stop with meetings, Ben and Blair talk about approaches of how to best analyze your experiences made during such.
One intriguing approach mentioned is to run a team meeting, where you present and discuss whom you met and why. There you go through what you wanted to learn and what you concluded in terms of insights and action items.
In general, when you get out of meetings, Ben and Blair, advocate immediately documenting and sharing your notes internally (e.g., on a central wiki page) as well as asking others for specific input for certain parts, rather than for their general feedback.

Chapter 8: The Product Managers

This chapter is all about how a Product Managers career.
They write about how individual contributors get into Product and when to best consider a change, for example, to go into people management.
For example, true and good advice about getting into Product is to do other jobs first. They claim a Product Manager is a generalist role by nature, which means doing other things first will benefit you later in your PM career.

For me, the most beneficial part of the chapter was the list of things a Product Manager usually spends his or her time on throughout the day that includes:

• Staying on top of development status by reviewing it every week and having a meeting with your development manager at least bi-weekly.
• Getting input from sales on a regular basis (every few days), keeping channels open, and “informally see what’s up”.
• Gathering customer feedback. Includes actions like checking questions via support, participating in implementations; reviewing usage data; regularly checking what they say about you or competitors.
• Syncing with marketing to align content and collateral generation
• Gathering industry knowledge to spot and not miss big market trends.
• Planning, coordinating, and sharing information by working with the product team and meeting them at least once a week
• Thinking deeply about the product, the customers, and the problems you solve. Short and long term! They suggest doing this by either spending time “quietly and alone” or by “brainstorming with colleagues”.

Conclusions

Ben and Blair did an amazing job outlining how B2B style enterprise software creation works, however, also point out that most of the theories outlined in the book should be taken as “ideals”.

The one thing, which repeatedly shows up in the book, and that I believe is the most important, is to deeply know and understand for whom you are building your products and why. The rest, such as a vision, a roadmap, or collateral for internal departments or your customers will then naturally follow from that.

I hope you enjoyed reading my summary and please, feel free to leave me your comments on how I can further improve! I would particularly appreciate it if you could let me know which parts are unengaging to you or which should be removed entirely?