A Different Way of Doing

Blair: My name is Blair Reeves. I'm a principal product manager at SAS Software.

Suzanne: Welcome, Blair. I want to start with something that maybe you thought was long buried in your long resume of things that you've done.

Blair: Uh oh.

Suzanne: Yeah, exactly. The peace corps.

Blair: Yeah.

Suzanne: You spent some time in the peace corps.

Blair: Yeah. I was a health and water sanitation volunteer in Cameroon for two years.

Suzanne: Was that sort of a straight out of school, earnest, want to make the world a better place kind of thing, or was that a sabbatical from something else?

Blair: My eyes are full of stars, you know? No, I mean, kind of. It wasn't right out of school. I graduated from University of Virginia, and I worked in politics for a little while. Then, I decided that I didn't want to work in politics anymore and international development might be a cool career and decided that I would join the peace corps, because that way I could decide if that was a career for me or not. If it was, then peace corps would be a real boost and get some great experience there. If it wasn't, then it'd still be a good experience and I'd learn a lot, and I did.

Suzanne: Right. We talk a lot on this show about the path that people take into product management and the theme that of course emerges over and over is it’s very rarely a straight path, but the path of politics and then international development is one of the more rare examples. How did you go from that to product?

Blair: After the peace corps I actually worked in international aid for a couple of years after that too. I moved to Chapel Hill, North Carolina, and I worked for a global health contractor there for several years as a program manager for a bunch of USCID projects in South Sudan, Vietnam, and Kenya. I spent a lot of time in Sudan in those years and that was a really interesting thing too. I was still on that career path, so I decided I'd get an MBA. I was already in the triangle region, Raleigh, Durham area, and Duke is right there.

Duke has a great school, so I wound up at business school there. I planned on staying in international development up until my second year. Between my first and second year I'd done an internship at IBM in product marketing. I learned a lot there that was very new to me. I always kind of been into technology and software and stuff like that, but never professionally, so I decided that I could always go back into global development, and this will be my first real shot at switching careers, so I did. I went back to IBM and they gave me a job, and that's what started my tech career.

Suzanne: So was that a product marketing position then, or you had done that as kind of more of an intern and then came back in a different capacity?

Blair: Yeah, so I started in product marketing. I did that for a number of years before I moved into product management. I went into a company called Coremetrics that had just very recently been acquired by IBM. We were still operating somewhat autonomously for a while, and so slowly we started being absorbed more into IBM and doing more the IBM stuff. At that time, certainly Coremetrics was one of the few native SaaS, software as a service, products that IBM had. We got to see a lot of the growing pains around how a company that size adjusted to and learned from a SaaS business model, a SaaS delivery model, a selling model, and all that sort of thing. That was really interesting to me, so you know, how IBM learned to deal with enterprise SaaS was really cool. It was a great experience, but I moved over to product management after a couple of years in that, and that experience has really helped me be more successful I think.

Suzanne: How did IBM delineate the product manager role from the product marketer role? This is something that I've seen particularly in enterprise that those gray areas, right, in a smaller organization the space between marketing and product is nebulous at best, but as the organizations tend to scale up, there seems to be more specific functions for the gray spaces.

Blair: Absolutely.

Suzanne: What was a product marketer's area of responsibility there as opposed to product management?

Blair: So there's a lot of things that product marketing owns that product management can have input on and have influence over, and even collaborate on, so the thing about enterprise software is, of course, we sell all of our stuff. We have to find customers for it. Customers need to know about the product. They need to know about what the value proposition is, and then a product marketer translates those value propositions into language that a market and a customer can understand. That sounds very straightforward, and it really isn't in a lot of ways, right? You think about a lot of enterprise software has a very specialized focus. Maybe it's designed for a particular industry or a niche within an industry or a very specific use case.

Some of those users immediately understand what your proposition is, and some others don't. Product marketing is very content heavy, a lot of it. We did a lot of ... Sales kits are a good example of this. Creating material that your sellers can use. We call it seller enablement, which is kind of a wonky enterprise term, but giving your sellers ammunition to use, you know? Good sellers need information that they understand so they can communicate this message in ways that your market understands. Marketers do a lot of seller enablement. In a place like IBM, which has at that time 400,000 some odd employees-

Suzanne: Tiny.

Blair: -yeah, no, it's gigantic. You know, we'd go to Singapore, or we'd go to Europe and go to Latin America. You have a giant IBM sales force there that needs to understand about this product that they've never heard of. We were pretty small. We were a good sized company, but we were small for IBM world, the global scale. When you're trying to teach sellers about a product and really about an industry that they now need to go sell into, that was a big, big challenge for us. We were pretty successful at it ,but you know, product management has a lot of input on that, not only in terms of making sure that marketing understands what those messages are and what the product does and what it's really good at, and what we're not very good at, but product marketers can also add a lot of value in terms of market intelligence, competitive intelligence, and seller assistance as well.

Of course, it depends on the product and the market you're working in and everything. The two do work very closely together. There's occasionally some very productive overlap there, but both have to carve out roles and responsibilities that work for them and how product marketing and product management can work together very productively is a really, I think, tricky thing for a lot of larger organizations to deal with and one that smaller companies don't always necessarily have a very good appreciation for. Many of them have to learn. One of the things we try to do is help them not reinvent the wheel every time they do this.

Suzanne: Right, so what then is the product manager responsibility if the channel enablement, the sales enablement stuff that you're speaking about is a big part of the marketer's load? What is the product manager actually owning in that context?

Blair: So one thing they can do is a lot of the internal stuff, right? You have an external sales deck, right, that sellers can use. Often times, that'll be tweaked for pitching to a particular industry, like hospitality tourism versus retail versus travel versus finance versus whatever. A lot of the internal stuff can be owned by product marketing, but often product management will own things like enabling sellers internally or enabling sales engineers about things like screenshots and implementation details. What kind of industries or niches in which we're strong, right? If we know the product really well, we know what particular use cases we're targeting, what use cases we're probably a little bit weaker on, so even in a place like think about CRM, like there are a lot of different use cases for CRM in different kinds of industries, and certain products are stronger in some than others and stronger in maybe a global multi-national distributor cap company than it is in a more regional smaller kind of company.

That's one thing. Another can be just more engineering detail. Classic product management responsibility is working with engineering to decide what to build, so a product marketer, they might have ideas for what we should do as well. A product manager's job is really to translate market signals we're seeing and input we're getting from our field and translate that back into what our market really needs and what the signals are in terms of what enhancements and features to put in our product. That's a little bit outside our product marketing remit that, again, this could be an overlapping area, but it's classically more our job, because we have a larger perspective on our market than the product marketing function might have.

Suzanne: Right. You were at this company, it was absolutely acquired by IBM, you were at a company that was acquired by Salesforce. You have gone on to be where you are now, which is at SAS. All of these are huge companies. You've only ever worked in these environments as a product manager. You're less like I only want to be a product manager if the company has thousands of people. Otherwise, I'm out.

Blair: Not necessarily. So I mean, at Demandware, when I joined Demand we were about 400 people. We weren't IBM scale or anything like that. We were a pretty good sized company. We were growth stage. When I left, I want to say we were 700, so we didn't quite double the size of the company while I was there, but it was a big, big growth stage. I didn't necessarily pick them or SAS because of their size, but it's just kind of where I wound up. I do find that very well defined product management functions are concentrated on larger companies. You know, if you're a very small startup, you may not even have a product management function, and for very small companies that are still growing, product management tends to take on a much more expansive role.

Product marketing is different from a brand or a solution level marketing, but when it comes down to product marketing, the product manager is effectively responsible for creating all this content and keeping track of it and keeping it current and enabling sellers and all this other stuff. In a smaller company, you wear a lot of hats. That can be a cool challenge, and maybe I'll do it again one day. We'll see, but a bigger company has a different set of challenges. We’re at 15,000 people at SAS, and we have subsidiaries everywhere. They all need to know about our product, and it has to be localized and translated and all this other stuff. Very different kind of set of challenges.

Suzanne: Yeah. There's probably some people listening who would think 400 isn't small, but I guess-

Blair: Yeah, sure.

Suzanne: -relative to the experiences you've had ... Just briefly for the benefit of our audience, what is SAS, the company that you're at now?

Blair: So SAS Software is about 40 years old. We did almost four billion last year, 15,000 people or so. We're based in North Carolina outside of Raleigh in Cary, North Carolina. We sell analytic software, data management, and data analytics software. In a lot of ways, SAS kind of invented big data analytics back in the 70s, and sort of commercialized it. I think we've been profitable every year since 1976, and we're the largest privately held software company in the world. You know, we're in North Carolina. We sell very specialized data science tools and you know, we sell solutions beyond that as well, for example, mine, but that's kind of our sweet spot. A lot of people are less familiar with SAS, and now we're all talking about software as a service, which at SAS creates this weird ... We're selling SaaS.

Suzanne: We're SaaS. No, we're SAS.

Blair: We're SAS. We're also selling a SaaS in a SaaS form. There's a lot of that that we have learned to deal with.

Suzanne: Yeah, maybe eventually there will have to be a rebrand at some point and say, "This is getting confusing." So what is your product? What is the structure? Your title is principal product manager. Are there hundreds of principal product managers? Are there three?

Blair: Yeah.

Suzanne: Help us get inside of that a little.

Blair: Sure so my product is on the customer intelligence 360 platform. SAS has long had done things like campaign management, marketing resource management, and things like this. We've done that for 15 some odd years at this point. The CI 360 platform is SAS's first software as a service platform to deliver digital marketing resources, so we do everything from web analytics, promotion targeting, email marketing, mobile marketing, push messaging. What we're trying to get towards with our platform and the way we think we differentiate ourselves versus every other marketing cloud out there, because we don't really want to be a marketing cloud vendor, because there are a lot of those, is bringing analytic detail to digital data, and giving marketers the ability to take that data and combine it with offline customer registration data.

Any large company selling to consumers has a very large data warehouse full of behavioral data, transactional data, or CRM data in customer registration. You know, still in 2018 it's still a real challenge for a lot of those people to combine that identifiable information with behavioral data from online. A lot of the marketing clouds require that you forklift all your data into their cloud or you pull down their data but then make it very difficult to match that to data you have offline. For data scientists and data analytics users who are already using SAS, or maybe not using SAS, we're making it easier to mesh those two data sets together through a software as a service platform.

In terms of how many principals there are ... principal product manager is sort of a SAS term, but it's like a mid-senior product manager. I'm a senior product manager. There are directors above me, but then there are a whole bunch of other plain product managers below that as well.

Not for my product, but for many other products elsewhere. I don't get too hung up on the titles. I'm more interested in what my product is and what we do.

Suzanne: Titles are so characteristically enterprise. Blair: That's true.

Suzanne: There is this big theme for us on the show. We're trying to demystify what is product management and what complicates that, of course, is that what is product management changes significantly? You spoke earlier about the wearing of the different hats and what it means to be in a smaller organization. I think equally being in an enterprise organization and what it means to be a product manager is a whole other set of conversations, a whole other set of best practices. In fact, you're writing a book on exactly this.

Blair: Wrote a book.

Suzanne: You wrote it. Even better. It's called 'Building Products For The Enterprise'. How did you come to be a book author in the midst of all of this? Did O'Reilly approach you? Were you just had a burning desire to tell this story?

Blair: So my co-author, Ben Gaines, he's a group product manager at Adobe, he and I have been ... We've actually been competitors for years, so I was at Coremetrics, he was at Adobe Analytics, which used to be Omniture. They were kind of at each other's throat, but we got to know each other that way. He's a super cool guy. He's much smarter than I am, so we started talking. Then we kind of took to sending each other funny tweets or articles or whatever. You see people write about product management. The thing about the product management literature is that it's all very, very heavily focused on startups, and the consumer market.

A lot of it is very hard to square with our experiences in enterprise software, and hard to square with our experiences in the kind of companies we work in. So we always just kind of laugh about it or whatever, but then he was in New York last year, and we had dinner. We were talking about it. I said, "Ben, we should write a book about this." He said, "Yeah, of course we should write a book about this." We started writing, and we figured we'd just self-publish it, and five people ... My mom would buy it.

Suzanne: She'd buy 30 copies.

Blair: Yeah, exactly. She'd buy like five copies, but yeah. So we were doing that, and then I knew some people at O'Reilly, and I just mentioned it casually to one of them. They said, "Well, would you consider publishing? This is a good area for us." I was like, "Oh, yeah. I'd consider publishing with O'Reilly. Yeah, sure." Yeah, they took it up. It was kind of caught by surprise. By the time O'Reilly got it it was mostly done, but we really benefited from their editorial help. We cleaned up the book a lot I think. It looks a lot nicer than what we could have done, you know?

I'm really proud of it, the way it came out. We got the animal we wanted, you know? Yeah. It was a great experience.

Suzanne: So take us throughthe narrative arc of the book, because I think this ties back to exactly the stuff we've been talking about in terms of how enterprise differs for product managers. I'm cracking open my new copy, it's called 'Building Products For The Enterprise'. What are you telling me here?

Blair: Sure, so first of all, we had to make the case for why enterprise product management is different. I think there are a couple of ways in which we really define our market here. One of them is that we sell our product, right? In the consumer market, consumer software market, you do have a direct sales model in some cases. I pay for Netflix, I pay for Spotify, things like this. Those kinds of direct sale models are self service. The average sales price is very small, so $15 or whatever it is. They have gigantic user bases. Obviously they're very expensive businesses. They're consumer products, so of course you have a giant user base.

What that means is that any individual customer means squat to Spotify or Netflix or one of these other ones.

Suzanne: Even though they wouldn't say that probably.

Blair: Yeah, of course. No, I mean-

Suzanne: You'll say it.

Blair: But you know, you define your market in terms of customer segments, right? Of course, for many of the consumer products you don't pay anything at all. Think of a Google or a Facebook famously, right? You are the product when you use those things. Their customers, if you want to call them that, are advertisers. That really changes the whole way a product is designed, is planned, is built, is managed, all those things. For any product manager in that kind of scenario, and I don't mean to make it sound easy, because it's not. It involves a whole series of challenges that are different from ours. In that world, a product manager like Google or Facebook, they don't need a "customer" until you're a very very senior in that organization in terms of an advertiser or a brand or something like that, which is completely different than how we work, right?

In the enterprise, if you have a couple dozen customers in enterprise software, you have a very successful product, right? Our customers write us checks of five, six, seven digits. The sale cycle is six to 12 months long usually. You have a whole selling process, a high touch sales model traditionally. You know, it can be more and less true depending on some products. You can sell service in some cases with a basic CRM product or a basic, I don't know, web analytics product or something like that. For the most part, you have an implementation cycle at a company that's more specialized software. We have to work with a number of different stakeholders in the customer to get them using our software, trained in the software, implemented and working correctly.

There are no renewal cycles and we work on improving the software as we go on. It's a relationship that you have with that customer. You know, the breakout leaders in enterprise software, it might have tens of thousands of customers. You think of a Salesforce, again, or a W Marketing Cloud or Microsoft, Azure, something like this, they have tons and tons of customers, but for most of us, you know, you're talking about a customer bases in the dozens or hundreds is a very healthy stable of customers. So you know, a product manager in our world has to not only lead development and develop our road map, track our road map, decide what it is we're going to build, but then also we're also involved in the marketing and sales side, because you know, one thing that we stress is that sales is everyone's responsibility in our world.

Not to say we're sellers, but our company sells software, so we're all in that. That's the first part of our book, just laying out the case of why this is different. Then, you know, we break down the key lessons you need to know as an enterprise product manager into three big categories.

It was tough for us to figure out some schema to bucket all the stuff that we think you need to know as an enterprise product manager. To be clear, you know, we don't have the one true way to do product management, right? The cool thing is that this function is still growing in our industry. Our industry is changing all the time, and we're not gurus or nothing. What we saw, though, in the product management world out there is you have a lot of thought leaders, right? You have a lot of professional speakers, you have a lot of VCs, you have a lot of entrepreneurs, or whoever. A lot of people who aren't product managers.

You have these guys from Google or Facebook who managed a product 10 years ago who are still talking about being a product manager. It drives us nuts honestly, because it's just not very useful practically for us. That's what kind of made us frustrated to begin with. Since we started writing about this, since we started talking about enterprise product management, the reception we've gotten has been tremendous. People email us, tweet us, whatever and say, "Finally there's something that speaks to this ..." Maybe it's a subset, or maybe it's just a different field of product management.

There hasn't been a whole lot written and directed towards this world, and we're hoping to make some small contribution to know what that is.

Suzanne: So what are some of ... So we talk a lot about validated learning for example, right, the build, measure, learn. We talk about lean principles. It's been, I think, well documented that scaling lean is a hard concept, and that assumes that you were once small and then had the ability to maybe say, "Let's try to preserve this philosophy or way of doing as we scale up," but a company like SAS is a good example. This is a company that's been around 40 years, so what are some of the fundamental philosophies of enterprise product management or what are the ways in which they're fundamentally different from startup thinking?

Blair: So one thing that I found surprising, which a lot of people don't know, is that most enterprise ... The largest section of enterprise software market is dominated by five or six firms. The top 25 enterprise software firms, only two have been founded in the last 20, 25 years. That's Google and Salesforce. Google's like number 15 or something like that. It's not large. Salesforce, they might be in the top 10. I'm not sure. The rest of them have not been. The rest of them are like IBM, HP, Symantec, Microsoft, SAS, Adobe. I mean, these are not companies that ... We were not startups when we hit hyper growth, right? The cycle of this massive growth and all the sudden you are adding 1000% customer growth over two, three, or five years, whatever. We see that much more often on the consumer side than on the enterprise software side.

Suzanne: What does a typical growth curve look like for an enterprise company that's succeeding? Is it year on year growth? Are there flat line periods?

Blair: Sure. I think that probably all depends on the product you're talking about and the area you're talking about, right? We're talking about enterprise SaaS, like everything's changing a whole lot, right? No one was on AWS 10 years ago, and now everyone's on AWS, or you know, Azure has had an enormous growth as well. Salesforce is new, and a lot of the marketing clouds are kind of newish products, but their underlying products have been around for, gosh, more than a decade, 15 years or something like that. If you're doubling your customer base every year, you know, you're either very, very small to begin with, you're sort of a small base, or you've got dynamite on your hands or something like that, right? Like I said-

Suzanne: You're keeping customers in this space. This is about keeping the relationship integrated and upselling new products as part of the offering? What is that?

Blair: Yeah. In enterprise SaaS, of course, the whole value is in the subscription model, so the recurring revenue that you get from your stable of customers, and winning new customers is a big part of your revenue growth. Also, upselling existing customers into other features, other modules, other products, that is a huge part of your business model. I remember Coremetrics, a large portion of our revenue, maybe a majority of our revenue, came from upselling existing customers to at that time we sold more server calls or new modules on our platform that people wanted to use. As they became more sophisticated users of digital marketing tools and digital analytics, they learned that they could do more with their data.

They could actually create more value with these other modules that we built. That, of course, is why we built them, right? I think the same is true with a lot of marketing cloud products. You know, what Salesforce is doing with its sales cloud, its commerce cloud, its customer cloud, its whatever clouds they have ... No, it's very similar, right, because if you're using one, then you know, you see enormous benefit by adding new modules, adding new clouds, and some of that changes the way you work as a company. As you develop yourself as a company and your organization changes around your usage of some of these products, that itself becomes a moat that a company can take advantage of.

A good example is Adobe Analytics. They really changed the way digital marketing works across lots of different industries. They are basically the default go to for a lot of companies when it comes to their digital marketing stack, and you know, that's not to say you can't use different tools. You certainly can, but they were the preferred vendor. It became that way 10 years ago or so. Now, gosh, you go into almost any large company. There's somebody there using Adobe Analytics, so the terminology, the practices, the way marketing works has become almost synonymous in a lot of ways with Adobe marketing.

Some people are annoyed by that.

Suzanne: People who aren't Adobe probably.

Blair: Exactly. Well, so the other one's Google Analytics, right? Everyone uses Google Analytics, right, because it's free. They try to commoditize that market. It took away a large part of that market, which is why you can't really make a business just selling commodity web analytics anymore, because Google took all that. All this is just to say different companies build a moat like that. You know, even IBM, right, so people kind of chuckle at IBM now because they're an older company, they've had a very hard time growing. I think they just turned around their revenue declines last quarter, something like that. They still make a billion dollars a year on Lotus Notes, right?

I'm not sure if you ever used Lotus Notes. I did as an IBMer, and oh my God. It made you want to gouge your eyes out, you know? People still buy that, you know?

Suzanne: Yeah.

Blair: The thing is that a lot of people that don't work in enterprise software don't always understand how large that market is and how long the tail is. They still make money doing that. They still make money on mainframes.

Suzanne: One of the things I think is interesting about enterprise is there is a little bit of a polarizing effect. Either you're in that world of large companies and all of the things that that means for better and for worse, or you're defiantly and definitively not. When you're not, and I'm one of these people, you do become ignorant of just the scale at which it operates or the challenges of speed to change, right? A company of 100,000 people or 200,000 people can't just stop using Dropbox and start using Box and then go back to Dropbox if they want. That's major disruption.

Blair: Yeah. That's certainly true, and I also think the enterprise market suffers a little bit for not having ... We don't have a Google. We don't have a Facebook or one of these things that just completely took over the world overnight. Those two weren't overnight successes, but you know what I mean.

Suzanne: Yeah.

Blair: We don't have that. We also don't have the VC industrial complex that's just like banging the drum, you know? Everyday there's startups entering this market. There are lots of startups in the enterprise space, and there's a ton of cool stuff they're doing, and there's lots of opportunity there, but you know, they are going up against large entrenched competitors. I'll tell you that one kind of thesis I have is that it's actually a much better time for startups in enterprise than it is for startups in consumer, because today, in the consumer world, you have the GAFA four, Google, Apple, Facebook, Amazon. If you're not playing with them, if you don't deal with them, if you don't integrate with them in some sort of way, basically any consumer facing startup could be squashed tomorrow if any of them sneeze, right?

You have tons of examples of that right now. Half of consumer startups are hoping that they'll be bought by one of the big firms, right? The other half are living in terror that one day their business is just going to disappear. You know, Zuckerberg tweaks the news feed and all the sudden half of digital journalism is dead. We don't have that in enterprise. We have big companies, you know? IBM is big, and AWS I guess is big, but they're not going to crush your startup necessarily. Salesforce, Adobe, they're really big. You know, we have big companies, but the spectrum of needs out bear in the enterprise space, and what companies need to continue doing to innovate and to reach customers, to talk to the customers, to know what they want, and to deliver goods to them is always changing.

It's always changing way faster than there are companies coming up to meet those needs. If one of the very large enterprise software companies sneezes, you know, they probably won't kill a startup or many anyway. I think it's actually a lot more opportunity out there but again, we don't have the VC industrial complex, you know, banging a drum for it. You know, I think a lot of people go into the consumer market instead because they want to be Zuckerberg or something like that. I think that's a mistake.

Suzanne: Yeah, well, there's a sex appeal for sure. I mean, I remember recently I was at a bookshop, and there was a young tech entrepreneur on the cover of GQ, and I thought oh, we've turned a corner, you know? It used to be Brad Pitt, now it's this guy-

Blair: Some guy with bad hair.

Suzanne: -with his startup. Yeah. So one of the things that it strikes me to go back to what you were saying before about number of customers and this idea that at enterprise you're not talking about hundreds or thousands or hundreds of thousands. You're talking about 10 or a couple dozen would be in the context of requirements gathering, which leads me back to agile. What does it look like or mean to be agile in an enterprise product organization? Can you really be that, or do waterfall methods force their way in because of the slow moving nature of everything?

Blair: One thing in our book, we don't take a position about whether agile works in enterprise. There's lots of people who fight about that, right? We think it does. We both use a modified version of agile in our teams. You do need to look out. You need to have a planning process, because one thing that we don't do is move fast and break things, right? When we have a couple dozen customers who pay us hundreds of thousands a year, they get pissed-

Suzanne: If you break things.

Blair: -when they log on and something is different, right? If they know you're testing a new toolbar on them or colors, even minor cosmetic changes, people get mad, because I'm paying you for this. Don't mess with my product, right? That doesn't mean you can't test. You can have a testing tenant. You can have ask people to opt in to testing. There's lots of different ways you can do that, but you can't just test all the time like you can like Google tests a billion shades of yellow on its logo or whatever. You know, 12 month roadmap is generally the ideal timeframe for us. Again, maybe there are places where this could be different, but I think for us that really works.

12 months ahead is a good rule of thumb that we use to plan out what are the epics that we're going to plan out to get to what kind of goals we have at the end of the year. Do we need new revenue generating features or modules or products? Do we need customer acquisition or customer retention tools in terms of features, enhancements, products, or just improvements, stability? Whatever those things are. Then, within our planning timeframe, I guess it is a little bit of waterfall. You need to plan what those things are going to be.

Once we establish what those goals are and we establish who is accountable in what ways in the timeframe, then we can focus on questions like what and how are we doing as opposed to why are we doing this? Why don't we do this other thing? And so forth, which are interminable kind of questions. So whether that's waterfall, whether it's agile, I don't care. I mean, it works really well across a lot of different organizations where we have very specific business goals for what our products need to do. Again, in a direct sales kind of model.

You know, that doesn't mean we can't be agile, right? The reality is if one of our largest customers comes and knocks on our door tomorrow and they need something and they're paying us a million dollars a year, we're pretty likely to go do it, you know? Every enterprise product manager has the experience of some important honcho getting on a phone and calling us and saying, "I need this done like now." That messes up your planning. It introduces technical debt. It messes up the planning process. You have to push things out to another sprint or another quarter or whatever. That all sucks, but at the end of the day, you keep a customer and you keep them happy.

Keeping happy customers is something I'll do seven days a week and take the technical debt and worry about that another time.

Suzanne: You know, listening to you speak I'm trying to think about ... How do you pitch the sex appeal of enterprise, right? Part of what's coming up in my mind is it sounds like there is stability in a way that isn't always afforded in that kind of move fast and break things model. By stability, what I mean is time to think, like time to actually take a minute and think, time to actually go and collect inputs with breadth and with depth, which think for me certainly as a product person, and I do a lot of consulting with organizations that are trying specifically to get from an A to a B, and one of the things I'm wrestling with regularly is how deep can I go with this?

It's almost never as deep as I would like to. It's a lot of this will have to be good enough for now, which is hard, right, because sometimes you want to be deep in it. I don't know. What is the sex appeal of enterprise product management?

Blair: So I will say every product manager, whether you're in consumer enterprise, whatever, is always thinking well, that's going to be good enough. I got a billion other things to do. How do you pitch the sex appeal? I mean, this is one of those things. Now, especially working in tech, product is super hot, right? I think part of it is people like the idea of being a manager, right? They like the title.

Suzanne: Wait until they find out there's no managing.

Blair: Yeah, I know. I can't control anybody. Ask my daughter. You know, I think it's a very exciting role, because you do wear a lot of hats. You have a lot of different areas of responsibility. It's not great in that you don't have a whole lot of authority. My engineers don't report to me. They report up to the engineering function. Marketing doesn't report to me. Sales doesn't report to me. The other product managers don't report to me, you know? We all work collaboratively. The metaphor we use in our book is product management is like a sheep dog, because we are trying to get everybody turning in the same direction. If you get everybody turning in the same direction, the product management can lead by influence and by example and by a very clear vision of the product and strategy for how to get there.

That's where we have to first develop and then articulate to the rest of the team so that development knows not only what we need to build but also why and the strategic framework that this fits into. Once they understand that, then they're going to build a much better product. Marketing needs to know what our product does and why do customers care? Then, okay, once they get that now I can make that into marketing, which they're better at than we are as I talked about before. Sales needs to understand what the heck the product does and how do I communicate this to a customer so they can do the selling, which is what they're good at. Every team is like that. Product is really what they rely on to define that vision and what that strategy is and then also define how do I go do my job best?

It can be cool. Sometimes it's not cool, you know? What I-

Suzanne: When's it not cool?

Blair: Well what I like to say is the best job you'll ever have you will only love about 70% of the time, right? There's always going to be, you know, 30% of the time you're just going to bang your head on a wall, right? Especially when you're dealing with any business where you have customers. Sometimes you get frustrating parts, right? Sometimes customers don't do what you want them to do.

Suzanne: Really?

Blair: Yeah.

Suzanne: Huh.

Blair: You know, there's either expectations or they want to play hardball and they want to be a jerk about it. It's not all roses. Sometimes it's stressful and it sucks. Sometimes a product doesn't do as well as you think it should. I actually think that a really good experience for any product manager to have ...

I feel bad for anyone who started off as a product manager for Google, because what do you do, right? You're Google, or Gmail or something like that. It must be a cool job, don't get me wrong, but if you're the market leader and no one's even close, what do you do? I mean, a great training to be a great product manager is to work on a middle of the pack product and just scrap it, right? I mean, if you have actual competitors and it's a day by day, deal by deal slow ramp sort of thing and hopefully at the end of that you're a better product and you're a better company and you win. Sometimes you lose, and then you learn from that too.

Suzanne: Right. Blair, is there a favorite chapter, section, nugget in the book that you're especially proud of or just think for anyone who's going to pick up a copy real soon...

Blair: I mean, I think the whole book is good.

Suzanne: Good answer.

Blair: I think that the chapter on organizational knowledge is really important, because it distills how a lot of enterprise software companies work. We have a section on development, marketing, sales, design, and leadership. Those are five big stakeholders in any of these companies that product management has to work with really, really closely, and we have some ideas about how you can do that most effectively. The other thing I like, actually, is we surveyed a bunch of our friends at different enterprise software companies, and at the end of every chapter we have a little profile from people who we know, other product managers. You know, so we have a buddy of mine from Asana, a buddy of mine from IBM, Dynamic Action. I didn't agree with everything they said. They probably didn't agree with everything I said, right? We're all kind of in the same world. We all kind of recognize where each other are coming from, so getting all those different perspectives you try to put them in the book anyway, because like we said, we're not gurus. There are different ways you can do product management and certainly in enterprise software. This is just like our take and some stuff that's worked for us. We're continuing to learn new stuff. This is our best shot for now, and maybe in five years we'll do another edition and it'll be totally different. I don't know.

Suzanne: All right, so what's the core value proposition of the book? What am I going to get out of it?

Blair: If you are in enterprise software now or you're just interested in product management generally or you're looking to get into the role, I think this book will help you understand the role better. It'll make you a more effective product manager, and if you're not interested in enterprise software, at least understand a different perspective of what product management does and hopefully make you a better one. One of the things I keep telling people is product manager should never be your first job in technology. I think this book is a good example why. There's a lot more stuff you need to know before you jump into a role like that.

Suzanne: Okay. Awesome. We're almost out of time, but I just have a couple last questions I want to fly through with you here. One piece of practical advice that you would give to somebody who's looking to get into product management.

Blair: I would spend a year or two or more in a different role, an adjacent role. That can be engineering. It could be marketing. It could be sales. It can be sales engineering. It can be whatever in the industry just so you understand the market that you're selling into. The most important thing as an enterprise product manager to know is understand the industry that you're selling into and the market for products like yours. Without that knowledge, you're just kind of flying blind, so getting the kind of view already into the industry is super important.

Suzanne: Great. What about hard lessons learned, or maybe to put it a different way, common pitfalls to watch out for, especially when you're just kind of getting started?

Blair: Not reading the documentation is a big one, you know? Documentation sucks. No one wants to read it, right, but 90% of the questions that anybody has are in the documentation. You don't have to remember the whole thing, but understanding how a product works, and you don't need to be a Jedi master at a product to manage it. You do need to understand how it works, and you need to understand how to use it. You should use it. You don't need to understand the code base or whatever. That's unnecessary, but basic system architecture is pretty important, because you don't understand those things, then you get down the line long enough that you're passed the point where you should know it and then you're in this really weird position where you have to start asking people about very basic questions about your product.

Suzanne: Read the documentation. The documentation in parenthesis sounds very ominous though when you say it. All right. Why do you love this job so much?

Blair: It allows me to have a pretty wide amount of influence of the future of a product that really matters. I mean, a lot of companies use both my product now and products that I've worked on in the past. Those products touched lots of lives. You know, it's not one of those making the world a better place kind of thing, but it kind of does. It makes the gears of the economy and the world run. The whole world runs on enterprise software even if you don't realize it or not. No, it's not like Google, but everything runs on something, and there's a product manager behind every piece of software you've touched or anything you ever bought. That's a big part of our world.

Suzanne: Cool. Do you have any recommended resources besides yours and Ben's book, which by the way, folks, is called 'Building Products For The Enterprise'. We'll put it in the show notes and maybe I'll talk to Blair about getting us some copies we can give out to your audience as well, but besides 'Building Products For The Enterprise', recommended reads, pundits that you like that are speaking to your world more so than the others?

Blair: There are some of the obvious ones, like 'Crossing the Chasm' is a big one. All Clay Christensen’s stuff, that sort of thing. I think that some people will recommend the building habit for me products and lean analytics and lean product books. I think that understanding the psychology behind not just how people use products, but then just how people act is important not only to build products that people can use, but then also 90% of product management is dealing with people and influencing them, understanding what they're saying and communicating.

I mean, being a very effective written communicator, spoken communicator, and maybe listener, you know, is very important. For that, fiction really helps me. I'm reading 'Anna Karenina' right now, and does it make me a better product manager? Yeah. I think it probably does. I probably couldn't articulate how, but I think fiction gets a bad rap sometimes, but good fiction helps you learn to empathize better and empathy is fundamentally one of the key skills I think a product manager should have, so developing empathy is important, so read fiction.

Suzanne: Cool. I'll give you a fun fact about 'Anna Karenina' in the context of product. Leo Tolstoy wrote 60 pages of that book before he realized what it was actually about, burned the 60 pages.

Blair: What?

Suzanne: I don't know if he actually burned them or not, and started the book on page one, which I think I tell this story a lot in my classes, because I think it's a great testament to don't let investment or over-investment in one direction be too much of a weight, right? If you've got to pivot, you've got to pivot.

Blair: Yeah.

Suzanne: Sometimes you hope to pivot sooner. I mean, you wrote a book. I'm sure you would have liked to know that you were on the wrong path before 60 pages.

Blair: Oh man.

Suzanne: All right. Last question for you, Blair. Is there a personal or professional mantra or philosophy that you use to kind of guide who you are in the world that you want to leave us with?

Blair: Yeah, ask for forgiveness, not permission.

Suzanne: Awesome. Thank you so much, Blair Reeves, for being a part of our project, and best of luck to you with everything that you do.

Blair: Awesome. Thank you so much for doing this.