Building Products for the Enterprise: Product Management in Enterprise Software

by Blair Reeves

In most high-functioning organizations, other teams rely on Product to help them do their jobs more effectively. Development relies on product management to define a plan and write user stories, requirements, and acceptance criteria that explain what needs to be built. Marketing relies on Product for product information, value proposition definitions, business case material, market intelligence and, sometimes, content. Sales relies on Product for much of the same, plus determining target market segments, demo cases, answering detailed inquiries, and helping to close deals. Finance and Product rely on each other to build the business through determining pricing, margins, discounting, and so forth. Leadership relies on Product for execution on overall product and business strategy. Across all of these cases, Product is the key index and what keeps all of them churning toward the same destination.

There are really three big elements that make product management in enterprise software different: our business model, our specialization, and the split between our customers and users.

Our challenge as product managers is not only to make these tools deliver more business value over time with new features, capabilities, integrations, and so forth; it’s also to understand how our users work, what their jobs and industries are like, and how our products fit into their lives. This is especially true after your product breaks out of the “point solution” category (i.e., meeting a very specific, constrained business need) and grows to encompass multiple different use cases, roles, or industries.

Applied to product management, the guiding principle here is deceptively simple: figure out who you’re building for, and why. If your strategy is sound, don’t deviate from it every time a customer or sales rep makes a demand. That’s how you develop a short-term product perspective, which obviously doesn’t produce the kind of innovation that redefines industries. If we had to boil down product management into two things, it would be these: figure out who you are building for by deeply understanding customer problems, and figure out how to build by driving alignment across teams.

Fundamentally, whether in consumer or enterprise software, good product management involves recognizing and deeply understanding problems. The people who buy and use your software have them. The better you empathize with those problems and internalize them deeply, the better you’ll be able to express them to your management, your design teams, and your development teams, and be able to solve those problems by delivering relevant solutions.

We believe that a good way to approach your role as a product manager is to treat customer problems as the “currency” that allows you to build alignment around a specific product vision. As a product manager, there is no better way to gain the trust and respect of the groups you’re trying to align internally than to consistently and confidently articulate customer problems and why they are critical to the companies that buy your software.

Solve customer problems in a way that pleases your users, and solve user problems that make their organizations’ overarching business goals easier for your users to obtain.

Here is how we recommend product managers begin to create consensus around an approach to solving customer problems: Define a product vision Establish clear metrics of success Create a core team that is accountable for product success

As the product manager, the best way to establish your product vision (if there isn’t already a clear one) is to figure out how your product will help your company achieve its vision. After the product vision is clear, seek to establish the categories of innovation that your product needs to pursue to achieve that vision. You will end up with a hierarchy looking something like Figure 2-1. Figure 2-1. Breaking down the corporate vision into product features We propose being very clear about this hierarchy, and as you present your ideas to colleagues, go through something similar to but hopefully more visually appealing than Figure 2-1. Remind management how your product connects to the company vision and how the relevant aspects of the product strategy help realize that vision. You’ll be all set up to explain how the project you are seeking to undertake brings that product strategy to bear.

An epic is one large collection of stories which should, in some meaningful way, represent encapsulated, material progress toward your broader product vision, whereas stories often constitute incremental steps toward completion of an epic. At the beginning of sprint planning, you should sit down with your development team(s) to go over the epic(s) in question and make sure each member of the team understands the value it represents to your customers (and, if applicable, your users, too). Only then can you begin the process of decomposing that epic into individual stories, and the requirements that might make up each one. Before we get to divvying up those requirements, let’s talk for a moment about the person who actually does that: your development manager.

As a general rule, if given the choice between saving our credibility with the customer and taking on some technical debt, we will take the technical debt seven days a week, with a double serving on Sunday. Typically, technical debt can be resolved a lot quicker and more cheaply than building back a customer’s trust.

For many enterprise product managers, design (i.e., UX design) is the only team with which you will work as closely as you do development. It is sometimes said that product management owns the customer, and design owns the user; if this is true, bridging the gap between how your product is bought and how it is used is one of the most important things that can come out of your communication with design.

Enterprise software sellers deal primarily with the executive stakeholders who own the buying decisions over your product. They don’t typically care as much about “user problems” as much as they do “customer problems” (the business factors which influence check-writing executives’ decisions over whether to sign on the dotted line). This often means that there is comparatively more “signal” in their feedback to product management. Product managers should take every opportunity to absorb this feedback, either structured (as in a monthly sales team meeting that you better be attending) or unstructured (go grab lunch with your West Coast sales lead when he’s in town).

Another good approach to “testing at scale” in enterprise software is to let users “opt in” to testing via a “public beta” or other “labs” mechanism, so that those who feel comfortable finding their way around potentially unfamiliar features or workflows know what they are getting into. This is not strictly A/B testing, but is a good way to gather feedback on changes to your product before they go live so that you can ensure your improvements will have their intended effect and solve problems for your customers.

Whenever possible, have an engineer or two and a UX designer join you for these meetings. Engineers are great at solving problems. They are where much of your best innovation will come from. Connecting them directly to the customer gives them an (all-too-rare, unfortunately) opportunity to develop empathy on a first-hand basis. Rather than having you send them a bunch of notes that you took, which can read as dry and impersonal, they have an opportunity to meet a real human being, with real motivations and real challenges. This will hammer home the frustration inherent in the customer problem and generally produce better software solutions at the end of the development process. We cannot stress enough how valuable it is to involve engineers and designers in these customer meetings.