Building Products for the Enterprise

Chapter 4. Organizational Knowledge

Enterprise product managers work with a dizzying array of teams and roles, from engineering and design to sales and marketing (and more!). Knowing how to get the best work out of each group in an enterprise software context takes practice, but is a key skill on the path to product management success.

If you play any sort of musical instrument, you already know that playing solo is an entirely different ball game than playing with other people. Although some amazing music was only ever meant to be played unaccompanied, pieces for a string trio or quartet can be positively magical. In a small chamber ensemble of three or four, personal player differences matter tremendously. Each member needs to know exactly what the other musicians are doing and the minute variations in how they tend to play in order to adjust their own tone, volume, or tempo at the slightest cue.

Yet precious as it might be, no quartet can ever do what a full orchestra can to convey the majesty of a great symphony. In an orchestral setting, individuals have a bit more margin for error (unless you’re first chair—in which case, go practice). Yet the trade-off is that a good orchestral player needs to keep track of many more parts, too. These players need to know what the first violins, violas, percussion, or winds are doing in the next few measures so that they can prepare their part or entrance. They must adjust their volume to account for the cellos (who are, of course, the backbone of any orchestra¹). If you come in a quarter note before the timpani at a forte, well…that’s going to be an embarrassing night.

There are many parallels here to product management in a mature software company. At its best, a software organization that is firing on all cylinders and executing perfectly closely resembles a world-class ensemble like the Berlin Philharmonic or Chicago Symphony Orchestra, whose many different parts harmonize and support one another. Product management (just like the cello section) is a critical function in making sure this entire organization is aligned—if not toward a common goal, then at least toward mutually interlocking and supportive ends.

Day-to-day collaboration with five stakeholders in particular make up a sina qua non of enterprise product management: development, design, executives, marketing, and sales. Simply put, developing effective and value-adding working relationships with these five groups of people will make or break your success as a product manager. Over the next several sections, we delve into the organizational knowledge you need to work with each of these teams to make your product successful. In each section, we also share some tips to help you communicate more effectively with these groups.

Development/Engineering

There is arguably no working relationship more important in the organization than between product management and development/engineering. (Note: in the interest of brevity, we refer to this group simply as “development” from here on out.) It is development’s job to build the thing; it is product management’s job to explain to development what to build. One without the other is either useless or flying blind.

The independence of development teams tends to vary greatly depending on the size and maturity of the organization. A small startup, for example, might have no product management function at all, and just one or a handful of developers. The CEO or CTO or head developer is effectively the product manager in this case. As the company grows, however, the sophistication of the software product tends to increase nonlinearly, requiring developers to be much more focused on engineering and maintaining the solution and less on the sprawling business, market, and customer demands that product management steps in to address.

Thus, in growing companies that have emerged from the startup category and graduated into a growth stage, defining roles and responsibilities between product management and development should help make the latter’s job easier, more focused, and better aligned with maintaining a high level of productivity. This transition requires a lot of trust between both teams—the last thing anyone wants is conflicts over turf and responsibilities. One excellent and frequent solution in this case is to promote to product management from within the company.

More mature companies have typically established a clear standard operating procedure for how product management and development work together. These will often rely on a common paradigm for software development like Agile/Scrum or a Waterfall model. We’re not going to delve into the pros and cons of these frameworks here—not only have oceans of ink already been spilled debating them elsewhere, but the applicability of different models is highly dependent on contextual specifics that teams in the field know much better than we do. Suffice to say, we trust that development and product management have already wisely chosen the best software development process for their particular situation. Nevertheless, new product managers who aren’t familiar with these frameworks already are strongly advised to become acquainted with them, at least.

No matter which framework you use, you’ll need to begin with a basic idea of what you want to build and where you want to get to. In Chapter 5, we discuss how to use market and customer input to build a product vision and strategy; for now, we get into the nitty-gritty part of putting that strategy into action. Rubber, meet road.

Structuring Work with Your Development Manager

To scope and plan work clearly, we use the Agile concepts of epics, stories, and requirements, which are fairly standard in the enterprise Software as a Service (SaaS) world. 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.

The development manager can either be a designated senior developer or, in more mature teams, a person with a specific competence and sole focus on engineering project management. We cannot stress strongly enough how great an asset a strong development manager can be for your development team and your company as a whole. The best development managers we’ve worked with provide a few highly specialized skills:

• They intimately understand the technical strengths and weaknesses of each individual developer on their team, which allows them to more effectively assign and structure work to be done.

• Experience allows them to accurately estimate the level of effort (i.e., “story points”) required to complete work on the backlog.

• They can raise caution or red flags early about problems anticipated or encountered, and help brainstorm workarounds.

As a conduit of team-specific knowledge, your development manager makes effective planning possible over the course of many sprints. With accurate story point estimates and work logging, you can derive better velocity estimates—basically, a measure of how much work can be completed within a given timeframe—which enable process improvements as time goes on.

When it comes to assigning requirements, defer to your development manager’s judgment. Product managers are typically more helpful in answering developers’ one-off questions that arise about specific requirements (e.g., “Should this list show full descriptions, or excerpts?”) than in getting deeply involved in details about the technical specifics. This distance can be difficult for ex-developer product managers to keep, but ultimately allows development to be more efficient at its job.

How Technical Should Product Managers Be?

This touches on a common debate in product management circles: just how technical should product managers be? As we’ve mentioned before, our view is that product management in enterprise software is an operational, cross-functional role, of which technical know-how is only one part, and not the most vital. Even if the product manager is an experienced developer, most enterprise software involves sprawling, intricate code bases, often with spotty or incomplete internal documentation that few, if any, individuals fully understand in its entirety. To go mucking around in that world, a developer needs to tread gingerly and possess the understanding of what he’s doing that comes from living in that code base day in and day out. That does not describe most product managers, which is why our recommendation is that most product managers should not be touching code. Of course, there can be certain types of product manager roles for which direct code base contributions are appropriate, but in our experience, those are few and far between.

What to Do When Things Don’t Go According to Plan

When you hear the word “engineering,” some of you might think of Montgomery Scott (“Scotty”) or Geordi LaForge, both engineers from the Star Trek universe. On the fictional USS Enterprise, Engineering’s job was often to assess risks, play it conservative, and say no when Captains Kirk and Picard (respectively)—much like product management often does—asked them for the impossible. Seemingly in every episode or film, the captain would thoughtfully push back on engineering’s concerns, and engineering would pull a miracle out of its hat. Working cooperatively, engineering and the captain save the day.

Just like Scotty or Geordi on the Enterprise, your own engineering team has a natural tendency toward conservatism. Developers would always (and understandably) rather take more time rather than less for prototyping, testing, QA, and so on. This is where product managers sometimes must step into an investigative role during a sprint and ask why certain stories are taking longer than expected, why velocity is down, and sometimes reprioritize on the fly so that critical work is finished before less-critical stuff. Just like before, the development manager is a vital partner here who can explain what new issues arose that slowed down progress. Some delays and unforeseen obstacles are just inevitable, and communicating them early helps to set expectations for that sprint’s outputs. Other times, understanding why certain stories or requirements took longer than expected can lead to avoiding similar delays in the future, which is a good use of a post-sprint review.

Yet, inevitably, one day you’ll be nearing the end of a sprint when you see that a high-value story or two look to be at risk of slipping out of the release. You’ll go talk to your development manager, and she’ll explain the reasons why, but the long and short of it is that the story is at risk. What do you do?

The answer will, of course, just depend on your situation. But here are two competing considerations that might help you think through this dilemma. On the one hand:

Technical debt can be a tool

A lot like consumer debt, technical debt—i.e., putting off important engineering work that might not have immediately obvious customer value, such as refactoring inefficient code—should be avoided wherever possible, because it will always catch up with you and usually cost more to resolve in the long run. Yet also like consumer debt, technical debt can be an effective tool for solving short-term problems. In enterprise software, we often telegraph certain features or upgrades to customers in advance, and when we don’t deliver them, it creates bad will and hurts our credibility in the future. 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.

And on the other hand:

Rushing out bleeding-edge features is risky

“Move fast and break things” is a recipe for disaster in enterprise software. With the obvious exception of early-adopter or beta user scenarios, rolling out lightly tested, “bleeding-edge” features without adequate QA and feature hardening 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.

No, we aren’t being cute. Both points are true, and like any interesting problem, they will require application within your own specific context. Some questions you should consider are: How important are those high-value stories? Are customers waiting on them? Can you roll them out with reasonable confidence that they’ll work as intended? Does sales need them to build pipeline? What work will have to drop out of the sprint, or what technical debt will you incur because you chose to finish those stories instead of other items? Only after talking through these questions with your development manager can product management decide on an informed course of action.

Communicating with Development

Helping development understand customer problems deeply enough that they can innovate to solve them is worth every minute that it takes. Here are some tips to help you think about how we communicate with our development counterparts:

Help them grasp the problem and then let them figure out how to solve it

This might mean putting them in front of customers directly, so that they can see or hear customers’ pains with their own eyes and ears. Where that isn’t possible, it means communicating back what you’re hearing from customers, prospects, and the market. But beware of being over-prescriptive of describing solutions to problems; you likely work with engineers who are great at solving problems with technology after they understand the problems and use cases at hand. Engineers’ solutions, in most cases, will be better and more complete if they are allowed the freedom to innovate without being told exactly how many columns should be in the database or how many pixels high the button should be. If you are overbearing in your communications with engineers, do not be surprised if you get exactly what you ask for instead of much more.

Hold them to timelines and commitments

Engineers often tend to want to solve the problem comprehensively, and the more they learn about the problem, the more they see things that should be added to the solution. This is the dreaded scope creep that can threaten timelines, which (at least in enterprise software) are usually driven by product management or executive leadership based on a variety of market factors that might not be apparent to development. Even in organizations that have a mature project management function, it is incumbent upon product management to keep committed timelines front and center and to help your engineers remain focused on the most important parts of the problem such that features ship on time and do not continue in perpetuity until they are “perfect.”

Have your team’s back at all times

As you talk to your development counterparts, make sure they know that you win and lose as a team and that, if necessary, you will accept blame if something goes wrong. Great development practices can often involve taking significant risks—betting on an unproven but promising DBMS or implementing a JavaScript framework that they think will scale, for example—and this is often where the best innovation happens. Never blame development for earnestly trying to do what you’ve asked, even if they failed. This alone will win you many acolytes among your developer colleagues. Never use the word “they” when you can use the word “we,” instead.

Defer credit

Similarly, never use the word “I” when you can use the word “we,” instead. Most of the time, despite being the ones who spend long days for weeks and months designing and perfecting a solution, engineers aren’t the ones on stage at conferences or presenting in company-wide meetings on the things they’ve done: you are. It can be easy to forget who made those opportunities possible. In many cases, development is like art: the creator of the solution is inherently proud of it, and feeling acknowledged and appreciated means more than just about anything else you can do. When you communicate with your engineers, and with others about your engineers, make sure to acknowledge their efforts whenever and wherever you can.

Don’t unduly alarm them with tales of escalation and attrition—but don’t lie, either

As their connection to the customer base, your attitude and outlook on your product’s future carries a tremendous amount of weight with development. A product manager who is all doom and gloom inadvertently conveys a sense of fear or discouragement to the development team. Be honest when customers are unhappy, but be optimistic—this is the team that can start to turn things around. Whenever you hear a CEO report missed earnings but convey confidence that things are going great, think of how you can similarly communicate bad news in a positive light to your engineers. But if bad news doesn’t need to be communicated, skip it.

Wherever possible, help them see how what they are working on is going to solve real customer problems and make your company lots of money. Everyone likes to feel that their contribution to the company matters. Share stories of deals won because of something that one of your development teams did. Talk in detail about the customer feedback that you’re using to justify asking them to do a project for you. Tell them how you are going to convey to the sales team what they are doing, and how you expect it to benefit the sales process.

Design

Conventional wisdom states that enterprise software often trades elegant user experience (UX) for customization and flexibility. Although that might have been true historically, the rising generation of enterprise software users (like us) grew up with the iPhone and Instagram; we are digital natives, and we expect better. Not every enterprise product manager will interface frequently with your design (which we are using as shorthand for “UX design”) team, but in many software organizations the relationship between product management and design is what makes the difference between an average UX and the kind that delights users.

In fact, what you might experience is that one of your chief responsibilities is bringing development and design together to brainstorm and hash out ideas. For example, you might come back from a meeting with a customer excited about a point of feedback; the customer has clearly articulated a use case and you believe solving it would be in line with your product vision, useful to everyone, and achievable. The next thing you might do is get an engineer and a designer into a room with a whiteboard to share what you learned. If you’re lucky, articulating the use case (i.e., the customer problem) might be the only thing of substance that you add to that conversation; from there, the light bulbs begin going off in a good designer’s mind as an experience comes into view for him.

Much more than just a creator of wireframes and mock-ups, your designer cares about how the user feels while engaging with the product; he considers how to solve the customer problem in the most elegant, holistic way possible. This is evident as your designer talks passionately about how a software product in a completely unrelated market solved a similar use case. Then, engineering chimes in with thoughts about how the designer’s proposal might work (or not!), and you’re off to the races as that exchange produces one outcome after another. It can be exhilarating to see how ideas become designs and designs become product! It usually doesn’t go as smoothly as we’ve laid out here, but this is one ideal to aim for.

Product management, design, and development can be thought of as a triumvirate that makes great products happen. Product management supplies a thorough understanding of the customer problem and the market opportunity; design discerns the user problem and a deep knowledge of human-computer interaction patterns; development adds the practical aspects of software creation (like resource constraints, technical limitations, etc.). Without the customer problem and market opportunity, design and development can lose focus on the product vision and build the wrong features. Without the user problem and knowledge of how humans engage with software, the problem might be solved in an inelegant or even unusable way. Without the pragmatism of engineering, obviously, software would never actually ship. All three roles are critical to making great software.

In fact, given that enterprise software is not traditionally known for being easy to implement and use, when properly involved in your process, your design team can become quite a powerful competitive advantage as they look for ways to solve new and existing customer problems in simpler ways. If you have the opportunity to work closely with design, encourage them to always be on the lookout for opportunities to streamline and reduce, focusing on putting the functionality that is most important to solving the problem first, and removing the clutter that is too often endemic to enterprise software. Even in this segment, products win despite not having as many bells and whistles as a competitor because they are a delight to implement and use. And if your product has all the features and good user workflows, it will be tough to beat indeed. Design can help you get there.

How to Involve Design

The first and most important rule of working with your design team is to make sure that they know what projects are coming down the pike. In other words, help them get familiar with the product strategy and roadmap. There will always be this or that unexpected small project that requires some input from the design team to make it successful, but if your design team has a good sense of what you are hoping to ship and when you will need design input, it can prepare. Good design takes time. Your designers will want to do their own research: meeting with users, exploring tools that have solved similar problems in creative ways, developing personas, and more. When you spring a project on the design team at the last minute, this process becomes rushed, and your design team will miss important context.

Beyond simply allowing your design team an opportunity to prepare and research a user problem, you will hopefully find that keeping your designers in the loop provides you with a group of partners who can help you innovate. Although they might not have time or the mandate to become market experts in the same way that you do, good designers are some of the most creative thinkers in your organization. Your market expertise plus their focus on users and workflows can produce some of the most impactful innovation of your career.

Ben experienced this as part of the Adobe Analytics product management team in 2012. Adobe was looking to extend its user base from the digital analyst to the less data-focused marketer. The customer problem—the growing need for more roles in the enterprise to use data and analytics—had been clearly defined, but it was the design team, not the product team, that created the UX paradigm of “data foraging” for the analyst, and curation and data consumption for the marketer, which resulted in the highly successful Analysis Workspace tool. Product management and engineering would not have solved this problem the same way, and if design had simply been presented with a proposed solution late in the process and told to make it look nice, the result would not have been nearly as impactful to Adobe or its customers.

One of the other essential benefits of involving the design team in the product development process is that it gives you an opportunity to provide feedback and iteratively hone a design before the product is built. We recommend holding both regular and ad hoc sessions with your design team to review its work. In many cases you, as a product manager, will have market or customer insight that hadn’t surfaced previously in the design process but that can help keep your product on the right track.

Lastly, use your designers to get feedback on designs and prototypes before your engineering team spends too many cycles building the wrong thing. Your engineering team might also take the lead on some user testing (both in the form of prototypes and alpha/beta tests), but your designers are the tip of the spear. Facilitate meetings with customers where your designers can explore what users like and dislike about a product design. Ensuring that users have a chance to give input at each stage of the development process is a great way both for your designers to hone their work early and for all involved to learn more about what your users’ motivations and preferences are.

Communicating with Designers

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. Here are some ways to make sure that communication channel stays open and clear:

Establish core tenets for product design and use those to stay aligned

Of course, you will want to help designers understand the business value of anything you are asking them to do (just like engineers), but designers are sometimes prone to wandering away from the vision and business value as they encounter new and bigger ideas. Establishing the core tenets of the product or features they are designing in advance and returning to those often in your communication is key. When the design team drifts from those tenets, this makes it easy to get them back on track. As one senior designer at an enterprise software company put it:

Help us understand the business value of a project, and keep reminding us of that value throughout the process. Also, you should help us in identifying the other few design principles that will be serve as the team’s North Star. That set of agreed upon items serve as a great rallying point when you and your designer don’t see eye to eye on something.

Let your designers play five years out, but be firm in bringing them back to the next six months

Many designers are visionaries, with brains that make connections between ideas in unique ways that lead to tremendous opportunities for innovation. This can sometimes lead them to take a very specific design request—“let’s make it easier to install our software”—and turn it into a wholesale reinvention of your platform. Great things can happen when they are allowed to explore on a grand scale, but do not be afraid to hold them to deadlines for coming up with ideas to solve the problem immediately at hand. In your communication, remind them that you are all committed to releasing features to market in the short term, and allow them to explore both the short-term and long-term in parallel.

Try not to say that an idea is bad; instead, propose a better one

Earlier, we discussed how code can be like art. That is doubly true of UX design, which is often quite literally art. As such, you’ll want to be careful dismissing ideas from your design team. One design manager told us of a project in his graduate program for which the professor made each student present their ideas and then had the other members of the class tear it to shreds as a way to “toughen up” these future designers and to teach them not to fall in love with their own work. Not many designers have had that kind of training, and constantly trashing their ideas can lead to long-term resentment. Couch your criticism in the form of improvement on the ideas that have been put forth.

Convey that you recognize that a good UX designer is more than just an Adobe Illustrator guru

No designer likes to be thought of as a mock-up monkey, producing beautiful screens with no context or clear purpose. Designing a true UX is a lot more than changing the color of a button. Concepts such as workflows, memory, personas, accessibility, intents, and problems-to-be-solved are the tools of the trade for true UX design. When you are giving feedback or brainstorming with your designers, make sure they know that you value these approaches to design. Talk about your requests and your customers’ requests in these terms. Make these concepts a part of every conversation that you have as you work together to design the product so that your design partners can produce actual experiences.

Executives

We all work for someone. Whether you’re a front-line product manager or managing the entire product group, eventually you’re going to be asked to give an update, status, or summary report to executives. Depending on the size and product portfolio of your company, this might include C-level management or someone significantly downstream but still very important. Either way, you obviously want to prepare carefully for these opportunities.

Typically, unless there’s a specific all-hands-on-deck issue at play, executives want some combination of the following:

• Status check: how are we doing?

• Roadmap: where are we headed?

• Strategy: are we doing the right things?

Fortunately, as the product manager, you’re already on top of all of these things. In fact, the most difficult part about presentations like this is how to summarize the relevant knowledge into something that is consumable in the time and attention constraints you face. One way to do that is to put yourself in an executive’s seat. Perhaps she is already an expert on all the minutiae of your product, but there’s a good chance she’s not. A good executive doesn’t necessarily need to be; after all, that’s your job. Particularly in larger companies, with lots of different product portfolios competing in tons of different markets, there’s a good chance that executives will look to you to not only be the product guru, but the market expert, as well. (We talk a lot more about how to do that in Chapter 7.)

But for now, you have 20 minutes with a senior vice president to give her and her direct-reports a full report on the aforementioned three bullet points, any of which could easily be an hours-long discussion by itself. Here’s how we might approach this:

Status check

Remember that at the end of the day, particularly in enterprise software, everyone is evaluated on sales growth, including your executives. How are sales faring against the annual plan? Think green/yellow/red-light guidance here, which you can back up with seller feedback.

Executives are often interested in user growth and engagement metrics, too, but have trouble putting them into context, particularly as they relate to sales performance. Back up your green/yellow/red-light guidance with this context. (By the way, we go into more detail on measurement in Chapter 5.)

Roadmap

A high-level quarterly roadmap should more than suffice here. Outline on the epic level, not individual stories. Bonus: it usually fits on one slide.

This is an area where breaking releases into themes is doubly effective, both as an organizational schema and also as a way to “bucket” all the cool stuff you’re working on in a particular period. It’s easier for audience members to wrap their head around themes like “mobile security enhancements” or “database infrastructure” than you droning on about one-off stories like HDFS cluster upgrades.

Strategy

You’ll have to forgive us just a little snark here: every executive thinks they know business strategy really well, regardless of whether their hunches are correct or even applicable in your context. Needless to say, this is not a fruitful debate to engage in during your meeting. It’s smart to lay out your product strategy in the context of your executive’s broader vision.

Overall organizational strategy is not typically something in which front-line enterprise product managers have much say. More likely, your best course here is to demonstrate ways in which your roadmap hews to your organizational strategy (and the corporate vision discussed in the last chapter), and to provide data points that support (or, if necessary, counter) the current strategy.

There is a “Goldilocks zone” of strategic planning here. Many companies “over-strategize” their execution, leaving themselves little room to maneuver given new circumstances or information; others fail to strategize properly at all. Try to read which situation you’re in and adapt.

At a high level, executives, like anyone else, look to the product manager to know “what’s going on” around your product. If there are issues facing your platform or product, you should be in the informational loop; if there’s a customer who’s hopping mad (or who loves you!), you’re on deck; if someone has a question about something on the roadmap, you’re the person who owns the answer. Your answers don’t always need to be happy ones, and if you don’t know, that’s okay, too. Particularly with executives, the company relies on the product manager to be the “truth teller” of the organization as well as the executional lead who clears issues from the docket. If there are caution or warning flags to be raised, the product manager needs to do it. That can be uncomfortable, because it puts you on the spot; but, well…that’s the gig.

A good practice to get into when communicating up the ranks about your product is creating a regular, standardized status update document. This can be something as simple as a few slides (if your company uses those), or even just a formal document. It should include updated, summarized quarterly data on the major metrics you follow, like sales and closed leads, average deal sizes and germane seller feedback, roadmap goals in the quarter (or whatever other time interval) to come, and maybe a line or two about relevant news from your market or competitors. Try sending this up the chain and around your organization. You’re likely to find that many people really appreciate the summarized information.

Communicating with Executives

There have been entire books written on the topic of executive communication, and we won’t rehash the topic in its entirety here. Still, as a product manager you will likely have above-average exposure to senior leadership compared to many of your colleagues. Often you will need executive buy-in to ensure that your projects are funded by development and marketing, and in other cases you might need to convince executive leaders to buy a company, to consider a new market, or rearrange priorities—all recommendations or requests that can originate in product management. Because the stakes can be high with an executive audience, your communication skills need to shine:

Tie everything to the corporate vision and the product vision

The single best way to help your executive audience connect with your ideas when you communicate is to tie them back to the company vision (and, within the company vision, your product vision). This is more than just keeping your initial communication high level; it means not leaving a shred of doubt how what you are discussing connects to what your company is trying to do. You can leave it to your executives to make that connection themselves, but from where they sit, 50,000 feet above the fray, it might not be as obvious to them as it is to you. Restating your company’s vision and then drilling into whatever topic you intend to discuss is a great way to bring focus to any presentation, phone call, or email, and also shows that you have internalized what your executive team has put forth.

Everything begins with the business metrics

Nobody feels successes and failures more acutely than your executive team; to put it crudely, they have a lot more to gain and to lose as the business grows and shrinks. Relating your communication to the metrics that matter most—Annual Recurring Revenue (ARR), bookings, retention, and customer experience—helps put your ideas in context and show executives exactly how your projects are influencing the world that they care about. This won’t always be possible in every type of executive communication, but whenever possible, try to relate things to what your leaders care about the most. For example, consider weekly updates that your executive(s) might ask you to provide.

Although many thought leaders will tell you that a “good product manager isn’t busy,” truth does not always match the ideal. Your calendar might end up packed full of meetings with various teams about diverse topics and projects. It can be tempting to say things like, “Met with development team about Project Phoenix and came to understanding of path forward.” But this doesn’t tell your leadership why they should care what you’re doing. Avoid such travelogues. A better update might say, “Project Phoenix is on track to deliver a 30% lift in cross-sell six months after release. This week the team made the following decisions to help us reach that goal,” followed by enumerating how you’re going to get the product to that objective. It isn’t that your executives don’t care who you are meeting with or what you are accomplishing; however, expressing your activity in terms of its impact on the business is a better way to convey the value you (and product management) are adding to the company.

Bring data and tell a story

As a product manager, your in-depth knowledge of customer problems is unique in your organization. Conveying that understanding effectively to executives can produce meaningful change and get innovative ideas prioritized. You cannot assume that your senior leadership understands customer problems the way you do. The best way to help them grasp the frustration that customers (and the market) feel is to tell a story that blends personas and data into a simple but meaningful narrative. For example, you might begin by telling the story of one of the individuals you have met in your customer interviews and how this individual is currently prevented from growing her business. Relating that to market data (“This problem isn’t limited to XYZ Corp; a survey of CIOs by Forrester shows that 73% of organizations rate this problem as one of their most troubling…) creates a strong blend of emotional resonance (with the end user’s frustration) and logical reasoning (supplied by the quantitative data). This is actually a great tactic when communicating with nearly anyone, but with the limited time you have in front of senior leadership, persuasion in a few sentences or slides is key.

Complain about resourcing with caution

One of the most common product management pitfalls is to decry a lack of investment in development or design as the reason that a critical project can’t be completed. Resource constraints are real, but to the team managing your company, complaints like these can come across as defeatist and pessimistic. A better way to convey that you won’t be able to deliver on what has been requested is to explain what you can do, and why you have chosen to prioritize the projects that you have. That said, if critical projects are not receiving adequate resources, it is the product manager’s job is to raise a flag early and make the case for aligning resource allocation with the organization’s strategy. To the extent there’s a gap between the two, identify it early.

Enterprise software companies are often large, matrixed organizations, usually by necessity. As so often is the case, relationships and an understanding of the internal “social graph” are invaluable tools to get anything done and to route the right tasks to the right people. To the extent that you can navigate your organization more effectively, you will quickly become a much better leader and advocate for your customers and the product. So, get out from behind your desk and meet some people!

Marketing

“[Marketing] is the whole business, seen from the customer’s point of view.”

Peter Drucker

Great marketing is like a jetpack for your product. Software companies that are able to figure out the optimal blend of brand, solution, and product marketing and use it for demand generation connected to a capable sales funnel set themselves up for enormous success. Smart marketers are able to analytically demonstrate their “MROI” (marketing return on investment), which allows executives to approve bigger budgets, which in turn leads to more revenue—a beautiful pinwheel. We’ve seen marketing organizations able to show an MROI of 5, 10, and even 15 times, whose biggest problem was keeping up with all of their profitable growth.

Unfortunately, we all know that great marketing campaigns, like great marketers behind them, are rare. Much more common is middling, unclear, uncompelling, timid, or outright bad marketing. (We could tell stories!) Bad marketing is more like wearing a jetpack that doesn’t fly: it’s just heavy, cumbersome, and occasionally explodes in your face.

To reach its full potential, marketing relies on product management for guidance. The full gamut of product management’s interface with marketing (usually product marketing, creating an awfully confusing battle of “PM” acronyms) is impossible to outline here, but suffice to say that a weekly, or twice-monthly at least, check-in is a best practice. We most often find ourselves working with marketing on three themes. Let’s take a look at them.

Product

This is an obvious one. product management should be marketing’s go-to contact for expertise on the product, features, benefits, and value proposition. When there is an update or new release in the pipeline, marketing should be brainstorming with product management long ahead of time to ensure the relevant launch content is distilled and presented to the market in the best way possible. When a new product is being launched, product management needs to confirm that marketing grasps the relevant market details (the target user, industry, and value proposition) inside and out. In SaaS settings, product management, along with development, should also help marketing get set up with the appropriate demo and sandbox accounts. Everyone in Marketing should be encouraged to have a login into a sandbox environment where they can get a feel for the product and not break anything.

Customers

Product marketing (and sales) should be the only functions that rival product management itself for a deep understanding of their customers and end users. As product management, we need to compare notes with marketing on who our customers and end users are, what their jobs are like, and how our product makes that job easier. Sometimes, we can teach marketing a thing or two, but as often as not, they teach us! Only with full visibility of the customer can marketing do its job of crafting stories and narratives around our product that connect with customers and users alike, and both teams need to constantly reevaluate if our assumptions about them are correct.

Messaging

As product management, we own the product vision, embodied in artifacts like the roadmap. But turning that vision into consumable messages that resonate with customers is literally a definition of marketing. Coming up with good messaging and delivering it well are both difficult, incredibly underappreciated skills. (If you don’t believe us, go look at nearly any two examples of technical messaging, and try to tell them apart.) Let marketing handle this; they’re the experts. Product management should focus on giving directional input to ensure that the messaging aligns with what the product does, its business value for your target industries, and where it’s headed (the vision). Regularly revisit this and make sure marketing’s messages remain consistent with yours.

Managing Content

One of the most common requests of marketing by the larger organization is for content: customer-facing, market-facing, and internal. On most external collateral, marketing should be good to go—communicating with customers is their specialty, after all, and if anything, they’ll need at most directional guidance from product management. Internal content, however, can be a different story. Internal content can range from sales enablement materials and pricing guides to competitive comparisons, ROI business cases, and “battlecards” (i.e., one-page summaries of solution details and key benefits) for sellers in competitive sales situations. (See the end of this chapter for an example battlecard.) Product management tends to have more involvement with these. Wherever possible, we recommend tasking Marketing with taking the lead on developing tools like these, with product management providing input as necessary, and for owning their ongoing development (i.e., version control).

Along with owning customer-facing content, one thing we’ll touch on in the next section about sales is how to get sellers the content they need. In our experience, very few companies have a great internal content management system for this. In small organizations, it often boils down to something along the lines of, “Just email Bill; he’s got the latest and greatest.” This is, of course, the easiest option for a single busy seller, but it obviously doesn’t scale. In organizations with dozens, hundreds, or thousands of content consumers you need to reach, a superior solution is a central online hub where everyone can self-serve what they need. (Many of us shudder just thinking about the SharePoint sites we’ve all wrestled with to establish this very “single source of truth.”) Even when that sort of system is in place, invariably you will still receive panicked emails from sellers and others asking you to just send them what they want. We’ll go into much more detail about how to address this in the next section on sales, but for now, if this describes life in your company, don’t worry. It’s not just you or your company. Keeping all of the marketing collateral needed for a multiproduct solution organized, findable, and current can easily be one person’s entire job, and it is often a thankless one.

For the sake of our marketing friends’ sanity (and our workloads), clearly delineating roles and responsibilities around content creation (and maintenance) is crucial. There should be no question of whose responsibility it is, say, to keep the sales decks updated and to drive training content for sellers. Sometimes, this can be as simple as having a talk with marketing and making a decision; other times, it’s a good topic for your regular check-in, for which one item on your agenda should be looking ahead at events, trainings, or the like for content needs.

What If I Don’t Have Product Marketing Support?

It isn’t uncommon for certain products, or even product areas, to lack dedicated product marketing support. This can happen in smaller organizations because of a lack of headcount, or in very mature ones, for any number of reasons (including…lack of headcount). In these cases, what is product management to do?

For these circumstances, there is really no other option but to brew some coffee, fire up PowerPoint, and create a “sales kit.” One downside to product management is that we often play “cleanup” for other functions in a pinch. In our opinion, the absolute minimum your enterprise product’s arsenal of marketing collateral should include is the following:

• A basic sales deck that explains what the product is, what it does, its key benefits, and messaging. This usually includes screenshots as well, and plenty of swappable slides that sellers can use to tailor a deck to a prospect.

• An internal-only sales enablement deck, which is mostly the same as the aforementioned customer-facing one, with more technical detail slides at an appropriate depth, pricing and ordering information, internal contacts to ask for more information, and lots of swappable screenshots.

• One-page guide (pro tip: landscape mode!) with key product value propositions, messaging, feature details, and competitive points. (See Figure 4-1 for an example of a battlecard.)

• Optional: official product data sheets, whitepapers, and links to official marketing blog posts or relevant recent webinars

One final word: if you’re lucky, in your regular rounds with marketing, you’ll notice that certain gung-ho marketers are the ones who really become adept at your product. They’ll be the ones who can run their own demos, and run them well; who know the documentation and can go look it up without guidance; who, over time, develop a reputation with sellers and the broader organization for being the “go-to” source for information. These folks will become an outsized resource for you to lean on and are outstanding candidates for future product management recruits. Keep an eye out!

Figure 4-1. Example sales battlecard

Communicating with Marketing

Marketing, particularly product marketing, is product management’s right-hand partner in interfacing with the market. As such, communicating effectively with them should become natural as you practice it. When communicating with your marketing colleagues, keep these principles in mind:

Use product marketing to help turn your message into something perfect for your sales teams

Sometimes, it is difficult for product managers to separate themselves from the products and features that they are working on and to be able to convey the value succinctly. Sales comes to product management looking for a few sound bites that will make their prospects salivate, and they get back what sound like technical specifications. Your communication with product marketing is an opportunity for you to “try out” your own translation of technical specs to market value, with an audience that won’t immediately go try to sell it five minutes later. Product marketing should be adept at helping with that translation, but get them involved early and communicate changes and thoughts often to ensure that what gets in front of sales is as polished and convincing as possible.

They are often the ones selling your feature or your vision in the market, so don’t share more warts than necessary

When it comes to selling your vision at industry conferences, when speaking with industry analysts, on your website, and with the media, nobody is more potent than product marketing. These forums are critical to the success of your product, even if they do not directly result in new leads for your sales team. The nature of these public forums is that you will want to put a positive spin on your product capabilities and value propositions. Thus, product marketing doesn’t always need to know every limitation of a new feature that you are building. This isn’t helping them to lie, but it is allowing them to tell the most positive story possible without being burdened by more detail than they need.

Be technical, but not too technical

Whereas product managers might come from a more technical background or have a minimal aptitude for technical topics, product marketers rarely do. Explaining how your product works is great; a product marketer who can speak intelligently about the capabilities of your product and the higher-level benefits and value propositions of your product will take you far. But, as with the earlier point, product marketing does not need to be inundated with the minutiae behind the product. Helping them understand what the product does allows them to explain how a customer can use it to achieve some objective, and helps them craft stories that sales can use to win deals; helping them understand the trade-offs that the development team made between three different JavaScript frameworks, however, is usually more detail than they need or can synthesize into a story.

Above all, help them tell the story

Working with product marketing can be like working with sales, except that product marketing does not have the same intense focus on the current quarter of business, and working with product marketing scales your work with sales in the sense that product marketing can be a bullhorn for you, sending news of your product far and wide for your sales team to sell. Like sales, product marketing might need some extra help and context to understand your key value propositions and success stories from customers. The best thing you can do as you communicate with product marketing is to give them the raw pieces of a great story. If you have a good counterpart in product marketing, that person will be among the best in the world at turning a customer problem, a value proposition, details about a solution to the problem, and customer examples into a story that sales can use all over the world to win business for you. Make sure you are always giving them those raw pieces and then helping to fill in whatever gaps are necessary.

Analyst relations

We couldn’t very well ignore this minor, but important, stakeholder group. Analyst relations doesn’t always fit organizationally under marketing, but its aims are pretty well aligned, so this is as good a place as any to address this function.

Industry analyst firms like Gartner, Forrester, and any number of boutiques are a mainstay of enterprise software. The startup crowd loves to poke fun at them (often for good reason) because they’re culturally and strategically aligned with and for big companies. There is also criticism, which is somewhat unfair, that analyst research is tainted by a “pay to play” bias: vendor firms pay the analysts, who are also the ones judging the vendor firms. On the other hand, you might be surprised to hear the percentage of brands in your target market that rely on these analyst firms to help sift the viable software solutions from the ones making noise in the market without delivering real value. As a product manager in enterprise software, knowing how to use analyst relations to your benefit is a smart skill to have under your belt, but it requires clearly understanding the delicate give-and-take required.

Analysts don’t have a crystal ball. They mostly look at the same reports you do, and obviously have the benefit of far less sensitive internal data. That said, they do talk to a lot more of your competitors’ customers than you do, and probably a fair number of your customers, as well. They use those interviews to build market narratives that go into their research. Most of us at big companies have access to key analyst research on our markets, which should naturally go into the big funnel of your information diet.

The entire reason why enterprise software companies invest time and resources with analyst firms is because our customer base reads their research, and customer shortlists for vendor selection are often influenced by the most recent Gartner Magic Quadrant or Forrester Wave. Less frequently, companies will actually engage with an analyst to help narrow down their shortlists or even perform vendor selection based on a company’s contextual factors. For all of these reasons, it’s worth setting aside a day every quarter or two to have an Analyst Day with the lead analyst on your market from a given firm. Ask them to come and present their latest research, bring questions you have about customers in your market, ask for feedback on your high-level product roadmaps, and ask for the analyst’s views on how you’re doing. We recommend getting input from more than one firm (and, of course, it need not be just Gartner or Forrester; these are just well-known examples). Analyst retainers might be useful for you, or they might not be. We personally run into few situations in which we feel the need to call up an analyst about a particular problem on any given day, but your mileage may vary.

In doing all of this, be aware of how analysts’ incentives can affect their research. Analyst thought leadership is both their product as well as their marketing. It is not uncommon to see prominent analysts make dramatic, provocative, or even outlandish predictions, because the penalties for being wrong often aren’t really that high. Moreover, analysts, like everyone else, are heavily influenced by marketing. Their perspectives on market drivers, influences and trends, what defines “market leadership,” and so forth rarely venture very far from the general consensus. Analysts are much more likely to fluently speak the language of your market, and again, they talk with a lot of companies—but as humans, when we’re personally invested in a narrative, we tend to process new information in a way that supports that narrative. We recommend taking analyst input seriously, but not as revealed truth handed down from on high.

And not to repeat ourselves, but of course you should endeavor to know your market as well as they do, if not better. Be your own analyst first.

Sales

“The sales department isn’t the whole company, but the whole company better be the sales department.”

Philip Kotler

Sales is a surprisingly unsexy topic for a lot of product people. There are, of course, volumes written already about sales, how to sell, effective persuasion, and the like, but most product management literature hardly touches on the subject. We think this is because most of that literature is focused on consumer businesses, where it’s rare for product managers below very senior levels to interact with a sales team (that might be selling advertising or some other derivative, not the product itself). In that world, it’s almost as if “shipping product” is where product management’s job ends! Naturally, those of us in enterprise software know differently. “Shipping” is only the start. Now, not only does someone have to buy it, but odds are good that the customer is going to buy from an actual carbon-based salesperson.

Remember: we’re all in sales. There are arguably only two real roles in any enterprise software business: engineering and sales (though, ultimately, even the engineers are in sales). Using an appropriately broad definition of the word “sell,” it is everyone’s job, at all levels of the company, to “sell” the product, whether they are giving product pitches or not. Be careful about hiring anyone who doesn’t embrace that. Part of what makes product management such a cool gig is that we have a foot in the worlds of both engineering and sales, and having a passion for each is an important part of conceptualizing our role.

Understanding enterprise sales is incredibly important to being an effective product manager. The reasons are pretty obvious: someone must buy what we make, or there is not much point in making it. Enterprise software sales are, have always been, and will likely always be pretty complex. Our products are sophisticated and specialized, and their value propositions are finely tuned to the specific problems people have in a given industry. It’s often a long and twisty road between a prospect’s first signal of interest to a person actually using our product. The process often looks something like this:

1. Resourcing discussions happen internally at the customer.

2. Budgets (for both software and sometimes headcount) are allocated.

3. Prospect interest is signaled. Sales calls are made.

4. More sales meetings. Demos are done. Designing and solutions happen.

5. Negotiations on price, components, architecture, and so on.

6. Contracts are signed. Everybody is happy.

7. Implementation process. This can take as little as a few weeks to, in some cases, a year or more. (Do not underestimate the implementation process in enterprise software. Rolling out a $50 million purchase to tens or even hundreds of thousands of employees can be brutal.)

8. Solution training (often simultaneous with #7).

This is a highly simplified flow, but you get the idea. Enterprise SaaS sales cycles are routinely between 6 and 12 months. This can be a big advantage in some ways, like when you want to start telegraphing capabilities to new prospects that are still two quarters away on your roadmap. In other ways it’s a drag, because longer sales cycles make it harder for prospective customers to pay you and use your product.

As an enterprise product manager, you should understand exactly how your product is sold, and what the hand-off process is like, from the first prospect a lead development representative (LDR) follows up on, to the seller who takes a qualified lead and sees it through to a sale. The people at each step of that sales process need different things from product management and can feed different kinds of valuable information back to you.

The Sales Organization

Sales organizations come in all shapes and sizes. Assuming that your company does business internationally, you will almost definitely have sales teams based in other countries that are focused on customers and prospects in that area of the world. If your company offers multiple enterprise software products or portfolios, you might also have sales representatives who specialize in one product and who will join a conversation with a prospect to help sell their product. With larger software firms, you might even have “sales reps” whose job involves very little actual “selling,” as you might define that word, but instead cultivate relationships with decision makers and locate budgets within a prospect’s organization so that they can bring in other sales reps to do the actual selling. You will get the lay of the land in your own organization as you work with sales teams on deals.

At a high level, however, we can categorize our sales colleagues into three groups which are near-universal at every enterprise software firm we have seen. Their titles may vary, but the roles are consistent.

Account executives own the relationship with the customer or prospect and are typically the ones who bear the most pressure in terms of quota (the amount of ARR that leadership has assigned them to generate). Their most important job is to manage that relationship and try to match a prospect’s business need with the solution the account executive is selling and seeing it all the way through to contract signing. Typically, their knowledge of your product will be limited to high-level value propositions and basic descriptions of various features, but they should know how to talk about the benefits you provide and how the software can solve whatever problem the customer is facing. Usually your counterparts in product marketing will take the lead on training and enabling account executives to help them know what to say about each new product release.

Note

When we say “sales rep” in this book, we are referring to account executives.

Sales engineers (often called solution consultants) partner with account executives as the more technically minded arm of any discussion with a prospect. The good ones are adept at demonstrating the best differentiating features of your product and applying those features to the customer’s requirements to find product–customer fit. They might not know the entire product as well as you do, but some of them will come mighty close. Because the solution consultants are more hands-on with your product, we find that product managers are better equipped to train and enable this role so that they are able to demonstrate and speak to the ins and outs of your product as effectively as possible.

Pre-sales/inside sales/lead development representatives are the front-line soldiers in your sales funnel. These folks do exactly what their title suggests: they develop warm and qualified leads to pass off to the seller(s) with whom they work. They are often the first point of contact for prospects replying to an email campaign, live chat, or phone call, and they spend a lot of time making cold calls. If you’ve never done that sort of work, take a moment and extend some compassion. These folks put up with a lot of rejection, but are also the source of a lot of your sales leads. They quickly learn about the tactics, campaign copy, and value messages that drum up leads.

A final key constituency to keep an eye out for here is sales operations. This can be a small team sitting somewhere, or it could effectively consist of a number of sales managers working in tandem, or it could even be just one lonely analyst squirreled away all by his lonesome. Whoever it is, in most high-functioning sales departments, particularly in larger companies, there is someone, somewhere working to consolidate and analyze sales data from across your company/group. (See the sidebar that follows on pipeline reporting.) This analysis will often include basic customer relationship management (CRM) data, including number of leads, days between touches by sales, deal qualification stage, days between each stage, deal sizes, and hopefully even deal quality. The reason you care is because this information is a peek into each customer’s disposition around your product, and invaluable intelligence about the market: did they happily pay a lot for it, or did they negotiate hard? Are they a “good” customer to have, or are they likely to walk at the slightest provocation? Knowing who is paying what and how they perceive the value for that price is inimitable and rare market intelligence to have.

Of course, there are plenty of others involved with selling your software, but most of your direct interactions related to turning a prospect into a customer will be with some form of these three roles.

How Product Managers Engage with Sales

Sales requests come in all shapes and sizes but often boil down to one of the following:

Presenting the roadmap and/or product strategy

In both a sales situation and a renewal situation, dangling the roadmap in front of buyers can be a legitimately effective way to get them excited about partnering up with your company for the next year or three. In enterprise software, prospects are often buying into the vision as much as they are into the current offering. Knowing that you are working to address their problems keeps them optimistic and gives them some air cover to go with your solution, even if it doesn’t do everything they need right now. In some companies, product management owns the roadmap and keeps it very tightly protected; in others, the roadmap is made more-or-less publicly available. In both cases, the product manager can shed light on the strategy and roadmap that nobody else can.

Answering technical questions

Sales engineers can handle many of these, but there are plenty of cases in which really hairy topics go beyond their expertise, and someone who is more plugged in to the inner workings of the software is required to speak to a requirement.

Demos

Ideally, sales engineers should be able to handle product demonstrations in any sales situation. (It is, however, up to you to ensure that the sales engineers are trained on how to do the demonstration.) It is appropriate to remind the account executive of this fact and to offer to prep the sales engineers on the deal prior to the meeting with the customer if they need a refresher. The exception to this rule is functionality that has not been released yet, and on which the sales engineers have not been trained.

Sharing best practices

Sometimes, buyers need advice from someone who has seen thousands of implementations across entire industries. They have questions about governance, security, hiring, and team structure, or implementation. In reality, product management is sometimes not the best role to speak to best practices, because product managers often go wide but not very deep with any given customer. If you have a consulting function in your company, we advise bringing them in here if possible because they tend to go deep (but usually less wide).

As you can see, some of these requests are truly best serviced by a product manager, whereas others are not. Because product management covers so many disciplines, and is so connected to nearly every other team at the company, sales reps will often start with you. Do not be afraid to redirect them if there is another role that is truly better positioned to help win a deal.

When to get involved

As we mentioned earlier, working with sales in the right manner can be a great way to help you both reach your goals. Product management, as a more technical, more strategically inclined role (i.e., not on commission and not totally focused on hitting a quarterly quota) has credibility with buyers and users that sales never will, and so engaging in a sales conversation can give the situation the push it needs to get across the finish line. As a product manager, especially after you have been around for a little while and have been part of shipping valuable product features, your presence in a sales deal—taking time out of shipping product to meet with the prospect and discuss the product as someone who has a hand in defining its future—shows the prospect how much she matters. Becoming a respected, reliable resource for your field (i.e., sales) teams can also do wonders for your career, because there is so much executive visibility on certain sales deals. On the other hand, some sales reps aren’t concerned about the other demands on your time, and will try to use you to do things that should be handled by others, including themselves. This is why you cannot (and must not!) become a sales robot, doing whatever is asked of you without discernment.

Occasionally we hear about a product manager who has responded to a request from sales to do a product overview (which any account executive should be able to handle) or to cover some other aspect of the sales process that should be textbook stuff for any sales rep by saying, “Sure, I’ll do it. Just pay me your commission when the deal closes.” We might laugh, but we can assure you that your sales rep who hears this will not find it funny (and we do not advocate actually playing that card!). Ultimately, you need to be judicious about how, when, and where you become involved with sales. We talk later about how you can gauge when to say yes.

There are essentially two kinds of engagements with your sales teams: a push interaction and a pull interaction.

We can call it a “push” interaction when you proactively reach out to a sales rep to offer your assistance in getting a prospect signed or a contract renewed. A good practice if you have pipeline data (see the sidebar that follows) is to find the most strategic (which might or might not mean the largest) deals each quarter and offer to personally sponsor them. This is great for a few reasons:

• First, it preempts any last-minute demands from the sales team. In many cases you will receive a frantic email from a sales rep who is already on site with a prospect and needs someone to walk them through the product roadmap 30 minutes later. If you step in to sponsor a deal, there is a much higher chance that you will have been in the loop from the start, which makes the entire company look much more organized.

• Second, although customer interaction is the currency of product management, prospects will teach you things that existing customers can’t. They might be using a competitor’s software currently, and offering to join demonstrations and Request for Proposal (RFP) calls can give you insight into how they evaluate your product versus the other guy’s product.

• Third, selfishly, getting involved with the most strategic deals each quarter will make you and your team look tremendous in the eyes of executive leadership.

• Fourth, and perhaps most important, it allows you to ensure that you are spending your time on the most significant deals at any given time. By being proactive, you avoid spending precious time on a $6,000 deal while a $700,000 deal goes sideways.

This can begin with a simple phone call (you can email, but in our experience many account executives seem to prefer the phone) to Sue, the account executive on a large renewal with XYZ Corp, to say that you noticed her renewal is in the pipeline for this quarter, and that you would love to get involved to help make it a slam dunk. In our experience, you will receive one of two responses: either the deal will already be so well in hand that the sales rep won’t see any reason to waste your time, or she will jump at the chance to have a product manager in the fold to help with this or that. You might still need to balance involvement in any given sales situation with everything else that you are uniquely positioned to do (market research, helping with product design, etc.), but if you’ve volunteered yourself in the first place, sales reps will understand that they cannot monopolize you.

Pull interactions, on the other hand, are when sales personnel are “pulling” you into becoming involved, and must be triaged differently. As we implied earlier, the tricky thing with pull interactions is that it can be difficult to orient yourself to the situation to ensure that your time is well spent. Here are some questions to ask first:

• Is it an existing customer who knows your product well and is preparing for renewal, or a new prospect who is considering a switch?

• How big is the potential opportunity, both now and in the future? (And is the sales rep exaggerating about the potential future account growth?)

• Is the prospect considering buying other products from your company, as well, or just your product?

• Have the account executive and sales engineer been doing their jobs, or are they looking to pass the buck?

These are all things you will need to ascertain when such a request comes in.

A common maxim in product management is that the product manager needs to be good at saying no. This usually refers to denying feature requests that are not on strategy, but we can apply it just as well to working with your field team. There are going to be times when you simply need to say no. It is true that your team will be judged, at least in part, based on sales, but this does not mean that you can let top-notch execution of research, requirements gathering, design, prototyping, iteration, development, and shipping your product suffer in order to win a deal that could be won other ways. It is appropriate to remind a sales rep that you are responsible for the success of the entire customer base, and that there might be others who can step in and help get a deal done. In these cases, have sales look to product marketing, evangelists (also known as technical marketers), and others who might be able to address the request posed by the prospect or customer.

In addition to assisting our sales colleagues with their jobs, they have much to offer us, as well, in the form of invaluable market intelligence.

Processing Feedback from Sales

As we mentioned, many leads typically begin with LDRs (recall that these folks go by many different titles). Good LDRs, like good sellers, are worth their weight in gold to your business, but typically have little product-specific feedback for product management. It’s good to be in touch with your LDR team(s) just to find out what they hear from the prospects they talk to. A lot of it will simply be noise—like the prospect once who really wanted to know if we could render the Tajik alphabet in our UI, and demanded screenshot proof. (Yeah, seriously.) But over time, you’ll hopefully develop a sense for deciphering the nuggets of insight buried among the nonsense.

The next big sales constituency to consider are those solution consultants (aka sales engineers) again. These folks are a tremendous source of customer insight. Very frequently, they will meet with a prospect’s technical, IT, or development team to talk through how your product’s architecture will work with their existing systems—think, a lot of in-the-weeds discussions about data types, models and warehouses, databases, authentication schemes, permissioning, integrations, compatibility, and so on. As mentioned earlier, they also tend to give a heck of a lot of demonstrations. Strong solution consultants become experts at connecting your product’s features to the prospect’s specific needs and pain points, and they frequently come back with pointed advice on what messaging is working and what is not. Because they tend to meet with more end users of the product than executive customers, SCs also develop a keen sense for “user problems” that product management should consider, like ways to improve your UX or workflow.

Note

It’s worth mentioning here that a lot of enterprise product managers we know considered doing sales engineering instead of product management. Sales engineering is a unique blend of product-level expertise, technical finesse, and business strategy. It also pays well. Just a thought.

Last, but perhaps most important, are the sellers themselves again. To reiterate: these men and women are the lifeblood of your business. Their work pays your salary. They take on a difficult, demanding job, a commission-based compensation structure and comparatively more risk than almost anyone else in the company, and we have to respect that. Great sellers are usually extremely sociable and likeable, but can also be a little pushy, aggressive, and very persistent, all of which makes them great sellers but which product management must take into account when evaluating their feedback.

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). That said, there are some important caveats to taking seller feedback:

• Everything is urgent to sellers. Sellers often feel like they will lose this deal or that one because the product is missing X, and if only you will commit to building X, they can wrap it up. Obviously, though, if the development cost of building X is significant, and it really appeals only to a small subset of customers, that trade-off might just not be worth it.

• When you participate in a large total addressable market (TAM), you might have hundreds or thousands of potential enterprise customers. A great seller is talking to a few dozen of those per quarter, tops. If you hear the same product wish-list items come up again and again, you might well have a pattern on your hands; or you might not. This is a judgment call, but consider whether what you’re hearing is localized to a particular geography, industry, or type of customer.

• Frequently, seller feedback about the product turns out to really be more about the messaging. It’s difficult for even great sellers to overcome crappy messaging about what a product does and the value it offers. A valuable exercise to ask your good sellers is how they would change that messaging or description of your value proposition.

• Understand seller incentives. It’s really true: salespeople are “coin-operated,” and properly so. Are your sellers incentivized to bring in bigger deals, or a high number of smaller ones? How does their commission work? Are there sales “spiffs” (i.e., immediate bonuses) or “escalators” in play? All of these will influence the kind of deals they try to land.

By the way, in many organizations, you’ll notice that certain “celebrity sellers” begin to emerge. These are reps who crush their numbers every quarter, manage to consistently bring in big deals, get “President’s Club” every year, and so forth. Particularly in growth-stage companies (somewhat less frequently in mature ones), these sellers get a lot of executive attention and their word carries great political weight. As product managers, we should get to know these sellers well. They are clearly onto something with how they communicate the product’s value and often have very insightful views into the adjacent range of business problems that our product could address. That said, be careful of over-weighting this input. Star sellers tend to be put in high-value territories, which can skew perceptions and information. Politics within your organization can also privilege their input over that of others. This is something to be conscious about.

Great enterprise product managers stay close to each of these groups. You should be talking with someone from sales almost every day. When big deals come in or quarterly results are posted, product management should be one of the first groups to know.

Pipeline Reporting

While we’re on the topic of sales, let’s talk about pipeline reporting.

Pipeline reporting (e.g., a view of how many deals your company or group has in play, at what stage, for how long, etc.) is another extremely unsexy and underhyped but incredibly useful tool for product management. In our experience, very few companies do it well, especially at large, public companies where finance departments are leery of releasing too much sales data, even internally. Used properly, pipeline data can help product management not only understand what’s being sold, how frequently, and where, but also in what sales stages prospects are deciding that the product just isn’t for them. This is obviously a matter of great importance to marketing and sales, but if prospects are responding to your messaging in the form of inbound leads but then dropping out in large numbers the more they see and investigate your product, that has product implications that product management might need to address.

In general, sales or marketing should be encouraged to own a regular pipeline reporting cadence. Weekly, biweekly, or even monthly reporting might suffice. The pipeline should be broken down into reasonably granular territories for your business and show progression between your tracked sales stages for number of deals, deal sizes, and number of days spent in each stage. Major, outlier prospective deals should be listed out. Make sure everyone in product management gets this report, and make it an item in your regular meeting.

Ways to Serve, and Influence, Sales

To sell effectively, sales needs to be armed. Of course, they need a good product to sell—or, at least, not an egregiously awful one—but they also need information in the form of content. Typically, marketing is responsible for enabling sales with the content it needs (see the sidebar earlier in this chapter about the bare minimum elements of a product sales kit), but inevitably questions come up for product management. A good example is RFPs.

RFPs are basically long questionnaires put out by prospect companies looking for vendors to fill a need that the prospect company has. RFPs can often tell you a lot about what competitors a prospect has worked with in the past and what business needs they’re most focused on addressing. Ideally, your sales team has already worked with the prospect and influenced their development of the RFP itself to be friendly toward your product; but if not, don’t panic. RFPs tend to get extremely detailed (like the aforementioned Tajik alphabet request!) and can go off on some pretty weird tangents at times. Sales often needs direct product management assistance to come up with appropriate answers.

Here’s a pro tip: grab copies of RFPs that product management is roped into filling out with sellers, anonymize it, and make the list of questions/answers available to the entire sales team. Boom! We’ve just saved you hours of tedious busywork and made your sellers’ lives a little easier. Instant ROI!

Beyond RFPs, sellers frequently need to find and access an entire constellation of collateral about your product or portfolio. Often, the way marketing deals with this is to set up some form of internal knowledge hub or content management site where everyone can browse the latest and greatest material. In our experience, the complexity and difficulty of use of these systems tend to increase exponentially with the sophistication of the product, making it a huge headache for sellers to find the stuff they need. And as any enterprise product manager knows, the seller’s motto is: “when in doubt, email the guy/gal in PM who usually has the deck I need.” You want to avoid this situation if at all possible, less because it’s annoying, and more because it doesn’t scale and leads the people who don’t know you yet to simply give up because they don’t know who has that one killer business case.

One way we’ve found to avoid this situation is to keep up a regular line of communication open with your sales team. It can be as simple as a weekly email that you send to all sellers (or cascaded through their sales managers) with usable tips about your product, competitive news (manna from heaven for sellers) or interesting and relevant market news. In every single such message, you should include a link to that online hub of marketing collateral, and clearly point them to the stuff on your product. Sellers are inundated with email, but typically very good at figuring out what’s useful (and what isn’t) for building their pipeline. If they respond to this, that’s good news.

One tactic that Blair used to employ was an end-of-week “Competitive Note” email to all sellers in his product portfolio group (a couple dozen). When there was intelligence or news on competitors to share, he included it; but more often, this was a medium for sharing “did you know?” tips on less-known features of the product, overviews of market trends, and short updates on what product management was working on. This note eventually became so popular and forwarded-on that it was widely shared around their company’s division.

If you have an annual sales kickoff event, and/or regular sales boot camps in various geographies, make it a priority to attend as many in person as you can and to present refreshed material on your product. You don’t need to go story-by-story; a quarterly breakdown of roadmap themes is usually fine, in addition to a retrospective of past milestones that you’ve achieved. Go through boot camp exercises with sellers, even if they’re not about your product specifically. The best such exercises involve building business cases, ROI justifications, and explaining the value of various products in combination, or targeted for specific industries. Some companies bring in outside experts for coaching on messaging, overcoming objections, and win/loss analysis, which can be extremely effective (ask us for recommendations!). Particularly for multiproduct software platforms or portfolios like those we’ve worked on, exercises like these give you a vitally important go-to-market perspective that is never far from a good enterprise product manager’s mind.

Summer Camp for Sales: The Vendor Conference

There is one other type of sales interaction which is worthy of mention here because it can take up a surprising amount of a product manager’s time: conferences.

In this case, we are not talking about conferences where you go as an attendee to learn about your industry and market, as described in Chapter 7. Here, we mean your company’s own conferences: events like Adobe Summit, IBM InterConnect, Oracle Open World, and Dreamforce. Enterprise software vendors market these events as opportunities for your customers and prospects to come bask in the latest and greatest industry and technology trends, to network with peers, to learn best practices, and to have a great time. (Dreamforce has had artists such as U2 and Bruno Mars perform.) They usually last anywhere from two days to a week and include main-stage product announcements, demonstrations, and guest speakers, as well as smaller breakout sessions, often led by—you guessed it—product managers.

Not all enterprise software vendors hold conferences, especially during their early years in business, but if your enterprise software company already has a critical mass of customers, there is a pretty good chance that your company does something along these lines. We named four of the biggest annual enterprise software conferences in the previous paragraph; your company might hold smaller events, such as summits or cafes or symposia open to customers and prospects locally. Or you might hold a larger annual conference that isn’t (yet!) on the same scale as those we just mentioned. Either way, if you are new to enterprise software, this aspect of generating business can sometimes be a bit overwhelming and disorienting.

Make no mistake: the purpose of these events is to generate demand for your software and close business. As a software vendor, the real value happens in two places: first, the main stage keynotes where potential buyers hear strategy and see announcements that get them fired up to do business with you; and second, in the side rooms where executives and others from both the vendor and buyer meet to talk about how to get a deal done. Each format communicates brand and solution-level values to your audience, whose curiosity is piqued as they enter breakout sessions. By the time breakout sessions begin, these participants are already prequalified for interest in sessions like “A Security Guide for Rockstars: Keeping the Bad Folks Out and More,” and “Four Myths and Four Truths About Customer Journey,” and so forth, which are mostly designed to get customers excited to buy or retain specific products by focusing on customer education.

Note

This is not to say that presenters have ulterior motives; most genuinely want to educate and inform so that customers will return from the conference with value—but remember, as we mentioned earlier in the chapter, everyone is in sales.

Sometimes, breakouts like these are aimed at existing users; other times, they are focused on specific user roles, industries, or simply top-of-mind topics in the industry.

It is worth noting that these conferences, when done right, can offer massive ROI to your company, even with large chunks of the conference budget going toward hosting technical breakout sessions and putting on concerts (which, of course, have VIP areas for prospects!). Although it is easy to be distracted by the bright lights, star speakers, and the fancy venues, these conferences can be seminal events for enterprise software vendors and their communities of customers and users. You could call them the “Black Fridays” of enterprise software, which is doubly useful as a metaphor because it emphasizes how important good execution is to make these events useful investments.

For that reason, it is worth a product manager’s time to participate. How you participate will depend on the type and size of conference. For smaller events, you might be asked to take an outsized role, such as delivering a keynote on a given topic related to your area of expertise. For larger events, you might be invited to host breakout sessions or participate on panels, lead a technical training, or demonstrate a product feature on stage. (We won’t cover how to lead a good breakout session in this book, except to say that there is no enterprise software product manager who couldn’t benefit from a public speaking course.²) All of that is well and good but falls into the category of “things you are doing at the conference while you are not helping drive your business.”

These conferences bring together large numbers of customers and prospects, and as a product manager, you should take advantage of this. You will never have a better opportunity to interface with so many customers and prospects in one place. If your sales team is on top of things, it will reach out to you to have you meet with its biggest and most impressionable accounts. You can bounce from meeting to meeting for days, helping to answer prospects’ questions and securing business for your field teams. Going into a large conference, make sure that you and your team are all clear on how you want to talk about your product strategy, your roadmap, and any hot-button topics that your customer base might raise with you. It isn’t uncommon for a single customer or prospect to meet with two different product managers working on the same products at two different times, so you will want to coordinate and make sure that you are consistent in your approach. This is a huge opportunity to help your product’s year go well in terms of bookings and retention, so make it count.

Your sales reps at these conferences will be frazzled, running around from account to account, trying to make sure that everyone is having a good time and is where they are supposed to be to hear the message that will help them see the light and want to do business with you. We call it “summer camp for sales” because they are jetting about seeing this contact or that contact, much like the excitement of a young kid returning to summer camp after a school year to see his or her old camp friends, all in one place again after having been apart for nine months. On the other hand, if a conference is make or break for your annual bookings targets, we can call these conferences life or death for some of your sales reps, who will need customers to have a positive experience and meet the right people (that’s you) to help them decide to license your software.

The most important thing to keep in mind is that any conference is about winning new business and/or expanding within the customer base you already have. When you begin to look at these events that way, you will find ways to engage with your sales team so that you can best take advantage of these opportunities. Educating your customers is a good and worthwhile part of your time at conferences, but that won’t pay for these events.

Dealing with Bad Behavior

One of the challenges that a direct sales model presents is compensation structure. As a product manager, you likely won’t have much control over how your sales reps are paid, but it is critical that you at least understand the mechanics of it. Your leadership team will have designed what they believe is a good system of incentives and restrictions to ensure good behavior on the part of sales (e.g., not allowing contracts to be front-loaded to produce higher commissions). On the whole, however, human beings are pretty good at finding loopholes in any system designed to restrict them, and sales reps can make an art form out of this subtlety. Reps find the loophole, management closes the loophole, and then reps find the new loophole that was created when the old loophole was closed. On and on, ad infinitum.

There’s nothing wrong with sales being “coin operated.” That’s literally their job. In fact, there are some situations in which this can work to your advantage. If your product is aimed at a sales persona, for example, sellers’ willingness to “hack” their way around standard operating procedures in order to do what works can be an opportunity. In the early days of Salesforce, for example, one critical adoption path was salespeople effectively using Salesforce as a shadow CRM solution to their companies’ existing incumbent vendor, which they just found painful and slow (if they had any at all!). Eventually, Salesforce was hosting CRM for lots of companies that had not yet signed official contracts, but who eventually would. In a similar way, thousands of companies are dealing with this today regarding Bring Your Own Device (BYOD) policies and employees’ use of personal email addresses to handle company files. The bottom line is that if your product is truly, demonstrably better, salespeople are a great entry point.

The reason we mention this here is that you might find yourself in a situation in which you catch a sales rep doing something that seems odd, like structuring a contract in an unconventional way. Even though you and the sales rep both want the customer, and even though you are both judged using similar metrics, the fact that you are not paid in the same way is critically important. Most sales reps don’t think beyond the current quarter, which means that you might need to be the one to do that. As a product manager, you must be concerned with both the current quarter and the long-term health of your business. A front-loaded three-year contract might help a sales rep get paid more commission up front, but it will lead to lower revenue for your product in years two and three, and make doing a larger deal at renewal time more difficult when the customer points out how inexpensive the product was in years two and three of the last contract. If this needs to become a conversation between management on the product side and on the sales side, that’s okay, but do not let sales mortgage your product’s future just to get paid today.

Hopefully we haven’t made it sound like working with sales is a chore. It can be tremendously rewarding to participate so close to where your company makes its money, to see a prospect go from skeptical to convinced, or to help secure a large renewal from a happy customer. There are some caveats, but you will find the right balance between yes and no as you learn the structure and culture of your sales organization.

Perhaps the best benefit of working with sales is learning how large enterprise deals are done. As you progress in your career in product management, this experience will prepare you to lead your business at the highest levels of your organization, making the time you spend helping sales potentially very valuable indeed.

Communicating with Sales

The language of sales is completely different than the language of development or design; quite literally, you might often feel like you are speaking a foreign language when sales begins talking about linearity, upside, cross-sell, and marketing qualified leads. When it comes down to it, your average sales rep cares about acquiring new customers, growing spend with their existing accounts, and hitting their quota. Although they approach the world different than you and your engineers do, learning how to communicate effectively with sales will help unlock one of your most valuable and rewarding partnerships and prepare you for additional leadership opportunities in your career.

Most reps don’t know how to translate “what a feature does” into “how a feature wins” (i.e., the value proposition), so help them get there. In short, you are going to need to dial back the development-speak and focus on how you expect customers to actually accrue value from your product. Remember the old marketing mantra that “people buy benefits, not features”? That might be marginally less true in enterprise software than in consumer software, but it still generally holds. When talking to sales about your product, or about your roadmap, make sure to tie everything back to how your customers are getting value from their relationship with your product. Here are some ways to do that:

Communicate using case studies and references

On that same note, a particularly effective way of communicating with sales is to speak in terms of case studies and customer references (both of which are essential to winning in enterprise software). What we mean here is to answer questions from sales by providing examples of customers who have been successful using your product. For example, if sales passes along a question from a customer who demands to know about your security protocols, answering the question directly is good. Even better, though, is answering the question and sharing the names of a few customers who are particularly demanding and have been satisfied with your solution’s security offering. If sales asks how customers do marketing attribution using your product, send them a few case studies that show how actual customers demonstrated ROI using your product to decide how marketing budgets are spent.

Recognize and have empathy with the fact that what is happening in your product next year does not matter, more or less

This sounds a bit like it flies in the face of our earlier point about prospects buying your roadmap, so let us explain. That remains true; to the prospect, the future matters. Our point here is that as far as sellers are concerned, if they cannot sell it at least as roadmap this quarter, or this year, it may as well be happening next decade. Don’t count on vague promises impressing your sales team. If you are not planning in the short-term to deliver a feature that they claim to need to win a big deal that is at the wire, hearing that it “might” happen in the next year or two will help but little.

Be clear about how your work will enable them to win against specific competitors

At the end of this chapter, we have included an example of a “battlecard,” which is a document that product marketing and product management create to summarize the tactics that sales can use to deposition a pesky competitor. Whether you have handy battlecards or not, your communication with sales should be focused on helping them win, which often means explaining exactly how a brand using your software can do things that a brand using the competitor’s software can’t do. Sometimes, you will be asked to step in and help a customer or prospect understand how your product is unique in your market; other times, sales will come to you to help them assess a competitive situation. In either case, be explicit not just about differences in product capabilities and specifications, but also in the unique benefits and value you provide. You have the benefit of getting to work with your entire customer base, so use examples from real-life interactions in which you saw a brand do something that they can do only with your product.

The language of sales is different; learn how to speak it

Ultimately, the language of sales is the language of business growth. We gave some examples of this language in this section. Learning what sales means when it talks about linearity or downsell helps you work with your counterparts there and to show them that you understand their world, but it also gives you the leadership tools that you need to put your work into context for executives, who are likely all accountable for sales metrics to one degree or another. It is one thing to say that “customers will love Feature X,” but it is another to explain that “we need Feature X because it will help combat attrition in our mid-market accounts where we are struggling to deliver cross-sell with any degree of predictability.”

Help sales get some insight into the reasons you aren’t building their requests

This might not be possible every time, but transparency about your challenges and goals go a long way toward building trust with your sales team. Suppose that a sales rep is demanding a certain feature to help close a deal. When you can, consider letting him into your world and help him see the trade-offs that he is asking you to make. He probably doesn’t realize that development and design resources are extremely limited. He probably doesn’t realize that delivering on his request would mean deprioritizing something that your entire customer base is demanding. A little transparency and allowing your sales reps to step into your shoes has helped many a sales rep to see that the product strategy and roadmap are doing exactly what they should be, even if it means a little bit of short-term pain for your sales reps. Give them the full context of your decision and it will be the foundation for trust between you and your sales team.

Listen to the sales reps, not just sales management

It is not uncommon for product management to spend a lot of time listening to (and training) sales management, perhaps as part of an internal product steering committee. This is good, given that sales managers are close to the sales reps and their customers, but they are still a step removed, so it is vital to spend time learning from actual sales reps what they are hearing from their interactions with customers. As one former product manager put it, “This is something I wish I would have done. Managers are rarely involved in the initial value proposition pitch. They almost always come in during the later phases of the sale; they’re closers. Front-line salespeople are the ones that are in the trenches hearing the objections.”

Summary

Organizational knowledge is a sprawling, highly company-specific corpus of knowledge that is critical for any successful enterprise product manager to master. This is even more the case in larger companies that contain huge amounts of institutional knowledge. We recommend focusing first and foremost on development, design, executive, marketing, and sales teams; understanding how they work, what their incentives are, and how product management most effectively interfaces with them. This is not an exhaustive list of our important counterparts, of course, but these are the most common teams that Product works with in many enterprise software companies.

PM Profile

Name: Jim Lynch

Title: Senior Product Manager, Salesforce Commerce Cloud

How did you get started in product management?

Before product management, I worked in services, first as a customer service rep, then implementation consultant, and finally a solution engineer. In all these roles, the root of the job is solving customer problems on a one-to-one basis. I started to look into product management as a way to start helping customers on a broader scale and as an opportunity to solve their problems and help them be more successful. I also took a year off for business school and wanted to find a role that would help me apply what I learned there within the software industry that I love being part of.

Are there particular backgrounds you think are especially valuable for enterprise product managers?

I’ve seen successful product managers come from almost every other area within software companies. What people learn in engineering, services, marketing, etc. can all be valuable experience for growing into a product management role, and I think teams comprised of PMs from each of these different backgrounds tend to complement each other well. In my opinion, the most common trait that is important for PMs is being a strong communicator to a varying group of different stakeholders. That is, they’re able to describe product needs at the level of detail and specificity that an engineer needs to build it correctly, while also being able to communicate to customers and prospects about the business value of some highly technical product where the benefits to them might not be inherently obvious.

What have been the most difficult parts of your job to learn?

Saying “No.” Coming from a services background, my inclination was (and remains) to always be thinking customer first, and always wanting to keep them happy. In a product role, you simply can’t say “yes” to every customer feature request that comes in—your team almost surely doesn’t have the capacity and the product that would result would become an incoherent mess. Learning how to listen to the request, dig into what the root use case or goal behind the request is, and try to identify the themes of all the requests you’re hearing has helped make this a little easier. Customers are never excited to hear “no,” but if you can explain your rationale and be open with them about the process, most are reasonable about it.

When have you felt the most fulfilled as a product manager?

The most fulfilling part of being a product manager is anytime I’m working on a feature or product that customers get excited about and can’t wait to use. Being able to collaborate with engineering to build things that have an impact on our customers’ success, and makes them happy to be working with my company and using my product, is awesome validation of all the work we do as PMs and product teams.

¹ Full disclosure: Blair is a lifelong cellist.

² For more guidance on this topic, we strongly recommend this book by engineering management leader Lara Hogan: Demystifying Public Speaking.