High Velocity Innovation with SVP of Product & GM at Cisco
EVP and CPO at Cisco
Jeetu Patel is SVP & GM at Cisco for the security and collaboration business unit. Jeetu is obsessed with speed, quality, and original thinking. Hear his experience with setting product principles, creating asymmetry in the market, and building teams that achieve high velocity innovation. Bonus: he lets slip that Cisco is hiring and gives a rundown of what his hiring team looks for in Product Managers!
“You’ve been an executive in Product for a long time at companies like EMC, Box, and now Cisco, but how did you break into Product?”
The way that I think about this is that the origination of value in a company starts from product, because it is something that you build that you’re gonna eventually give to a customer. It’s what the customer’s going to purchase, the origination of the value is on the product side. It’s so central to every part of the business.
That’s why I decided to go into product because it made a lot of sense to say what you build is actually of the most importance and the most amount of value. Because once you have actually have a great product, you can take it to market, you can have scale distribution.
It’s got the most amount of ripple effects and the most amount of leveraged investment because every single decision that you make will in fact impact not just the engineering and design teams that you’re working with, but it’ll also impact sales, and marketing, and customer success, and, billing and accounting and finance. And all those parts get impacted based on the decision that you end up making. It’s a great business to be in.
I ended up getting into product just by luck. I moved to Silicon Valley and I always was fascinated with product. When I was at EMC, we made an acquisition of a company and they asked me to run the business. It was a small company and we were all about just building a great product that people loved. That’s how I got started, and haven’t left since. I think no matter what I do I’ll be a Product Person.
“The idea of Product being at the core of everything has been around for a while, but now it’s becoming more mainstream. When did you realize that value comes from Product?”
It’s a challenge in this vocation in the sense that there’s a formal school that you go to for design, or for engineering, or for kinds of people in different parts of the business like finance or accounting, but for product it’s very vague. Every company defines product slightly differently. That’s part of the challenge, which is why companies like Product School make so much sense.
Chris Cox had given me this thing that, there’s very few product people that are great product people. Most of the time, the companies that are doing great on the product side actually build out a skill to train Product People within the company itself. Because if you don’t, then you can’t just find people from outside because every company defines it slightly differently and you have to have your core set of values in product and core set of principles.
It’s unique in the sense that there’s no playbook that can be portable across the board, but then there are also so many things that can be codified. Conversations like these really help the community at large learn from each other.
“When working in a large company like Cisco, there’s many different business units that speak slightly different languages. How did you go about like creating a common language across the board?”
The common language is showing off to people what you’ve build because companies build products and you gotta show people what you’ve built. One of the things I did when I first came to Cisco was: the one meeting that I don’t reschedule out of my week is a design review meeting. And the design review meeting is with a Product Manager, a designer, and an engineering leader.
And it’s not management, I’m not talking to VPs, I’m not talking to directors. I’m talking to the individual people that are building the product. We tell people explicitly in the meeting, leave your titles outside of the room. I don’t really care what anyone’s title is. You shouldn’t care what my title is. And we are just gonna make sure that the best idea wins and makes it in the product so that people that we are building the product for love the product so that they can talk about it to their friends and family. And when they do, that’s the most scalable marketing engine you can ever build is word of mouth.
What we did was we started with that. My boss is the CEO at Cisco and his leadership team is all the executives at Cisco, and now at every meeting at Cisco we start with a demo. Individual contributors from a 70,000 person company come in and they demo their product, to all of the executives at Cisco. It’s a great moment for them to get recognized, and it’s also a great moment for everyone at Cisco to know that we are a product-centric culture.
We are building amazing products and that’s the most important thing we can do, is build great products that people love. We started doing that first with me, then with Chuck’s staff, and now we are doing it with all hands meetings. So you have a 70,000 person all hands meeting. We start showing demos in that meeting, it’s a lot of fun.
“Let’s double click on what you said about design reviews. You have different products in your business unit, does that mean you have different design reviews as well?”
I do. I have two. One for the collaboration business unit, one for the security business unit. And so I do each design review every other week: one, one week and then the other week and we kind of alternate. And then some days we’ll actually do it every week.
But when the design team and the product team get together and they share with us the problem that they’re solving and why, how we are creating asymmetry in the market by building and designing a product that is the way that they’ve designed it. And then we actually are very critical. It’s kinda like sculpting a piece of art.
Why did we make the decisions we made? What are the things that we need to think about. Go back to the drawing board because this doesn’t seem like it’s a right for the users, it’s not simple enough. It goes from the smallest of things: What does the sign up flow look like in WebEx. To the biggest of capabilities: We’re gonna go out and create a whole new category of a product like contact center, and what should that look like? All of those pieces and everything in the middle we actually look at.
“At your scale right now you have 75,000 people. How do you as an executive keep track of all the different initiatives that are happening?”
Every week, there’s a strategic program sync where we go through every single major priority that we have. We review that on a weekly basis. That’s pretty important, to have the operational rigor in place. Because if you don’t have the operational rigor, what ends up happening is you don’t get a rhythm going.
So what’s the active user account look like, how are we doing on sales? What are we doing in different kind of bug counts? What are we doing from new releases that are coming out, are we on time on those releases? Are we doing as we thought we were gonna do in the releases that we did ship?
All those pieces are pretty important. Product Management is a very holistic kind of function where it has to interface with engineering, but also has to interface with design, with sales, with marketing, with back office systems. You need to have an entirety of a 360 degree perspective, because something as simple as, Hey, we don’t have the right enablement in a back office system, could be what kills product.
You might have the best product, and if you don’t have the right systems in place for going out and making sure that the sales person can go out and quote it properly, then you might end up not having a successful product. So it has to be a very broad view that’s looked at and you have to make sure that there’s a rhythm in place in the business.
That’s one thing that we do is just an overall operating system. The second thing that we are building out right now, and we had built this at Box really well, is: what are the core set of product principles that you want to align with? That every individual in the company understands deeply and internalizes. Because once you have those product principles, then you don’t have to centralize decision making. The decision making can be federated.
When you have a large team of people, everyone is making decisions every day. You want to make sure that they’re making them with the same set of baseline assumptions about the business that everyone is thinking from. At Box the way that we had done it was we had a set of product principles. And the important part about the product principle is not just what the product principle is, but what is the trade off that you’re making that the product principle is not?
I’ll give you an example from Box: one of the principles was build horizontal software for the masses. Multi-billion dollar companies can be built with vertical software that specialize for particular industries. That was just not what Box did. What we did was, when we said build horizontal software for the masses as the principle, we would add a line at the bottom that we would strike through, which is: versus building vertical software for specialized industries. We showed the juxtaposition and the compare so you knew that this is what you stood for, and this is what you didn’t. Even though what you didn’t stand for could have been a legitimate trade off that you made at the time.
But you’d made that trade off. So any new person coming in, if they were not aligned with those principles, then they shouldn’t join the team. Because you’re just gonna have a lot of constant debate which you’re gonna keep relitigating over and over again. That’s a pretty important dimension that we are embarking on right now as well at Cisco, because doing that at scale with…I have about 15,000 people in my org, that’s a pretty large thing to do, so we have to make sure that those principles are clearly defined.
“How do you balance maintenance of products that work today with moonshots where it’s not clear whether they’re going to work or not. But if they do, they’re going to make a huge impact.”
The way that we do it is there’s different products at different stages of maturity. And the one thing that we instill in everyone is speed is of the essence. You have to make sure that you’re moving fast. But what you can’t trade off with speed is quality. Quality is just as important if not more important. Speed and quality have to be at the core of what you end up doing. At scale, it’s pretty important that different stages of products at different stages of the life cycle are thought about differently. So for example, I fundamentally believe that you have to keep chipping away at the product and keep iterating little by little, little by little that compounds over time.
So just to give you an example, WebEx added 400 capabilities since September 2020. Between September and now we’ve added 400 capabilities, right? That is an enormous amount of engineering effort that was put into just making WebEx better and better and better and better and better.
So many things were things that you might say, oh, what are the changes you’ve made? Well, we worked really hard on reducing CPU utilization for the product. No one sees that from a naked eye perspective, but it actually massively enhances quality of video and audio. But then we also added of moonshot ideas that created new categories of products. And we did a whole lot with capabilities. If you are using WebEx in a livestream, if I did something like this [gestures with hand], it would automatically detect my body language and show that I’m doing a thumbs up.
Those kind of AI capabilities got added to the product as well. The theory is, get small two pizza teams in place that actually have a local mission that are in charge of a particular kind of area. They have to be tied to the global mission, but then you make sure that we keep iterating, keep iterating, keep iterating. And then you have to make sure at the highest level that you’re creating asymmetry in the market. Don’t go out and try to chase competition, do something that they have not done so that you create asymmetry in the market. Because as a Product Manager, one of the biggest traps you can fall into is getting so obsessed with your competitors, that all you do is do what they’ve done.
The world doesn’t need a copy cat. The world needs someone with original thinking. There’s some people that are very good, fast follow business models. Some of the companies that have been very successful have said, I’m gonna build a product that’s good enough. Why? Because I have a monopoly. And so I’m just gonna build a product that’s good enough. And I’ll be able to be fine. That’s not us. We have to build enough asymmetry. And we have to think about problems, discontinuously, rather copying what someone else had. You can’t win at someone else’s game. You have to create your own own set of rules to win.
“I love what you said about the two pizza team. Can you elaborate a little more on that please?”
Yeah. The two pizza team is not my idea. They came from Amazon, which is essentially don’t ever build teams of people that are solving a problem that cannot be fed with two pizzas. It’s basically an eight to 12 person size team at the most. And don’t try to have 50 people in a team or try to minimize the number of teams where you have that many people, because what ends up happening is when you have too many people in a team, all you’re focused on is alignment. You’re not focused on innovation.
What you need to have is few people that are just getting the work done and constantly innovating rather than constantly spending the time aligning with everyone, because alignment doesn’t create value in and of itself. Innovation does. Alignment is a necessary component, but the more you reduce the overhead on alignment, the more you can redirect that overhead into energy, into innovation. I fundamentally believe when you scale as a business, you have many, many, many small teams, but don’t start having big teams. Big teams kill companies. And so make sure that you have many, many small teams.
“You mentioned your business unit is 15,000. So how do you create those pizza teams?”
We create scrum teams based on problems that need to be solved. There is someone that is focused on media quality for video, and there is someone that’s focused on media quality for audio. Those people who are focused on media quality for audio are only focused on that. There’s someone who’s focused on AI for gesture recognition and that’s what they’re doing. You build these teams based on projects that you have, and then you’re constantly improving and iterating on that thing. You’re obsessed with not just building the product capability and sending it out, but with getting the usage high. Because once you get the usage, it does make a big difference.
“What is your philosophy around hiring PMs? Let’s start with the entry to mid level PMs.”
I have a higher order philosophy in who I hire, which is I hire people that are hungry and people that are curious above all else. I don’t really care as much if you’re technical and not technical, you have to be relatively intelligent, high integrity. Those are all important things. But what you can’t teach is hunger. You can’t teach someone hunger, they’re either hungry or they’re not hungry. And if they’re not hungry, there’s nothing you can do to make them hungry. They’re just not hungry. So find people that are hungry, they have a fire in the belly to win. And find people that are curious. They have to constantly be able to ask the question, why is it this way? And be able to challenge the status quo and not be afraid to challenge it. Those are the kind of people that do best.
So we try to hire and search for people that are hungry and curious. And then the other thing I look for is discontinuous thinkers that have a clear point of view. I don’t care if your point of view is wrong some of the time, but you have to have a process of getting to a clear point of view. And you’re a clear communicator. Because in Product Management specifically, if you don’t know how to communicate well, you’re not gonna be able to motivate the engineers. You’re not be able to work with the designers, Product Marketing, sales, or the rest of the functions in the business, most importantly the customer.
You have to make sure that you’re extremely thoughtful in your ability to communicate crisply, clearly, without a whole lot of noise. You have to be able to break it down to the core first principles and say, this is the essence of what I’m trying to solve for. If you can’t do that, then chances are that you need a little bit more coaching and development. Those things are what I look for. And in interview cycles, ask someone what they know really well in life about anything and tell them to teach you one thing that you might not know.
It’s a really good kind of question to ask. And if they can’t teach you something in an area that they know really well, that they’ve thought about deeply then you know they’re only surface level thinkers. And in product what’s important is you have to go three levels deep. You can’t just talk at the surface level, you have to go the first level and the second level and the third level. And you have to be able to make sure that you’ve gone through that thinking.
One of my other mentors told me, Jeetu, always look for people who have passion, which is the same as hunger because you can’t teach passion. Make sure that they’re intelligent, which is obvious.
Make sure they’ve got high integrity because it’s one thing if you hire a dumb person that has low integrity, it’s very dangerous to hire a smart person with low integrity. So make sure that they have high integrity and last one, make sure they can get stuff done. They have to be able to execute. They have to be able to ship. They have to be able to make sure that they can actually not just talk about something, but actually get stuff done. If you’re not thinking in, 90 day increments on things that you can deliver to the market, you’re probably not as action-oriented. So think about that as you’re going through it. Those are the things we look for.
“People have these misconceptions that they need to be a software enginee or an MBA in order to build something. If you want to build something, just go and build. There’s only so much that you can just learn by reading a book.”
I agree with you completely. By the way, I’m not a software engineer and I seem to have done okay. That doesn’t mean that I’m marginalizing software engineering skills. What I’m saying is, anything can be learned and taught because we have this amazing resource called the internet. And so you can just to learn about it on the internet. You can find the Product Podcast and you can listen to people that have actually learned it and tried it before so you can learn from their mistakes. Most people are more than happy to share their learnings with other people in different forums, so you should take advantage of that.
The thing that’s really important that you learn is how to pick the right problem to solve. As a Product Manager, the right problem is 90% of the game, because the harder the problem that you pick to solve—what I’ve found, and this is something that Sam Altman said very eloquently—the probability of success is much higher, which is very counterintuitive. Usually people would think, I’m gonna pick the easy problems because the probability of success is gonna be higher for those easy problems for succeeding. No, in fact, what happens is the harder problems have a higher probability of succeeding in the market. Why? Because the hard problems attract the best people. And when the best people get attracted to solve really hard problems, that’s when you know that you’ve actually got magic happening. The thing that you really wanna learn from people is how do you solve great problems that you wanna pick to solve?
“So Jeetu, what are you curious about learning these days and how do you make time for it?”
I think the dimension of how do you get machinery to operate at scale while still not losing the individual touch, is a constant quest to learn. You can’t have any individual feel like they’re just a cog in the wheel. Because everyone’s doing something special.
But you have to have some systems in place and you have to have some systems thinking so that all of that good work that people are doing creatively comes together to a find solution, and that gets harder and harder the more you scale. Maintaining velocity of innovation at scale is probably the thing that I’m most proud of in my career, to have been a small part of teams that have done that. In fact, if I look at the WebEx team today, I would say that these are the largest teams that I’ve been part of, but they’re operating faster than any other team I’ve ever been part of. It’s just amazing to see the level of speed compounding. And I think the ability to create a system that does that and work with people that can actually be identified so you can do that is a constant learning process.
“One of the things I love the most about product is that we get to create our future. How do you think that variables like AI and velocity are going to impact the future of Product Management for people who are just starting out as Product Managers?”
AI is a very interesting kind of domain because the model for delivering products with AI capability is slightly different. It is a non-deterministic model versus a non AI related capabilities. It’s a deterministic model. What do I mean by that? Well, let’s take a simple thing that you take the product that we are in right now, and we need to add a feature or two, which is non AI related; I need to make sure that I have a feature for doing a threaded reply.
That is a very specific problem that has to get solved. You have to have a certain amount of work and you can have a time period. And you can say in this time period, I’m gonna be able to get this done.
Now let’s think about AI. In AI, you’re training a machine learning model, and you’re saying, I’m gonna keep training it, keep training it, keep training it to see how I get on the other side. And once the result gets to be acceptable, if it ever gets to be acceptable, at that point in time, I’m gonna take that product to market.
But I’m gonna constantly keep having to make sure that there’s a model that’s keeping on learning, keeping on learning. That is a non-deterministic model for shipping product versus a very deterministic model for shipping product.
There are things which are very different in an AI-based PM model because you sometimes don’t know if what you’re building is gonna be valuable to that degree. One of the things we are doing right now is we’re building a product for people insights. And what is people insights? People insights is I would be able to tell you as either individual person, a team, or an organization based on your insights on how you’re doing.
So, for example, Carlos, you’ve actually been in 17 meetings in the past two days, but you’ve been five minutes or more late to more than 14 of those meetings. You might want to think about that a little bit. Having that insight be a valuable insight, making sure that that data is actually valuable and that we can provide that data is very important.
How do you do that? Well, that’s a very deterministic kind of model, but when you now start thinking about artificial intelligence related stuff—I’m doing gesture recognition, I’m doing noise removal. How do I take out the sound of a dog barking in the background? Well, the dog barking in the background has the model has to keep working on it and keep working on it until you’ve identified the dog and separated from human speech.
And there are different kinds of dogs. There’s some dogs who are gonna have a higher pitch and some and dogs are gonna have a lower pitch, and how do you make sure that those happen? That model doesn’t have predictability of when it’s gonna ship. You’re gonna keep training the model, and then one day, you know that that’s working and that’s when you’ve actually done it. There’s a nuance to AI based product development, which is a non-deterministic kind of cycle for Product Development rather than a deterministic cycle that you have to keep in mind as you’re going through it.
“And I just want to give some peace of mind to some of the PMs here thinking, oh my God, are robots going to replace us? No, PMs are building the machine. So I don’t think we’re going anywhere.”
In my life, it would be great if I could say, you know what? I can hire all the Product Managers that are great in the world, and I would still have room for thousands of robots with all the ideas that we have. The reality is, there’s a human judgment element to building product. And that requires instinct and judgment. Not everything is data driven in life. I want the Product Managers to understand this. Yes, you have to have some data driven pieces, but you will always have incomplete data. You have to make decisions based on incomplete data. And that’s the art component of this job, not the science component. Yes. You have to have data. Whenever you can get data, get the data to make a decision.
But chances are in life and the higher up you go, there’s gonna be more and more places where you’re not gonna have all the data. You’re gonna have incomplete data, but you have to make a call. And that’s a judgment call. What data did we have when we were talking about COVID, right?
At the beginning of COVID, how people should work—as a CEO, what data did they have? They had no data on that. They had no data on what a pandemic’s gonna look like. And by the way, frankly, if you asked us at the beginning of COVID: is everyone gonna work from home, and the stock market is gonna skyrocket? 100% of us would’ve said, there’s no way that’s gonna happen. But what happened? That’s exactly what it ended up happening. So there’s a human element to things which I don’t think gets completely taken away by machines.
AI will keep getting better and better and better, which means that humans will keep getting the opportunity to do things that require more and more judgment over time. There’s plenty of room for both to augment.
By the way, one thing that you’ll notice: the way that we are using AI is in an augmented fashion. Where there are times that you’ll use AI and then augment with human judgment. So if you call a contact center from Cisco with any of the customers, you might initially have a bot that’s just going out and asking you questions and giving you answers through AI. And then at some point in time, let me give you an example. I’m calling a bank and saying, what’s my bank balance? That’s a pretty basic question that I’m keeping on getting asked. I put in my account number, I can get my bank balance. That’s something that a bot can do. Oh, now I want to increase my credit limit on my account based on the income that I have. Can I talk to someone? At that point in time, the AI will transfer you to an agent.
Know that those are aspects that’ll continue to keep getting, fused together over time. AI and human will get more and more augmented. I don’t think we are anywhere close to Product Managers’s jobs getting obliterated because AI is gonna take care of everything. I think we are a long ways away from that. At least in my lifetime that’s not gonna happen.
“It’s been an absolute pleasure to learn from you, Jeetu. Is there anything else you would like to add?”
I’d say thank you to you for all the good work that you’re doing. Thank you to the folks that are thinking about getting into Product Management. There are a couple things I’d like to add. One is it’s extremely important that we have more women in the field of Product Management. And I think it’s extremely important for men to understand that they will build better products if they have more women. When you have a balanced team of 50-50, you will actually build better products because you will be more representative of the consumer that’s actually someone you’re building the product for.
Build in a diverse way and make sure that you’re giving opportunities across the board. Let’s not make Product Management a male dominated vocation. Let’s make this be one which is open to all different types of people that are coming in. That would be one thing I would say.
And the second thing I’d say is the reason there’s not enough women in Product Management is not because of the lack of interest from women. It’s because sometimes men don’t create an environment that’s welcoming and comfortable for women.
So if you’re a real man hire women in your team, because you need to make sure that you are better when there’s a mixed mode of building products. And I think it’s extremely important that in engineering, in Product Management, and design we have more women in the team. I’m big fan for women in tech. If there’s one message to take away, it would be let’s have more women in Product Management, because I think we’ll just build better products.
Because here’s the problem: there’s so many crappy products in the market today. We need to build great products because the world gets better when great products are built. And that gets built when you actually are a representative of the crowd for whom you’re building the products. And so we need to have a crowd, which is very diverse that represents the crowd for whom you’re building products.
Stay tuned for new episodes
By sharing your email, you agree to our Privacy Policy and Terms of Service