Fred Koopmans

Rahul Abhyankar [00:00]

Fred, welcome to Product Leaders Journey. I'm really excited to have you on the show and really appreciate you taking the time.

Fred [00:08]

Thank you, Rahul. It's a pleasure to be here. I'm excited to spend some time with you.

Rahul Abhyankar [00:13]

Chief Product Officer at Big Panda, and Big Panda is an AIOps company. So I'd love to get that perspective of the flavor of conversations that you're having with customers around AI.

Fred [00:25]

Great, happy to dive in there. Before we get to the customer conversation, let me tell you a little bit about Big Panda. What does AIOps mean? Effectively, it's using AI to streamline IT operations and incident management. At every large enterprise, there's sort of hidden somewhere a NOC, an incident management team, a support team, L1, L2, L3. That's a really hard job in today's world, with multi-cloud and microservices and CI/CD.

Engineering's throwing everything they could possibly throw at these teams and it's hard for them to do it. They need a tool, they need data, they need AI to help streamline all of that. So this was the thesis of the company, but that thesis wasn't born in November of 2022 when ChatGPT came out. This was born 10 years before, right? This was 2013, 2014. Honestly, ahead of the market.

The vision was AIOps, but the technology was not that advanced. I joined in 2021. I was like, okay, I've been in a bunch of other kinds of industries, web and video and data. Now I want to get into AI. I joined and I was like, all right, so how's the AI work? And they're like, well, we got some prototypes over here and we've got some experiments and some ideas, but mostly what customers are using today is this sort of elegant rules-based engine because there's a lot more trust in the rules that they can see and control and explain. And don't forget, these are IT people. They like to know how it all works. They don't like black box kind of magic things that they can't explain. So that's what our customers are actually using. I was like, okay, well, we might be over-marketing it a little bit or under-developing, but let's worry about that later. And then I dove in and got to work.

A year later, ChatGPT did come out and that was an iPhone moment for the whole industry. And especially for someone who had been marketing themselves and building towards a vision of AIOps, all of a sudden the technical barriers just plummeted. So very exciting. Now, what I've learned is just because you're very excited about your technology, your AI and how cool it is, doesn't necessarily mean that the customer is going to throw money at you.

One of my favorite quotes from a top five bank, my customer, long time customer—I was doing a roadmap interlock session with them. Here's my roadmap. What's your roadmap? I asked him, he explained his roadmap and he never talked about AI, talking about all kinds of other projects, but not AI. I said, "Hey, you didn't mention AI. What's your AI strategy?" And he smiles a little bit and I'm like, let me get ready.

He goes, "My AI strategy is to make sure that vendors don't double my price for no added value just because they have AI now." I was like, snap. We've reached that point already where there's some concern over hype and different kinds of things. So they're excited about AI, but it's new, just kind of like when the cloud came out. Not that there was quite a singular moment when cloud came out, but everyone was like, "Are we allowed to use cloud? Do we have a strategy, do I need to get permission for this thing?"

You have to go through a whole crossing the chasm thing. Let's go find a couple of visionaries that have enough influence in their organization to just drive something to completion. Somebody's got to go first. You got to find those people and just keep working up that hill. So we've made a ton of progress, but that's how it's gone. On the customer side, I still get a mix of, "I'd appreciate if you use the words AI a little less in this meeting." It's a skeptical IT kind of buyer and user. "We're not sure about that, why does that matter," all the way to someone that really wants to geek out: "Well, how does it work? And what's the technology and tell me more." So it's quite a spectrum. It's a tricky thing to navigate because you don't always know what kind of customer you have, but know your audience as best you can is probably good advice.

Rahul Abhyankar [04:20]

You mentioned the iPhone moment. What struck me is when I look at your career progression, it's fascinating in terms of not just the types of roles that you've held from QA all the way to Chief Product Officer, but also the types of companies that you worked in. And there is this theme that emerges to me, which is riding the right wave at the right time. When I look at Bytemobile, that's optimization for wireless networks, then video, Citrix, and then cloud platforms, data platforms, and now AI. So each of these have been significant waves of technology, and you've been at the right wave at the right time. So tell me about how you've managed to surf these waves or even identify these waves.

Fred [05:05]

Mix of luck and some intentionality, for sure. I'm a bit of an oddity in Silicon Valley this day and age because my whole career I've been in four companies. I average more than five years per company and that's unheard of. My wife is literally 4X that number. But what I really enjoy is grabbing onto a thing and then really seeing where it goes. Let's see what the next chapter is. And as long as I'm progressing and the market's progressing, we haven't stalled out, I'm not necessarily eager to jump off. I don't get bored quickly. I have a lot of stick-to-it-ness to answer questions.

I joined Bytemobile because I graduated in 2002 and the mobile internet was taking off, but the economy was also not in a great spot. There weren't a lot of job offerings, but my research group at the University of Illinois had started this company a couple of years ago and startups sound fun in California. That was about how thoughtful I was about it. And the mobile internet sounds good too. So I joined there. You said I started off in QA—there was no quality, there's no enterprise readiness. When I joined, I thought I was joining the development team. They're like, "Nope, you're going over to QA. We need to up-level and create enterprise readiness for this product." It was kind of a six-month bootcamp—health checks and load balancing and active-active and all these sorts of things. They didn't teach me about that in school, but I guess that probably matters too.

My first five years was that, and we had saturated the market. We were like, "What do we do next? We can't really sell any more of this. We have this really cool product. It delivers incredible performance gain, but still these 2G networks of the time were empty. Nobody was buying a mobile data plan in 2007 because the devices weren't good and it was still too slow." And then something magical for that particular business happened. And that was that the iPhone came out. YouTube came out. 3G came out and unlimited data plans. Within 18 months, you went from empty 2G networks to completely congested 3G networks. Our CTO had a little pocket of engineers who had been incubating on something that only a year or two earlier we were like, "What are they doing over there? What's that for? This video transcoding kind of thing." We grabbed that. We built a video optimization product. And that was this breakout moment for that company.

So we didn't see that wave coming. We responded to it. We'd been investing in some research, not knowing if that was going to pay off, but there was a thing in the right place, right time. And we just rode that wave. We went all in on it. Video optimization is the thing. I remember writing a slide—I was copying Bill Clinton, "It's the economy, stupid." I was like, "It's video. If any of your accounts ask you about some of these other random features, talk about video, because we're going all in on video and that's where the customer should be going too." So that was a great moment.

I'll fast forward a little bit. I did leave. That company was shortly thereafter acquired by Citrix. That video product helped drive that. I spent a few years there at Citrix, had gone from engineering to architect for that video product and then product management. I was running the business unit's portfolio products there for a few years. I was like, "Okay, it's time for something new." And I didn't want to hear the words mobile, video or anything like that again. Life's too short to go to the same thing. So I wanted to be super thoughtful about what is the next thing. And big data was a thing. Open source was becoming much more of a thing. I decided to go join Cloudera and I was looking to capture data, open source and cloud. I spent five years there. Very interesting and exciting. There the technology was amazing and the people were amazing.

But the business strategy and some of the product management processes were underdeveloped. There was a lot of room for improvement and driving alignment between the field and the customers. How do you listen to the customers? How do you create more forums for that? So it was five years of like a PhD in product management was really kind of what my experience was like. I don't change companies all that often. I do need to be very intentional about what's a good next company.

I literally wrote what I call a reverse job description. It was a one-pager. This is what I'm looking for. This is how I'll know it when I see it. And I told everybody, every recruiter, "Hey, here's my reverse job description. Tell me if you find one of these." Of course I tweaked it and changed it and iterated on it, but I was very intentional about it. At the time I was like, "I have to catch another wave." I don't know what else I was considering—green economy, there were a couple other candidates, but AI was the leading one. It took a while, but I found the right company and then that was it.

Rahul Abhyankar [09:45]

Fascinating. This aspect of the reverse job description—can you talk a little bit more about that? How did you structure your thinking and putting that down on paper? I would love to see it if you have a copy of that reverse job description from a few years ago.

Fred [10:00]

I do. I don't know how to share my screen right now. I'll send it to you afterwards.

It was like, "Okay, what am I looking for?" Very simple. Good company, good product, big impact. And then I had some questions around company stage. Let's start with good company. For me, what that meant was big market with tailwinds. I've had a big market with headwinds. I've had a small market with tailwinds. I was like, "Hey dummy, you need both of those things for the next job."

Something early enough that there was a lot of growth ahead of it—10x kind of growth opportunity, not for the whole company, at least sort of my line of business inside of that. And it certainly wasn't going to be another on-prem company pivoting to the cloud. Life's too short to do that again. I'm not going to get hired by the kids if I keep getting associated with on-prem companies.

And I did want—remote workforce is the thing, obviously this is mid-pandemic I was looking, but I wanted some leadership in the Bay Area. I want to be part of a team, not just an individual. I don't want to be the one person on this side of the planet. So that's good company for me.

Good product. Good product was as in product-led growth, meaning something that doesn't require enormous amount of sales and marketing. Good product means some form of societal benefit, something that can easily very directly explain to my mother, to my kids, "I'm doing this and this is what my whole company is about and it's not just making money." And then most important is it's got to fit me. I am who I am. I'm not a gamer. I'm not going to go work on gaming. I'm not going to build the best product for developers these days. It's been a long time since I've been a developer. It kind of needs to fit me and my capabilities.

And then big impact. What does that mean? Early enough that some really important decisions are still ahead of it. It's not like you've made all of those and you've kind of made your bed, now you got to lie in it. I wanted to have the opportunity to contribute and think through all of that. Multi-horizon business planning and challenging was a big thing.

One of the things I realized—I'd actually been coached on this a few years back—was even if you're not really sure where you want to be in five years, it's not okay to not have an answer to that. You got to have an answer. You've got to say, "Look, I'm gonna be an X and here's my path to get there." And like any roadmap, it's a roadmap. It's a plan. It might change, it might not be exactly that, but you're running product, you can't say, "Oh, I don't have a roadmap. I don't have a plan of where I'm going to be in five years." No, you got to have one. So what he said is, "Look, I want to be either the GM of a billion dollar business inside of a large company, or I want to be CEO of a smaller company." And that actually connects quite well with my overall path of always going upstream, getting closer and closer to the heart of the business. I'm a years on and I still think that's the right goal. Actually, I think that was a good roadmap for me. Okay. So that's the big impact.

Now here's the one thing I didn't know. Do I want to do this in a smaller size company, a medium-sized company or a large company? Because all of those are possible. You can go be a GM in training at a hyperscale public company. You could go be a CPO in training at the latest decacorn. Or I could go be the top job from a product perspective, CPO, at probably a Series C to E kind of stage company is where I was at. I needed something clever here to help the recruiters and myself remember these things. So I called them whales, sharks and piranhas.

Rahul Abhyankar [13:30]

Interesting. Can you explain that a little bit?

Fred [13:33]

Piranhas being the post-product-market-fit, Series C to E companies, the sharks being the next decacorns and the whales being the giant ones. It was like, "Okay, well, I don't know what I want. There's some things I know what I want. These are my non-negotiables, but I want to try a few things out."

And then I interviewed—I let me go interview with a few whales, a few sharks, a few piranhas, see what feels good. I got turned off as I talked to the whales, and the sharks weren't hiring at that time. They were like, "We're good." I didn't get a whole lot of opportunities there, but the piranhas is what really spiked my curiosity. I'd go meet with the CEO of a piranha for a couple of hours and I would either have absolutely no interest in that business or my mind would explode with questions and ideas and experiments and things I want to try. I would fill a couple of sheets of notebook paper with exciting things. At some point after that happened the third or the fourth time, I was like, "Okay, your body's telling you something. It's telling you the piranhas is the path to go." And then talk to everybody, every single recruiter. Once I decided I'm looking, I'm like, "Okay, I'm taking every single phone call and I'm sending them my reverse job description. I want them to work for me." And some of them would come back with, "Hey, I found a thing that sounds just like what you said." I'm like, "Great, thank you. What's that about?" That's how it worked.

Rahul Abhyankar [14:55]

When you join a company, people who are already there or people you are trying to recruit or people on your team generally ask you the question, "Why did you come to Big Panda? What made you make that decision?" What are common answers around this kind of thing? The people, the technology, or my buddy had just joined. Things like that.

Fred [15:15]

Honestly, my hack is I just pull up the reverse job description. Literally on the screen, "This is what I was looking for. Once I decided what I was looking for, it took me a while, but then I found Big Panda. Well, it turns out Big Panda was looking for exactly the same thing."

Rahul Abhyankar [15:30]

When we step back, we hear these things about companies being engineering-led, sales-led, product-led. How do you think about these labels? What do they mean? And if I'm a product manager listening to our conversation, how do I orient myself to an environment that is one of these three—engineering, sales, or product-led? Let's focus on engineering-led and sales-led. How do I still be effective in that environment?

Fred [15:55]

A lot about this. Bytemobile, if I look back, I think that was pretty engineering-led company. The founders were all engineers. It was a couple of professors and a bunch of grad students dropped out, created a company. All of the technology was born and invented and they ended up being the leaders of that company. Now the reality is, they also turned into business leaders and product managers. I think that was my transition into product management. So there was an imbalance, if you will. There was sort of weaker product management and very strong engineering. It wasn't necessarily a feature that it was led that way. I would have loved very strong product management. We would have done better things along the way.

Citrix I found was very sales-led. They had the power. Ultimately you could build whatever you wanted in product, but if you couldn't convince sales to sell it, then they were going to de-invest in your sales team. That was kind of a different experience.

Cloudera was engineering-led, almost community-led. That was the weirdest thing. A lot of my engineers actually had more affinity with their Apache community than with the company, at least when I first joined. I'm like, "Well, this is hard. How do I influence that?" So that was interesting.

And then Big Panda, I think, was sales-led prior to me joining. You would kind of tell the customer whatever they wanted to hear was a little bit more common and we need to rein that in.

So I think back about it. Here's my conclusion. If somebody says, "Hey, that company or this company is blank-led," that's code for "this company is dysfunctional" or "it's still work in progress." You're kind of saying that division has too much power. Or you're saying that division is the only one carrying the weight and everybody else is not keeping up. They're B players or C players or something like that. It's an indication of how decisions are being made in that company. I think the best-run companies would actually reject that question and every division would reject that question of "Are you engineering-led or sales-led?" They'd be like, "What are you talking about? We're aligned. We're all strong players and we're aligned. We're not CEO-led or something like that."

Having said all of that, I think those are just labels. You asked how would I advise a product manager. At the end of the day, their role is the same regardless of C-suite politics that might be going on. You got to define where we're going and get alignment across the whole company on where we're going and make sure that people bought into that. If people didn't have an opportunity to participate in that decisioning process truly—not just performative participation, real participation—they're not going to get bought in to where you're going. You're going to have divisions and silos and fractured thinking. "Well, this wasn't my idea. This was just what engineering wanted." You got to get rid of all that stuff. And that's the job. Then turn that into a strategy and a roadmap to get there and step-by-step releases. There's more work that comes downstream, but at the core of it, define where you're going, get alignment around that.

Now, if you accept that as your definition, that can happen in many departments. That could be someone in engineering whose job that is or who plays that role. In my view, they're actually the product managers. You occasionally hear this, especially on the consumer side, "What do product managers do anyways?" There's running jokes and memes about, I'm assuming consumer product managers, that they have no purpose or something like that. Time out. Whoever it is that's deciding where you're going, that's the product manager. You might have someone else who actually has that title who's doing downstream work, like creating decks and pricing and stuff, but someone's deciding where you're going. Somebody's figuring out how to take technology and convert that into a business strategy, or you're not. And you're just building technology, but you're not building a business. In other words, you have no path to revenue on that. And I've seen that pattern. Sometimes those are the companies that ridicule product managers. I'm like, "But who is deciding how you're going to make money? What market, what customer, what pain are you going after? Is that pain worthwhile? Do you have a route to market? What's your distribution channel?" All that kind of stuff.

So it's a very loaded question when someone says, "We're blank-led." It's like, okay, let's talk about dysfunction first. What team needs to be up-leveled, if any, and then you can get to more of these particulars.

Rahul Abhyankar [19:50]

So what you said is really interesting there in terms of somebody's making the decision in terms of where we are going, how we are going to get there, how those decisions are being made, who is making those decisions. And you happen to be a product manager with that title in that environment, then you have to figure out how do you earn the seat at that table, become credible with the aspects of product management that you described that you need to do very well and ensure that people see that.

Fred [20:18]

Absolutely. And like I said earlier, I glossed over this. I said, "Hey, you have to define where we're going." Well, how do you do that? Two ways. You can come up with the idea or you can find the idea and write it down. You don't have to have all the good ideas. In fact, you probably won't have all the good ideas all the time, even if you think you do. There's going to be really good ideas sitting out there in your engineering team and your customer support team, your PS, your pre-sales, your customers, your competitors. There's good ideas all over the place if you're looking for them.

So your job as the product manager is to collect those ideas, bring them all in, do some form of prioritization and turn a thousand disparate good ideas into a well-thought-through strategy and write it down. That's what I mean by define the destination—to do all that stuff. And to be perfectly candid, if I don't come up with any of the good ideas, great, let's work. And everyone else feels incredibly bought in because they saw their good ideas come into your thing. So when I'm working on a project like this, I'm actually looking for every time that somebody says something, like, "Oh, that's good." And I'll pull that word, even if it was my idea, but they had a better word than I did. I'll pull it in and I'll let them see me adopt that word. And now they are so much more bought into where you're going. And that sounds a little nefarious or something. I don't mean it that way, but your job is to collect the ideas, the words, the ideas, all that, and then put it all together and then be like, "Hey company, here's step one, step two, step three. Here's why, here's how we're going to do this." And you've rationalized it.

Rahul Abhyankar [21:50]

Yeah, no, I don't see it as nefarious or manipulative in that sense, but it's just an aspect of putting yourself in the stream, putting yourself in the flow of ideas and then catching the right things that are coming in that flow. Beautiful. So Fred, you've had significant experience as in engineering organizations—QA, engineer, engineering manager, architect—and then product management. So you have a great perspective on maybe two things. One is what is it that engineers wish product managers know? And maybe conversely, what do product managers wish that engineers know?

Fred [22:25]

Good question. What do engineers wish the product managers would know? I think I've seen this happen before where the engineers would wish that the product managers know how to demo the product. They'll see the product manager working in slides, working in Jira, working in collaborative docs, but not the product. I find if you really want to gain the respect of the engineers, use the product, learn how to demo, be the best person to go demo. That comes incredibly natural for some people and some products. That's actually incredibly hard for others with the products.

I actually had that. I did three years in at Cloudera. We were launching a new product. We just merged with Hortonworks. I did a deep 360. I took three people on my team, three executives at the company, three of my peers. "Tell me what you think." And then I had a coach that came and did this for me. One of the big pieces of feedback: "A lot of slides, not a lot of demos. Not sure if he's technical enough." And I was like, "I have a graduate degree, 4.0—what are you talking about? I'm not technical enough. Let me show you how technical I can be." But they were right. I wasn't demoing. I was always in PowerPoint. I took off that hat and I changed my stripes on that. I was like, "Okay, I need to go demo." And six months later, completely different story.

So I think that's one of the biggest things—appreciate my product, use my product. Give me feedback, but not just based on how you're marketing it. Be more tactical, be more hands-on.

The other direction, I think product managers want their engineers to have strong opinions about where this thing should go. Don't just be beholden to the product manager to spoon-feed every idea. Get curious yourself, get curious and go meet the customer. "Huh, I wonder how sales pitches this product. I wonder how they're demoing. I wonder how they run trials. I wonder how does the customer respond? I think these three features are incredible, but what does the customer think?"

That was my path to product management. This wasn't an intentional path. I just got curious and I suspected that maybe my product management, my sales team might not be positioning it as well, they weren't going to sell it as well as I could go sell what that thing was. And it turns out I was right. As I got into that room, my expertise just gravitated towards that. It started from a position of curiosity and "let me go meet the customer and figure out how to get them excited."

Of course, I fumbled over my words many times. I always remember a sales leader in a meeting once. We were selling an upgrade. It was kind of an apology for having destabilized their network for a little while at a major US operator. I was talking about how cool the technology was. I was like, "We're, you know, this is bleeding-edge technology. It's really cool. You should be excited about it." Something like that. And the customer goes, "I don't want to be on the bleeding edge. You know what happens there? You get cut. I'm going to lose my job if you ever do anything like that again." And my sales leader was like, "I love the technology, Fred, but let's keep that whole cutting-edge thing to ourselves. We'll just talk about that in all-hands. We don't have to say that out to customers." I was like, "Okay, I am maturing. I am growing. I'm learning." That's a lot more than just technology that creates this partnership with this long-term enterprise customer. They need to trust you. Trust that your upgrades are going to work. If you talk about a need that they have, you're going to follow through on it. It's a lot more than the tech, but I wouldn't have known that if I just stayed coding all day.

Rahul Abhyankar [25:40]

Those are great stories, by the way. But you talked about the relationship, the partnership that you create with customers. And a little while ago, you also talked about seeing your customer get promoted in their careers. How do you build that personal relationship with a customer to be able to understand what's going to move them forward in their career within their organization and really force that personal individual-level partnership that you talked about?

Fred [26:10]

You can't do that in Zoom calls, with an internal meeting and a different customer meeting right before and right after. You got to go get in their environment. And understand what's at stake for them. "Hey, if this goes really well, what happens?" "I'm going to get my bonus. And if it doesn't, I'm not going to get my bonus." Okay. But that matters. This is an industry where bonus is a big thing, or "I'm up for promotion," or whatever. Understanding what motivates them, what are they solving for. And then also just look, you got to do what you say. Make a commitment, say something bold. "I will fix this for you. Might not write the code myself, but I will make sure this thing gets fixed." And they're like, "Okay, I see you. I see what you're doing there. Go solve my problem." Then you got to go solve it. "Hey guys, I committed to Troy that I'm gonna fix this thing. We've got to get this done." You can rally your team around that. They all want that customer to be successful. And you earn a lot of credibility by doing that.

And "here's my number. Here's my mobile number." And then see if you can get a text message relationship. I always want to have a couple of customers I have a text message relationship with where they text me anytime. I pretend like I work for your company. If you can build that level of trusted advisor relationship, interesting things can happen. Next thing you know, they're like, "Hey, have you ever heard of this vendor? We're thinking about doing a thing." I'm like, "Well, I've never heard of them, but I know a buddy who works there. You want an intro?" Allow it to go somewhere a little more connected than just "I'm the product manager at this vendor and you're my customer," very controlled. Open it up.

Rahul Abhyankar [27:45]

Yeah, that's powerful. "Pretend like I work for your company." That's just amazing.

Fred [27:50]

And if your incentives are aligned, that is what you're doing. And if they come to you with this idea, you need to be able to say, "That's a fantastic idea. I hear this adjacent vendor does it really well. That's not in my wheelhouse though. We don't do that kind of thing. Talk to these people." So you're not trying to be all things to all people. Again, you get a lot of credibility for that.

Rahul Abhyankar [28:10]

There are situations where that relationship perhaps gets taken too far and you only end up doing what customers want you to do. I talk to a lot of product managers, product leaders who are in the situation where, "Hey, in my company, there is so much force exerted by customers that we only do what customers want us to do." What can you share in terms of how do product managers and product leaders steer this culture away from just doing what customers want us to do?

Fred [28:40]

Wow, that's a hard one. At Bytemobile, I had two to three customers that were more than half the revenue. Certainly they had more than half of the influence. Cloudera was a handful, five or 10 customers that had so much influence over the company that they held you hostage. You'd be doing a thing because you needed to drive that renewal, knowing full well that the tax was that you were going to lose a portion of the whole market from that.

One big lesson is you need diversity in your revenue. If someone says, "Hey, we can go sign up extra-large size bank and it's 10 million in revenue." Do you want that at that stage of your company? Or would that become indigestion for the company? Next thing you know, you're building something amazing that's going to turn that $10 million account into a $20 million account. You're going to miss a $500 million opportunity because you're building something very, very, very custom to that one bank or telco. I've done both of those things. So one is you got to have an alignment across your executive team about your go-to-market strategy that says, "Hey, we can always go up-market later, but you can't really go down-market. It doesn't really work. So let's be conscious of where we're at and let's go as wide as we can. Get diversity of your revenue." And then pick off one or two or three of these other ones, but at that point, hopefully they're only a couple of percent of your revenue. So that's one big thing, clearly not all in the control of product management, but give it a go.

The second thing that is more in control is, product managers are often "the deciders." We put in the feature request, "Fred said no. The heck, Fred, let me escalate to your boss and see if that person will say yes." And you get into these rainbow escalations: "Well, I'll go talk to my boss to talk to your boss," blah, blah, blah. Not a helpful scenario.

What I like to do in those scenarios is, "Hey, let's take all the good ideas out there. We could do this strategic thing. We could do these two bespoke customer requests." I'll usually try to pick a region. Let's say I've got two big feature requests from the European sales force to move their customers forward. I'll call a meeting with all of the SC directors and say, "Hey, let's talk about it. There's these ideas. What do you think we should do?" And nine times out of 10, SE director one will convince SE director two that "we're not doing that feature because it's going to hurt all of these other things." In other words, I don't have to say no. "I'd like to do this, but that guy won't let me. His customers need something different from us."

Now at the same time, every once in a while they'll come back and they're like, "Yeah, we need that. That's going to make our quarter. I need it." Okay, well now I got buy-in across a whole bunch of people. And when you can really go through a good process and figure out, "if you do this one feature, you get X million dollars in revenue"—there's worse things, right? That's good to know that you've got this sort of agreement and understanding that this feature will definitely move the business forward. That's not a bad thing to do, but you got to go through the right process and make sure that you don't get caught in this trap where you're building for a market of five or 10 customers and you're going to lose the whole other market because somebody else is coming up behind with a much more flexible, extensible product.

Rahul Abhyankar [31:30]

Interesting. Let's switch gears a little bit and come to your product organization, the team. So as a chief product officer, what are ways that you just keep a good pulse on people all the way down to the individual contributor in your org?

Fred [31:48]

I have every variety of meetings. For the rest of the org, I'm a big believer in skip-levels and I do them ideally twice a quarter. One of them is just, "Hey, what do you want to talk about? Show me your work or ask a question." It's their meeting more than my meeting. I'm hoping that they're going to come with some idea that they want to show me, a test or something they want to show me or ask me.

But the other one, once a quarter, "Hey, I want you to tell me about last quarter. What did you aim to do? What did you actually do? What kind of misses did you have? What at the end of the quarter did you miss—missed opportunities, effectively?" And I want them to do that at two elevations. One is for the business, the projects: "I was trying to close these five accounts and I closed four out of five" or something like that. The other is for their career. It's more for them than for me, but I want them to be thinking about their career. "What progress did you make in your career? Did you improve your writing? Did you go meet three customers? Did you get out of your comfort zone? And if you've got nothing in that quadrant, what are you doing next quarter to fix that?" Because you should be working on the business, but on your career as well. You need to be intentional about planning out, "I am too insular. I'm spending too much time inside this company. I'm not getting out there. I'm not in the flow of good ideas. Okay, I'm going to listen to 42 podcasts next month." Okay, that's fine. I'm not super prescriptive. I just want to make sure that they're also thinking about personal growth and that they own that. I'm not going to tell you, "Here's five podcasts to listen to and here's two customers," but I don't have time to do all of that for all of my employees. They should be doing it and I'll help them. I'll suggest if they ask, "I want to do one of these. I don't know how." Okay, good. Now I know what you're looking for. You give me the equivalent of a reverse job description. "You need a mentor. I know somebody. They'd be a perfect fit." I can help with that introduction.

So a look back to the last quarter, look ahead on the next quarter. And then one of my favorite things there—it's a three-slide, simple quarterly conversation deck. The third one is, "What was the most satisfying experience of the last quarter? And what was the most frustrating experience last quarter? And what feedback do you have for me?" I always liked this one the most because I get the most surprises. They've already talked about the more pedestrian projects: "I did this, I did that, this demo was cool and here's what I heard about it." But then they'll mention some of, "the most satisfying thing was when someone mentioned my project in the all-hands," something that comes out of the blue, and you're like, "Oh wow, I didn't realize. I should have known that was really important, but okay. Now I know what motivates this person." Equally when they mention the most frustrating thing, a lot of times that's a surprise. "Well, now I know what frustrates this person." I get inside their head. Sometimes it's nothing to do with work. Okay, so something at home is weighing on them. Good to know, I didn't know that. And of course the feedback, "What do you want me to know that maybe I don't know right now?" You hear lots of good things from there as well.

So I try to stay close with people. There's obviously big group meetings, small group meetings, off-sites and stuff, but at minimum, once a quarter—product orgs aren't that big. I can do a skip-level with everyone at least once, if not twice, a quarter. And I like to have that cadence of "How's your career going? Am I doing enough to help you on your way?" Because while I want you to stay here for a long, long, long, long time, at some point I want you to go off and make me look good. Perfectly selfishly. I want you to go be a chief product officer somewhere else and they'll look back and say, "That Big Panda organization, that was pretty good product. They turned out a lot of really great people." What more satisfying thing can you have in your career than that?

Rahul Abhyankar [35:00]

Absolutely. Excellent. So Fred, one word I've heard multiple times, and that seems to be a theme that's emerging to me across everything that you said, is the word intention or intentionality. So tell me about the intentionality that you've had, and is this something that people can learn? How do you become that high-intentionality person, if that's even a word, but I'm going to go with that.

Fred [35:25]

I forget when it was, maybe three or four years ago. I think it was during that deep 360 process that I had gone through at Cloudera. Somebody used that word for the first time. It was, "Fred is one of the most intentional people I know," in this 360. By the way, that was not a thing the company did for everybody. I decided I want that. I felt like I was kind of stuck in a rut or a slump and I'm like, "I need help. Something's going on. I got to figure this out." And even just that was sort of an expression of that. I was like, "Yeah, that's a good description of me actually." So I embraced that term.

I might even over-emphasize it every once in a while. But I think that's just part of this job—to say, "Hey, where are you going? What's the plan?" To me, writing is a big part of it. Whatever ideas are floating around your head, get them out of your head, get them on paper, go argue with yourself before you go waste anybody else's time with a half-baked argument. That's an act of intentionality.

I'll go further than that, tying to what I just said related to those skip-levels and the quarterly cadence. It's not okay, especially if you're a product manager—but kind of anyone who's an up-and-comer leader—it's not okay to not have a roadmap for your career. It can be all BS, and a lot of roadmaps are BS. "We're going to solve this problem, then cold fusion. And then after that, we're going to the moon." Okay, at least you got something, you got a structure there. But if you can't come up with that, why should I hire you to create a roadmap for my product? Why should you lead my engineering? Why should you be the person that comes over and takes over my pre-sales plan? You got to come in with a hypothesis and formulate a plan of "We're going to go here. This is my vision for how this is going to go." If you don't have vision, that's not good. Now I'm worried that you won't be able to guide your thing there. You can guide whatever function, whatever job that is.

I think it starts with picking a few ideas. Specifically, when I was transitioning from Citrix to Cloudera, I had been three years in product management and the previous 10 years in engineering roles. It wasn't obvious to me that I wanted to be in product management for the next job. I thought, "Well, hey, why don't I go look for a couple of VP of engineering jobs? Maybe that's what I want to go do." So I met with a couple of VP of engineering friends. I was like, "Hey, I want to do this. Here's my resume." And they quickly were like, "This is not a VP of engineering's resume. This is a product management strategist kind of resume. If it said VP of engineering, you would say, 'Hey, I know how to open up an office in Bangalore in six months, scale it to a team of 50, revamped this,' blah, blah, blah, blah." And I was like, "Oh God, I don't want to do that. This doesn't sound interesting at all." They're like, "Cool, then you're not a VP of engineering." I'm like, "Good to know." All right, I closed that door at that point, but I didn't know at first. I tried it on. "Let me look for a little bit of these. I have a couple of hypotheses." And then explore them in earnest and then shut them down when you're not.

In other words, you're running an experiment on your own career journey. "Do I want to be a CEO? Do I want to go to a large company? Do I want this? Do I want that? I don't know. Assume that's where your destination is, go down that path for a little while. If it feels great, keep going. If it feels horrible, turn around, go back."

Rahul Abhyankar [38:25]

Beautiful advice. Getting those thoughts down on paper and argue with yourself. I think that's really powerful. So you mentioned Crossing the Chasm. What's the latest book that you've read, or maybe even a book that shifted your perspective about something?

Fred [38:40]

Wow, lots of different books to call out. We'll stick with Geoffrey Moore here in his series. He's written eight or nine books. The last of which was called Zone to Win. And I've read it three times now, because it really spoke to me, but for different moments and different things. A lot of lessons from that. It's one of those books that speaks to you. "Yeah, I remember that meeting at Citrix. Yeah, I wish I had this book then. I remember that meeting at Cloudera," so on and so forth.

Rahul Abhyankar [39:05]

Now, what a funny coincidence, and I'll get to that. The other phrase that the book talks about is how portfolio management becomes a crisis in prioritization. And the funny coincidence you mentioned, Zone to Win—just recently I hosted an executive briefing with Michael Eckhart, who's the director of Chasm Institute and a close collaborator of Geoffrey Moore. And we talked about the zone management frameworks and how to apply them. So I agree, that's a great book and a lot of flashbacks to when you read it and say, "Well, I remember that situation in that company." Fred, thank you so much. Such a great conversation. I really appreciate a lot of wisdom and insights that you've shared across your career journey. Thank you so much for being on the show and wish you all the best.

Fred [39:50]

Pleasure, Rahul. I really enjoyed it as well. Thank you to yourself and to your audience. Really appreciate the time.