A little while back, we made gentle fun of Google’s hamburger menu. Well, Google responded! This week Paul and Rich sit down with Google’s Senior Director of Product Management, Ben Wilson, to discuss the hamburger menu and so much more. We chat about the importance of good research and why it’s vital to promote diversity in your teams. Also, Ben shares what it’s like designing product at such a large scale — think trillions of API calls a day.
Ben Wilson And when I go look at the diversity in humans, because they have different backgrounds and different experiences, oftentimes I find that diversity in thought comes from those same humans. [music ramps up, plays alone for 15 seconds, fades out]
Paul Ford Hey Rich!
Rich Ziade Hey Paul, good morning.
PF What a surprise to see you back here again.
RZ Or good afternoon, depending on who’s listening.
PF Really, I mean, it’s asynchronous in every possible way. So not too long ago, we recorded a podcast in which I made gentle mocking, loving fun of Google Cloud Platform. And it’s remarkable hamburger menu on the on the top left. Because imagine a hamburger that had on top lettuce, tomato, onion, but also mustard, mayonnaise, five kinds of mayonnaise, mayonnaise that can run in the cloud with no problem, mayonnaise that’s like a full Linux machine, DNS, all on top of one hamburger. That was kind of how we characterize Google Cloud Platform. And you know who reached out?
PF Google Cloud Platform. [Rich laughs] And they said, it was kind of like—
RZ Uh oh!
PF It was a good one. No, ’cause it was like, ”Alright, dude, those are some good burns.” That was kind of the essence of the message, right? And so we had a great conversation, because you say that to me, if somebody comes to me is like, ”I appreciated the way you made fun of my product.” I’m like, ”I would like to talk to you.” And so we had a great conversation with Ben Wilson, who runs product for Google Cloud Platform, we should talk about what that is, and asked him to come on the podcast, because when do we get to talk to product managers at this level of abstraction and altitude?
RZ I mean, at ground level, it’s hard to talk to product managers about product, because product management is product management. But at this level, it’s a whole other game. Right? So welcome, Ben, to the Postlight Podcast, it’s great to have you.
BW Thank you very much. I appreciate being here. And I of course, appreciate all the good burns, those are the most fun of the day. [Paul chuckles] And we also have those great conversations about what’s on the hamburger also.
RZ Ben, I want to get your title right. I have, I’m looking at LinkedIn right now. So you are Chief Technology Officer dash Energy at Google, as well as a Distinguished Engineer at Google. So explain your role. I think that’s a good place to start here.
BW Like every good Google employee, that’s an old role that I had two years ago. [Ben laughs] So when I started—
RZ Ah! So this is no longer your role?
BW Yeah. So when I started with Google, I started in the office of CTO, and one of the roles I had was working in the energy spectrum. And so I was working with energy companies. Today, my role is I’m a Senior Director of Product Management working for Google, running a whole bunch of products on Google Cloud, specifically, I’m running a lot that are kind of more internally facing now, although I do have a whole set that’s externally facing. But it’s a lot of fun and an ability to go and do scale like I’ve never been able to scale in my entire life.
PF You know, what I’d love for I think that the listeners and me too, right? Like, when we talk about product, we’re often talking about maybe an API or two, a mobile app that you can use to access and do things with those API’s. When you’re talking about product, at this level of abstraction, these are the products that people use to build the platforms and products. So give me some example of you know, you have this portfolio, what would be in your portfolio, what kind of things?
BW So one of the products that we brought out a while ago was called Active Assist. So if you go think about Active Assist, it basically is out there trying to help customers use our products better save money, be more secure, and so forth. We have something called like IM role recommender. And when you think about those, those are very diverse product sets that we have out there, whether it be BigQuery, or IM or Compute. And you don’t want to go rebuild that kind of same functionality to be able to make a recommendation, you want to have a platform that builds on. And so that’s the thing that I’ve helped go build is that kind of platform that each one of these product teams can use to be able to go make recommendations, surface it to customers, and then eventually surface it to kind of the field salespeople who are working with those customers, they can say, ”Hey, listen, we’ve made a recommendation to our customers, they have an opportunity to save all sorts of money in compute. We told your customer that wouldn’t be great to tell that FSRs and the TAMs that are out there also.”
PF I’m not even going to try to unpack all these acronyms, it’s actually really, like, like, there is a lot going on your world, right? Help me understand who the customer is, because that to me would be where I would immediately freak out in your role, because I would think my customer would be Con Ed, and my customer would be a woman named Susie.
BW Oftentimes, the way we think about our customers, especially—lets use Active Assist as an example is oftentimes we think about them as the developer, or the infrastructure engineer that’s operating out there. So for Active Assist, and we think about them in terms of that kind of user persona, that user persona is the thing we use to be able to identify where the features and functions, were always trying to figure out to kind of increase that usage, but more importantly fulfil that need that customer has. So one of the things we spend a lot of time on is CUJs. And one of the unusual things—
PF Wait, what are CUJs? Well, wait, let’s take a guess. CUJ—what do you—I think customer user journey, that’s my guess.
BW It’s actually critical user journey. But yeah. [Ben laughs]
PF Ahhhh! So close! So this is why I run a software service, because I’ve never had any idea but I can usually—context clues. Okay, so CUJs…
BW Yeah, I mean, the critical user journeys are one of these things we use to be able to really understand what’s happening. And what’s a little bit different inside Google is we like a lot of research, our research teams actually exist inside of our UX teams, and being able to have true researchers who actually understand how to go and pull the information out of users to understand what their true needs are, is really an art and really a talent. And as a product manager, you’re like, ”Oh, I can figure that out! I can just go talk to a customer, I can have a user group, and I’ll figure out what it is.” And I used to believe I could go do those things. And when I came to Google, and I went through our UX team, and went through the research, and having people who really understand this, they are an asset, like no other asset I’ve seen. And I think that being able to couple those two things together is one of the things that really drives a capability and being able to understand what the value is.
PF Let’s give the Google PR person listening to this really good day, I’m gonna ask you the greatest leading question that anyone has ever heard. What makes Google research so good?
BW I’m not sure I know the answer that. I think that if you go look at the way they interview these people, and that the ringer they put through, it’s it’s got to be really tough. And I think some of it too, is they’re allowed to focus. And I think that’s one of the things I find in product is it’s easy to get like defocused on too many things. Because as a product manager, we always say, oh, you’re kind of like CEO of the product. So you always have so many things going on. So it’s easy to get diffused, these people can stay focused on that particular item. And they have a passion for it too. I mean, some of these researchers work that Gartner or some of these other places where they really did hardcore research, and were able to pull out what those features and functions are that people wanted. And that really drives a differentiated experience and provides me insights we didn’t have before. As an example, one of the things we say in Google all the time is, you know, we ship API’s first, never UX. And when we originally started using our building the Active Assist we we envisioned it as kind of purely an API solution. Our researchers were like, ”Yeah, you’re wrong.” And we’re like, ”No, we’re not, we’re not wrong. We’re right!” They’re kike, ”No, no, you’re wrong.” So they went and did some research, came back. And the research was absolutely overwhelming. They did a pairwise comparison research that allowed you to kind of like rank all your all the features and capabilities you wanted through kind of a pairwise comparison. And what came out of top is the ability to visualize and see it. And then like, once we built it initially, and we released it to a small set of customers in those customers, you could literally see the hockey stick of usage. And it’s these types of insights that you know, as product managers and engineers that we don’t normally get.
PF Their major skill is to tell you, you are wrong.
BW Correct. That is 100% correct. And the people that I’ve worked with in this space would say that that’s true, too. It’s absolutely true. And that’s what’s great, right is that brings in that kind of different thinking that you need to really be good at product.
RZ I’m hearing two challenges for you that aren’t typical for a product leader. One is your users are also inside your company. And also the best of the best are inside your company. So you’re trying to drive product forward but you’ve got a population within your organization. It’s like me creating an app for real estate brokers. Meanwhile, I run a real estate brokerage firm, like and they’re all inside, and they’re going to have strong voices. And frankly, their voices should be heard because they’re at Google, and they’re probably really great at what they do.
PF No, but you know, we’ve we’ve talked to lots of ex-Google folks in our time at Postlight, right? And it is a powerful mental adjustment for them to leave that organization and realize how the rest of the world does engineering, which to them is like cave people with you know, hitting sticks with with bones, okay. [Ben and Rich laugh]
RZ I don’t think it’s that bad—
PF No, but here’s the problem. The cave people hitting sticks with bones have access to like a trillion dollars in IT spend. So the Google engineers are like, they’re over there in a cave grunting and now you have this cloud platform that literally is like, you know, a lot of the world runs on SAP, right? Like, I don’t think Google would build its own SAP. That’s not Google’s thing. But if you’re going to have a cloud platform that’s truly viable, you’re going to support SAP, there’s no way around it. So that is to me like that is the great like, I don’t you’re not gonna resolve that on this podcast. That’s like the great eternal conflict of being in an engineering work and then needing to support the world of IT.
RZ Do you find that’s a challenge to sort of reconcile sort of what you’re learning about the world and what’s going to resonate with people and the strong sort of cultural position that sits that, you know, that lies within Google that has delivered unprecedented success on every level? Do you find that’s a challenge in terms of navigating that within Google?
BW Here’s, here’s what I say is, I think that the question is perfect, because that is exactly the position we find ourselves in is, we have customers who are using our product, it’s a publicly facing product. But really, it’s Google engineers are building on top of our platform. When you look at me as a product manager, where I really excelled most is building platforms that engineers use. And where I excel best is when those engineers use that product in a way that that’s expressed externally to customers. And when you’re in that situation, you always have to remember that you’re in service. It’s servitude, and like that servitude, and service always sounds bad. It’s like you always want to be the person like, ”Oh, hey, look at me, I’m the product manager and like, look at this great thing I built and look how awesome, it’s great to be in the videos and you know, be on stage and stuff.” That’s great. That’s one thing. But there’s a whole thing around building platforms. And if you’re building platforms, you have to have this mindset of my job is to go serve those people so they can be successful. And what you have to take take away from that is when you see that success, you kind of get that those goosebumps is like man, I can’t believe they use my product to do that. And then as more and more products get added to it, you start looking at, wow, there’s look at how many 28 day active developers are on it, looking at how many API transactions we’re having a day, 2 trillion API transactions a day. I mean, these are things you have to get excited about. If you can’t get excited about servitude, you can’t get excited about more and more people using a platform that expresses itself externally. Building internal platforms is probably not the right place for you.
PF This is like music to us, right? Like I don’t know about you, Rich. This is like literally, I’m just like, ”Yeah, yeah, keep talking.” Because first of all, we’re client service firm, right? So so that’s just part of our ethos. But that moment, when you see people getting empowered, and they don’t care who empowered them, they’re just like, ”I have a new power. Look at that, I found a tool on the street.” They don’t care that you left the hammer there, they just somebody left a hammer, and now they can drive nails, and they’re really excited. They’re never gonna know you had anything to do with it. But you will. And if that does feel awesome to you, then the the platform stuff is wonderful, right? Because your job is to make yourself as invisible as possible. So that people just feel it’s just natural to, to pick one of these up. What is Active Assist? We should talk about that so that people know,
BW It’s just a recommendations tool. You know, it’s a capability that allows our users to understand how to be able to use Google Cloud better. We just introduced it in the last like six months, it was in our Next conference in July. It’s a fantastic, it’s a great product. I think that at the end of the day, what we’re really trying to do is find a way to make it easier to use Google Cloud. And eventually like can it be something like a self driving cloud, instead of us just making recommendations can be actively do these things for you. And so as you think about these types of recommendations, the idea here is like, how do we go make them even even more useful to our customers? The explanation I always use is the the duplex video that Sundar had it about two years ago at I/O, where he had the assistant go make a haircut appointment for him, and also make a reservation at a restaurant. If you go back and you look at that video, right, you watch it. There’s nobody in the world who asked for that. I mean, nobody in the world asked for the assistant to go do that. Right. And so part of the way Google thinks about things is how do we be helpful? How can we be helpful to our users? And you go look at that idea, right? And those are similar ideas that we’re trying to try to bring forward, not only like listening to our customers, but also be like, ”Well, hey, if we do a few extra things, does that really help them more?” And that’s kind of what Active Assist is trying to go out and be.
PF When we talk about scale, let’s quantify it like, how often is an API getting hit? Like how do you think about scale? When we’re talking about, you know, transactions or number of users? What are the parameters that are in your mind?
BW So I think first, let’s define what scale is first, right? I think there’s different kind of, if you will, dimensions of scale. One is transactional scale. One is user scale. Another one is customer scale, which is different than user scale, right? There’s geographic scale. And then there’s technical complexity, like self driving car is different than a curbside delivery app. Right. And so scale is different depending on which pieces. Now you spoke about transactional scale, which is like API’s. I have a particular product that does roughly 2 trillion API calls per day.
PF For people who are listening, that’s a lot of API calls. Like that’s…a lot. [Rich & Ben laugh]
BW Honestly, it’s like, ended up in a presentation, I changed it to billions because I thought they’d made a mistake. And they said, ”No, no, no, no, that was trillions and T was correct.” I’m like ”Oh my!” because I was new to the product. I was just taking this over and, and it was like it was amazing. When you go look at at the capability that’s driven. It’s amazing. And this type of scale, you have to really think through like, how do I go manage things at that scale? inside Google, we’re kind of a big microservice organization. So you can imagine lots of tiny micro services. So the fact that you get 2 trillion API calls, it sounds like a lot. But isn’t that uncommon in Google, because of the way we’ve constructed our products.
RZ I want to go back to the timeline, right after the research comes in. The research has come in, it’s undeniable in terms of guidance in terms of rationale for what you should go do next. And so you let that inform your requirements, effectively, let’s just let’s be, let’s dumb it down a little bit here. And then this is going to be the next six months of what we’re going to focus on, because this is what the research told us.
PF Wait is six months right? How long does it take to ship a thing inside of Google?
BW It depends on what it is. But I think the first month is denial that they’re correct. [Ben & Paul & Rich laugh] You have a bunch of researchers come back and they tell a bunch of engineers, ”Hey, actually, you’re wrong.” And then the first thing that engineers want to do is go ”Well, wait a minute, what about that assumption? Or what about that assumption?”
RZ You just restated the question I wanted to ask you. Unlike law, where there’s the wrestling, that happens as a bill is debated, and then once it passes into law, the clay hardens, right, and you can’t go change it here. When you write that PRD and it goes out, people keep pecking at it right. As a product leader, how do you deal with the winds that come at an effort? Whether it be doubt, whether it be second guessing, or whether it be? No, there’s a better way? Or why are we doing this? Just the ‘why’ question is exhausting. Why are we doing this as a painful, painful question. So how do you deal with that? I mean, and I, my guess is you’ve got a lot of strong opinions at Google.
BW Yes, absolutely. There are a lot of strong opinions. One of the challenges I think we face in product management is this idea of being able to be clear on our vision, and clear on our strategy. If you’re clear on your vision, your strategy, the idea of a PRD is fulfilling pieces of that vision and that strategy. And the three things cannot be if you will separate it. Now, if you want to get down to details, certainly you can find things that says, well, why are you doing this? And you go, ”Well, we got this big customer, they really need—” [Rich laughs]
RZ Sometimes it’s straightforward.
BW ”And honestly, they said they’d be one of the first customers to use it if it had that feature. And we’re like, if we could use it, so we did it.” Right. So that happens. But let’s just be honest, that’s what happens. But like, usually, like you can be really specific on why that happens. But like, if they’re asking for like a fundamental feature, like, why are we building this right? Or why is this particular feature important to this strategy? Hopefully, it’s self evident. If it’s not self evident, then you’ve done something wrong. And that’s, that’s part of the challenge. I mean, I would love to say I’m an incredibly awesome storyteller. I don’t think I am. I think that every product manager strives to go do that. But I think it’s the everyday work of being able to say, ”Listen, here’s a charter of what I’m trying to go do. Here’s the vision of what I’m trying to go do.” Right? And then be able to say, ”Okay, here’s the strategy around it, and why it makes sense.” Right? And hopefully, part of why it makes sense is, I’m going to go to go drive monthly recurring revenue, or active recurring or annual recurring revenue. And these things will drive you to go and build certain features and functions, so people actually consume it. This is how I think about it. And it’s, it sounds very linear, it sounds very like, ”Oh, wow, it sounds fantastic.” It never quite works that way. Sometimes you’re building a product, and you’re like, ”Oh, hey, I need a vision and strategy for it.” But you never want to be in that situation. But oftentimes, you find yourself.
RZ So okay, so you navigate through that. How do you translate that mission? Let’s talk about your team, the team that’s doing the actual building. And this kind of butts up against the question, I want to ask about how you’re perceived, how product management is understood to be at Google? My guess is it’s something different than a lot of other places. What is the perception of Product Management at Google?
BW I think defining the product and what needs to be built, I mean, being able to marshal the resources together. I mean, if you think about like, I don’t know if you ever seen that picture of like how each organization is structured, right? You have, you have like Microsoft is top down. And then you have like, Apple has got a circle in the center and everything goes out. And if you go look at Google, it’s just like matrix on top of matrix. And it’s like, super confusing to look at it.
RZ So describe Google in this—
BW I think the way I describe Google is its matrix on top of matrix on top of matrix. I mean, the idea of a product manager having 900 people reporting to them. That’s not the way reality works in Google. The way it works is we have these kind of teams and we have a product management team. We have an engineering team. And there could be three or four engineering teams. There’s a UX team, there’s a program management team, all these different teams, and they’re working on different products at any point in time. And you kind of get assigned a slice of their time to go and help you go build something.
RZ Is that frustrating? Slices of time?
BW So I’ve been, up until this point in time, I’ve always been a CTO. So I’ve had both product management and engineering report to me. So I’ve never really had to face that frustration, but it is it is challenging because the idea of getting mindshare is difficult, it is difficult.
PF We’re sort of back to the politician part, like I’m noticing this as Postlight scales. Rich and I function in a more political way, we can’t—used to be, you could just be like, ”Okay, we got to do this.” And that was that. But there’s all these different resources. And you can’t—I mean, yes, nominally, you can stomp your feet and yell all you want. But that’s not an effective strategy. You have to you have to start to kind of compel and persuade people to come into your world.
BW I completely agree with that. I’m not sure I’d use the word politician, I think the word I would use is the ortater of what the value is, it’s going to be driven for a customer. Being able to explain it in terms that each team can understand so they feel like they’re part of that journey you’re going to go on. And you say this, is like, I say this, and I’m like, ”Oh, wow, he must do a really great job.” I actually don’t think I do as good a job as I’d really like to do on it. In fact, I think some days I wake up, and I’m like, ”Man, I’m doing a terrible job at it.” Because trying to do that at scale is quite challenging. And when you have teams that you know, span and the thousands that you’re working with, trying to gain that mind share is quite challenging.
RZ I will say just my experience as a product leader, the secret weapon of an engineer or a designer, that is bought in and really motivated about the thing you’ve got them working on just changes the game in my mind. If you can get some—I mean, that’s why I imagine this is so challenging, because even if someone is really excited about some initiative you’ve got them on, they still have they committed to five other things. And that’s really hard, right? Like we incubate stuff, sometimes at Postlight as well. And it’s just a glorious moment, when you can tell an engineer is like, ”Okay, I believe in this, like, I’m really, I’m into this, I’m gonna think about this some more.” And I’m getting messages at night, because they’ve been thinking about it. That’s a wonderful place to be, right. Because you’re selling not just to stakeholders, as a product leader, you’re selling to your team, as well. People at Google can go—I was about to say can go anywhere they want, but they can probably go anywhere they want inside of Google.
BW That’s absolutely true. I mean, the marketplace inside Google is very fluid. And so you’re always trying to gain that mindshare, to be able to get people to be a part of it. It all comes down to what’s that story you’re telling, and why is it valuable? If the story you’re telling is like, it’s like a compliance story, it’s really, really hard, right? [Rich laughs] I mean, think about compliance, compliance, right is like really, really hard.
RZ People aren’t excited about compliance stories, Ben?! Doesn’t pump them up?!
PF Nobody got that Stanford degree to do 18 months of compliance related engineering? [Rich laughs]
BW I will tell you is, you will find people like that.
PF Well, sure, sure.
BW I mean, this, this is the part that I think product management has got to really get their head around, right? I was doing lots of traveling, and I was staying at this one Marriott for like months on end. And I got to know the general manager there. And he was terrific person. And he’s like, ”Hey, let me buy your drink.” So we’re sitting there having a beer, and he was telling me some of his problems. I said, like, ”How do you find people to go and clean those rooms all the time? It’s like that it’s got to be terrible.” And he goes, you know, what is ”Yeah, I got to go through 5 or 10 of them to be able to find a really good but but you’d be amazed. There are people in the world who love to clean. They love it. It is like they get finished in a room and they get goose bumps and they love it. And it’s like, we know how to find people like that. And when we find people like that we can put them to work. They’re so happy to clean and we’re so happy to have them. It’s fantastic.” And when you think about something like compliance, or you think about like platforms is another one, right? This is the challenge I face in building platforms. When you find that person who like gets that thought processes and says ”man, I love this, this is really what I like to go do.” And usually it’s very service oriented. They love that kind of service approach. Those people like to build platforms, oftentimes those people also like to do things like compliance. For people who are not motivated that way. It’s a strange thing, but it is absolutely 100% true. And I always go back to this general manager that I met at Marriott is a great story.
PF You know, it is true. If you find them, they’re gold and you just want to get out of their way. And no, you know, you keep that list in your back pocket of like, okay, this is a difficult thorny problem that most people would never want to touch. The metaphor we always use this the tax attorney like the that, you know, the one guy that partner in the firm who’s incredibly good at tax law, and may really not be good at anything else, including buying shoes, and they make partner and nobody, nobody wonders why right? They’re like, ”Oh, yeah, obviously.”
RZ What’s the number one warning sign you would give product leaders out there? What’s the signal that makes you go ”Oh, I gotta head this off.”
BW People within the organization saying they’re not bought into the vision. Or they don’t understand it or ”I’m confused”. ”I’m confused” always makes me concerned.
RZ ”I’m confused” is I mean, you might as well just scoop my heart out and just kick it around the room. ”I’m confused” is a rough, rough thing to hear.
PF Well it’s a nice reminder that you haven’t done your job. [Paul & Ben laugh]
BW Yeah. And you know, sometimes people are legitimately confused. And there are other times where it’s they haven’t spent the time to learn to write. I mean, there’s, there’s two ways to communication, right? I mean, there’s the speaker and there’s the listener. And if you’re not listening, or you only have slices of time to listen, or whatever, sometimes you can’t avoid that confusion in certain people. But when you get a large scale confusion, that becomes problematic. And oftentimes, you see it in a couple different ways. One is, ”I don’t understand” or like, ”What’s that value look like?” And the other one that looks like is ”I’m confused”. And those are things that are super concerning. I will tell you is that sometimes in platforms, I think you see that more often than you would a real product, because it’s hard for people to get to wrap their head around the platform, right? I mean, if I’m building, you know, a CRM system or something like that, and I’m just trying to create a funnel and trying to make that work. And I’m trying to explain, like, how do we manage data on the back end, it’s like, I don’t understand the value, I’m confused on why that’s valuable, or how a pipeline works, and why a pipeline has to have validity by estimate data, quality check on it. These are things that are hard sometimes for people to understand, I think, in the space of platforms, I think there’s a higher propensity for people to not understand or be confused. And, and that makes the job a little bit more challenging.
RZ Let’s back up even more. ”I’m confused” is essentially them saying I’m not bought in, and I need you to explain this to me, and you should take the time to do that, right. I read it as passive aggressive in a lot of ways. I also have, I have a very ugly view of humanity generally. [Ben laughs] So maybe I’m not a good—
PF Well see, I love ”I’m confused” because now I get yet another opportunity. I get to explain it all over again. And maybe this time, I’m gonna purify it so that everyone can understand what I’m talking about.
BW Well, I mean, but you do get people who say ”I’m confused”. And you sit down and you talk about it. And in a period of time, it might be in that meeting, it might be over a week, or maybe even longer, that they are all of a sudden are not confused, and they’re like, ”Oh, I get it, I get it.” And then all of a sudden, now you’ve got an advocate. So I mean, I’ll be honest with you, I bristle sometimes at ”I’m confused” too, because it’s just like, okay, so like, let’s talk about it again, especially if the person has been in some of the meetings and you’re like, ”Okay, you’re the only one? Or is there more than one?” And if there’s one, you can always be sure there’s another some place and now you have to go find it, right, and being able to articulate that’s important. And so like, I think that as a product manager, right, you have to take those things seriously and try to go resolve them. Sometimes they don’t want to resolve themselves for one reason or another, and you have to accept it. But in accepting it, what you also have to do is take accountability and responsibility for making sure that articulated if you will, North Star or vision is still clear and that people understand it.
PF Let’s give some people some advice here because, look, here’s what we’ve been talking about, we’ve been talking about the fact that most product managers in the world, if they’re listening to this, most of us will work on apps and websites and sort of things that probably reach thousands, hundreds of thousands, maybe even millions of people. And then there’s that next level in your career. And the next level in your career is not necessarily—maybe it’s that you’re going to go build an app that has more consumers using it. But very likely, if you’re really kind of going deeper into this industry, you’re going further down the stack towards that platform level. That where you live, like it’s a hamburger menu of lots of pieces. I like to make fun of it. But you’re talking trillions of transactions. That’s where the scale is. And that’s where the power is, right? So help me make that transition. You know, let’s say I have a year or two. And I am I’m smart. I know API, it’s work. I’m a good product manager, good eye. I can get an app into the App Store. Ben, tell me what I need to do to come work with you.
BW That’s a tricky question. Because I think that to come work on a platform, I think it’s got to be a kind of thought process. And so it’s like, I want to I want to clarify the question, it’s not come work for Google, because I think there’s many avenues for product managers to come into work for Google. But if you want to come and work on a platform like the platform’s I work on, right, the thing I have to see is, are you willing to be in servitude? Can you get that mindset straight in your head that says, listen, my success is when I see success out there. And when I see that come from a person, they internalize that as a product manager, and they express it, and they express it in terms of Listen, when I make it easier for developers to be able to go create a pipeline and do a transform in that pipeline, and make it so easy that it takes them five seconds rather than 50 hours. And they get excited about that because what they recognize is, that platform added value to that developer, that’s huge. Now, it doesn’t always have to be a developer. Sometimes it can be a user. But oftentimes, with platforms at least I build are often kind of developer focused. And that type of thought process is what I’m looking for. I think the technical expertise is just as important. So that’s a different kind of vector we have to have a conversation about. But the vector has been a really good, if you will, platform product manager has to be around, how do you go and see value derived?
PF That’s been the value of the cloud platforms, right? Is that the thing that used to take you two weeks, and then you would have to configure, you learned a new skill, and now in five minutes, you can have the 20 servers up in the cloud. And that used to be two people full time job. And instead now you’ve pushed three buttons. Now, it all seems magical and obvious now. But getting us there was an unbelievable amount of thought. It’s not a trivial challenge at all, right? So that’s, that’s, so go learn more about the lower level and think about ways to help people absolutely skip steps. So more about acceleration plus experience, as opposed to like, pure experience. Like product management thinks a lot about experience, I’m going to open that up, I have this very specific user journey. But what you’re saying is like, you know, could you also cut out 90% of that user journey?
BW Yes, exactly. I mean, when I was at GE, we were moving to the cloud, and we built something called the bot army. And the whole idea around the bot army is go build a bot that saves people time. Literally, that was the whole message. And there were all sorts of signals we could bring in from the cloud. And we’re able to concatenate that into a way that it was consumable, and you could do analysis against it. And then you could literally point it at almost anything, and you can go, ”Hey, here’s a place where I can save money” or ”Here’s a place that can get better performance” right? I mean, this is what we were really trying to go do. And when you think about it in those terms, and like you just think about like little bots, all of a sudden, you can start to understand it. And when you start to orchestrate the bots, right? All of a sudden that orchestration provides another level of value. And this all sits at the platform level. And I think that those are important concepts to think about. I’m not saying bot army is like the right way to think about platforms. I’m just saying that, from a conceptual perspective, those thought processes about how I can do a single thing better over and over and then orchestrate it together is a powerful concept.
RZ This relates back to the vision statement, I mean, that like that very succinct, 8, 10 words orients all the decisions and drives, a lot of the decisions that you make beneath, this kind of further punctuates the value of it, because then people wonder, ”Why are you doing that?” Well, you just say that statement again, right? It’s like, we’re gonna make it easier.
PF I mean, you know what, this is a sort of meta thing. But I think about this a lot, because the disciplines are very folk like design is very focused on experience, right. And engineering is focused, usually on process, good, reproducible process as well as quality. And so what is product? To me product to me is always about speed, like kind of quietly underneath, it’s always about, can we get it done faster? And then can we make it much, much faster for people on the other side to get it done? Can we give that to our users? And it’s funny, because I talk about this a lot in the firm, but it’s really not the conversation that the industry has a lot of the time, and that’s that this is what you’re giving back to us, right? You’re going, nope, it’s all about to be like how can we cut steps make life simpler and move things along faster, both internally and for the customer over and over again, until one day, there’s just one big button, you just hit that button, and suddenly your entire cloud platform is set up because it uses ML to figure out what you were using, reads your face, it’s like ”Oh, this person needs cloud run”
RZ I mean, eliminating steps is a great part of product, right? When you eliminate steps, you’ve achieved things.
PF It’s such a great feeling when it’s just, it’s almost ridiculous. And it looks so simple. And people think that it’s dumb. That’s how you know, it’s so wonderful. You know, you’ve got a big team, right? You’ve got lots and lots of product managers, dozens, you’ve got zillions of engineers here inside of Google, you know, there’s a there’s a sort of ethos around cloud services are very kind of it’s, you know, kind of DevOps culture, and so on and so forth. You’re gonna need a lot of ideas, you’re gonna need a lot of ways to play an explorer, if you’re going to do something interesting. So get me there, right? Like, there’s a lot of different things to build. How are you getting people to stop building just a much faster web server for the 500th time or the, you know, or, you know, the the Linux server that’s 10%, easier to boot? Where are all these things coming from?
BW That’s a great question because I think we all want a Linux server that’s going to boot 10% faster. I don’t know why we all want that. But somehow we still want that. But when I think about it, I really do think about in terms of diversity. I think oftentimes when you hear Google Talk about diversity, it’s in terms of like gender, or LGBTQ. And those things are extremely important. I always think about diversity in thought, how can you go find that diversity in thought, and that diversity in thought allows you to kind of look at things and different vectors, right, and being able to think about something in a different factor is super important. I was working on a software product in Berlin, where it was for shop floor control systems. And I had one gentleman from the UK who came over to Berlin working for us, and he had a completely different thought process than everyone else. And that complete different thought process led us from a very kind of process orientated shot for control system into a very orchestrated one, instead of everything having to be step by step by step all all in one piece, all of a sudden, we started orchestrating things. And we were able to get the plant from 70% capacity to almost 82% capacity. And that 12% capacity actually is almost all pure profit. And so when you start bringing in that diversity of thought, that really makes a difference. And that’s how I think about it personally as an individual.
PF Look, I mean, that is, that is the story, right? We need lots of people seeing the world lots of ways. So I mean, at this scale, of course, you need the world to talk to the world. Look, Ben, this is great. You are remarkably open and transparent given the fact that you work for a giant global mega corp, we really appreciate that. [music fades in] Because I think people need to understand how things are working at the scale. Google scale today will be other people scale tomorrow. And then Google scale will slowly incorporate the planet Saturn as it gets bigger.
RZ Ben, thank you so much for doing this. This was great.
BW No, it was great. Hey, thank you for your time, guys. And it was it was fun.
PF So last question, if anybody wants to get in touch, what’s the right way to do it?
BW Best way to get in touch with me is I show up as BenjaminWilson@google.com. And you can reach out to me anytime. I’m always happy to talk about product management. It’s always a thrill. And thank you so much for having me on the show. And I look forward to further talking.
PF Alright, Richard, if people want to get in touch with Postlight, a little company compared to Google, what do they do?
RZ Well just hit Postlight.com. I think we put a contact form on literally every single page on the site. So there’s no way out of it.. So just hit Postlight.com.
PF There’s a nice white paper, go to postlight.com/catalyst, check out our white paper about the how to manage software change inside your organization. But yeah, we’d like to hear from people. We will talk to you soon.
RZ Have a great week.
PF Bye! [music ramps up, plays alone for 3 seconds, ends]