Jeremy Pollock === [00:00:00] Going faster doesn't always result in success. We have customers like Starbucks who are losing tens of millions of dollars each day that we're down. You can see the growth of the platform against the decline or diminished investment that was eye-opening for us all saying, Hey, we went through a period of diminished investment. And that has now led to the fraying of our platform. Welcome to Launch Pod, the show from Log Rocket, where we sit down with top product and digital leaders. Today we're talking with Jeremy Pollock, VP of Product at WP Engine. On this episode, we talk about why speed is the new moat. Jeremy is pushing PMs to use AI ship code and move fast because in the AI era, slow teams fall behind for good. How? WP Engine is enabling product teams to use AI through access training and best practices that turn weeks of work into hours, and how big aspirational product goals create momentum. Giving teams the motivation to eat their vegetables and tackle a foundational work required for long-term success. So here's our conversation with Jeremy Pollock. Jeff: Jeremy, welcome to the show, man. [00:01:00] Thank you so much for coming on. Jeremy: thank you for having me. Jeff: This is gonna be fun. , I think we got a cool show today because you've had a, a cool experience. You, you're now at WP Engine, been there three years, VP of product, uh, through a very, you know, important time in just the web with AI and everything's moving. But, you know, looking back over your career. You spent time at Lightbend PubNub, , you had a whole interlude of being at Mastery and going through two acquisitions. \ , you started out as a sales engineer though, and I think all of this kinda rolls into a really neat, I. Way to talk about how the world has come full circle, right? You moved into product from being a sales engineer. You could be a little more hands on. You could kind of do it yourself a bit more, uh, and you, you ship some stuff, you know, kinda as a product person, very early on in, in doing stuff for yourself. But with ai, this is, I. kind the new expectation. And so I think that's kind of the real, real quick version of the story we have is [00:02:00] learn to do it yourself and then now that's a world everyone has to do with themselves. So maybe we start from the beginning and just, you know, you started out as a sales engineer and, and how'd you kind get into a product and what did that mean for your ability to self surface, self-service a bit? Jeremy: Yeah, sure. And, uh, you know, I do this before I jump into that, I, I definitely, whenever I see like any, any tweets or xs or whatever we call them these days. Jeff: I still call 'em tweets. Jeremy: Tweets, tweets are good. Uh, when, when they, when they do a tweet about like, you know, we don't need any more engineers. Clearly we need more engineers. Jeff: Oh, we always need more engineers. Jeremy: yes, but I do like the spirit that's emerging as like, you know, product managers having more influence, more control, , more input in, into what's being built and how it's being built. And again, that's not about dictating code, but I just love this, this emergence of. DIY type attitude within the product management community. And when I think about my first entry into product management 25 years ago, which sounds so crazy to say, but I [00:03:00] was the know it all sales engineer for a small startup doing content management systems for. Technical documentation and other types of, doc sets. We got acquired by this company called Broad Vision, which is an early internet pioneer serving, you know, massive sites out there in the early days of, of the internet. Um, large scale e-comm sites like Sears, if you remember, sears.com, et Jeff: Oh yeah. Jeremy: sites like that. remember being on the phone with the, the product leader. Saying all the things I wanted to do with this product or what was wrong with this product. And he said, Hey, why don't you come over to product management and, and start solving these problems? And, and once I got into pm it was, set it and forget it. I just love this notion of building solutions at scale or customers and solving complex problems and. It was born from not just the product management ethos of actually identifying important problems and coming up with solutions that deliver value. But for me, I've always been a [00:04:00] developer myself. I've been coding since a long time, more than 25 years. I won't say the actual years since that will date me quite a bit, but I've always had, you know, hands-on keyboard. Jeff: Mm-hmm. Jeremy: into product management, especially at a company at Broad Vision where we're doing large scale platforms, this ability to kind of dig into the code and start using code to translate ideas into tangible pictures that would better represent my story or my vision, really proved to be , a great value to me. , I remember early first project, , at Broad Vision where I kind of used this technique. Of, you know, illustrating the, problem and the solution. We were trying to deliver , a new integration framework into our portal technology. So think single pane of glass application that allows the user to get access to content and functionality scattered throughout an enterprise in third party applications. There was a new standard that was emerging that would dictate [00:05:00] how these portal technologies could. Exposed third party data and capabilities through the single pane of glass. The engineering team and I were having challenging conversations. does this mean? What does this mean to our product strategy? What does this mean to our users? How do we actually implement this standard? Because they don't give you the guidebook on how to do that. Jeff: Mm-hmm. Jeremy: that's when I just decided for some reason to roll up my sleeves. Dig into our, I think at the time it was a, a serlet based application, so Java and just did a rough proof of concept of how the standard could be applied within the context of our application and our customer base. And I still clearly remember the, the meeting today where the light bulbs you could see going off in the minds of the engineering team. We had a much more productive conversation. Just as important. I think it established credibility, my credibility with the team that much more so I was working on a developer platform. [00:06:00] I was coming to them with a developer mindset as well, and that was just so much better received and coming in as a kind of a classic marketing person. No disrespect with, Jeff: None taken. Jeremy: the PowerPoint that shows kind of like the vision doesn't speak to the. Tangibility of what Jeff: Yeah. Jeremy: do. And that technique has proven to be successful time and time again, albeit my main experience has been in the developer platform space. So this type of like developer focused ethos has paid off quite successfully. Jeff: Mm-hmm. Jeremy: but as we transition into the world of AI where you don't have to be as deeply experienced on the tech front as someone like myself. with ai, you can use lots of great technologies out there, different LLMs, different development tools. Tools like Cursor Lovable. You have Kline integrated into Visual Studio Code. [00:07:00] You can really rapidly start to create these proofs of concepts that are clickable, that show your vision, show the problem space, and become , a much more effective communication artifact or vehicle. When interacting with everyone from engineers, but also to customers and even executive stakeholders. Jeff: no, , it is interesting 'cause you bring it up, you saw the light go off when you showed something, you know, clickable, usable. It was not production ready by any means. But they could touch it, they could see it, they could kind of grasp it, and everyone communicates differently. And I, I feel like I've run into several people and several really intelligent, smart, really, really productive people who have trouble sometimes envisioning if it's not their vision, envisioning , the step you're talking about. But if you can make it real and in front of them, and not even fully functional, but just the teaser where it starts to become real, you see the light goes off and, you know, I, I remember. Maybe a year ago, year and a half ago, there was this [00:08:00] functionality that we really wanted to build on the marketing side that needed a browser extension. And I was trying to get it prioritized and prioritized and, and the engineering team we had dedicated to it just kind of kept, you know, never made it above the fold. And then finally I went out and used some of the tools you talked about, , and I think this is before a lot of 'em came out. So I was using just chat, GPT and whatever, and threw together a thing that got, I. 80% of the way of, almost functioning. But they could start to see some of it, but they also could see where it broke and where it didn't work. And then it became, oh, we can knock this out. We can do a better version of that. This makes total sense. Versus having a vision, like, how do we do that and why would we even do that in the first place? Once you kind of saw it, it just became, oh, we can fix that. That's easy, and I get why it's necessary. So I do feel like that kind of making it real , is an important step for some people , to move it forward. Jeremy: Yeah, for sure. And, , there's certainly the art of delivery too. It's like walking into an engineering. Team team and saying, here's my get repo for this feature Jeff: Mm-hmm. Jeremy: not the right approach. You know, [00:09:00] they, they, Jeff: Yeah. Jeremy: to build, they want to do their job. They don't wanna have their job taken away by a, a Jeff: Right. Jeremy: , but going in there with , the right approach of like, I wanted to paint a picture of , how we could approach this a problem, how we could solve it. This isn't the code, this isn't to your point. Production worthy. That's not what I was trying to achieve. I was trying to achieve better storytelling. you know, that's useful in kind of bringing down their guard so they can have a much more engaged conversation. Jeff: I actually wonder even, , I'm sure you've heard about this, it's kind of all over the place now about, someone brought up the way to get information on something like Reddit is not to ask a question, but it's almost to like. Make a statement that's wrong about the subject that you're trying to get the answer on, and then just everyone will come outta the woodwork to tell you that you're wrong or maybe, you know, step two profiles and ask the question, then put the wrong answer right away and everyone will come out and you'll get the right answer that way much faster as you just ask the question. And almost is this. A corollary rule to that, you know, if you just ask for the feature to be built or worked on, [00:10:00] it's tough to get it. But once you kinda show it and, , you don't do a production ready job, like, ah, I could, I could do this. Let me fix it now. Jeremy: You know, us humans are awfully good at pointing out the faults Jeff: Yeah. Jeremy: So putting out , , these proposed answer and being okay with accepting people saying that's wrong. You know, it Jeff: Yeah. Jeremy: courage, some strength to do that. And I think that's why sometimes people don't do that. They're like afraid of getting that criticism. But to your point, and I actually, I just walked out of a strategy discussion, this morning with our product and engineering team, Jeff: Mm-hmm. Jeremy: we were going through some product strategy and there was a paragraph that was a little bit too open-ended , it left a lot of room for the interpretation for the reader so they could kind of walk away with whatever they wanted to get from that paragraph. And I said, no, we should just make this clear statement. , it's very, specific, it cuts off a whole swath of the market, and it may be the wrong answer, but let's get better engagement with this paragraph, this set of words, by putting out an answer whether right or wrong, and in your case, [00:11:00] maybe sometimes it's put the wrong answer just to get people to, to focus in and providing better feedback and engagement. Jeff: I think kinda make this real again. , we kind of got to catch up a little bit a week or two ago. Um. Ade, I know, you know, she was over at, uh, WP Engine for a while and you worked with her there. So we have that common friend and she kinda gave, you know, topics and background on you and, and so I have a little more context, but I, I think you brought this up actually, over at Pub Nub. There's a great example of this kind of around making it real, you know, Peloton early on did really well because they were able to kind of like make it more community based and who's online and, and who are you with and all that kind of stuff. But it, it seems like you were, you know, maybe a bit involved in, in bringing that to fruition, , while you were at Pub Dub. Jeremy: Pub nub. So real time communication platform. Think location, tracking, chat, that same type of capability or set of APIs and customers Peloton. Um, actually early days of the pandemic, of course Peloton, all the rage. Jeff: Oh yeah. Jeremy: and , they were having, a [00:12:00] desire to basically, if you're on the bike, , you're seeing who else is riding and where you are relative position. Are you like at the end of the pack? Are you the leader? So that leaderboard functionality is a great way for people , to engage, you know, think about what they're doing and gaining more, more, more, more momentum and ambition. Peloton had a desire , to provide a capability to allow the filtering of that list. So there's 10,000 people on a ride. I don't wanna see all 10,000. I wanna know how am I doing relative to 50 plus men in San Francisco. example. So Jeff: Yeah. Jeremy: a basically a real-time leaderboard and reducing it to just what I'm interested in, that moment in time Jeff: Mm-hmm. Jeremy: rather straightforward and, and definitely yielded great results for Peloton. At PubNub it was, okay, how do we take that capability and then translate it , into action, into the product using a similar type of technique. Sketching out what we thought the API would look [00:13:00] like, the Peloton would be using it. And then using that as an artifact to communicate with engineering. Just a another example of kind of painting the picture in a tangible way to quickly get to the result that we're looking at for the customer. Jeff: Well it's, it's so interesting because I feel like a lot of innovation kind of comes from that piece, right? Part of it is you need to show zero to one is possible, and once you've hit zero to one. One to 10 is just an optimization project almost at that point, right? Like you need to make the code, , production ready. You need to make sure it's secure. You need to, do all those things where you can, you know, sell it to people, but zero to one. It doesn't have to be perfect. It just has to paint the picture , and show the functionality. On our end, we have, um, kinda a similar idea where, you know, we do session, replay, , analytics. And the big problem with all of that has been how do you parse through, you know, WP Engine, must have millions and millions of of users every month in sessions, every month. You're not gonna watch, no matter what tool you use, I, I don't know what tool you use, but [00:14:00] you're not gonna watch every session there. , but there's a ton of information baked in that, but how could you possibly parse it down into just the things that are interesting? How can you bring that forward intelligently? , and that was the same thing. And early on it was a lot of. Um, taking data sets on our end, but also manually parsing stuff and finding out how that worked, and then finding out the rules and the levels and, and what are the thresholds. And that was quickly able to be, you know, turned by engineering into scalable and that one to 10 and 10 to 100 product. But early on it was kind of, you know, a couple people who maybe, , weren't necessarily production level engineers, but they were making it. Work and showing it was possible, so then you could take it and drive it forward into automated AI based and all of that. But you had to kind of build the foundation first that way and a little bit more manual, the structure. Jeremy: I love this, train of thought here because it does speak to one of , the great values that I'm getting AI right now. Jeff: Yeah. Jeremy: Which is, I know it's weird to say, like, my conversation with the ai, my collaboration with the ai, and I'm not just taking whatever the AI is spitting [00:15:00] out always in this, you know, putting it out there into the world and say that's the truth. But at the same time, it's the, ability to kind of get into , the sausage making of whatever you're trying to do. Jeff: Yeah. Jeremy: Building a, a proof of concept or building that picture, that zero to one kind of solution. Learning a lot just by, by doing , Jeff: Yeah. Jeremy: the mistake, and, , the feedback loop becomes a lot tighter, a lot quicker. and that's one of the great values that I'm seeing right now in my day-to-day AI work is just being able to have that messy sausage making process that I learned from, that I can then adapt my own vision towards having that happen much, much more quickly. Jeff: Exactly. I think the more people who can help make the sausage and, and get involved, probably a better product in the end. Um, then the other kind of, I think thing that kind of guides this is there is just so much happening in ai, so it's one thing that more people are gonna be, able to start building, right? You're gonna definitely be able to move faster. More people are gonna help make that sausage. But [00:16:00] there's also just. Every day, I guess so many different new sausage makers being thrown at us. , and one thing to keep in mind through all of this is how do you keep kind of focused on like what is core product mission? How do we make sure we're not just building something and build it? , I heard one person talk recently about. in their role as an engineer, they're actually finding themselves building less things, not more now, because it's easier because they're thinking through the kind of next steps of like, how will this go? How will I move it forward? , how will I one to attend it, not just build it and see what happens, which is interesting, but you kind of had a, experience here I think helps with mastering this idea of focus and speed. , you were at Mastery, went through a series of acquisitions and what kind of came out. The other end is a great lesson in focus and time to execution and just keeping up speed and good things can happen. Jeremy: Yeah, definitely. , it was great to, go through a successful exit mastery to, to Intel. But of course, mastery was a small, I think it was like 200 person Jeff: [00:17:00] Mm-hmm. Jeremy: SaaS platform. Uh, Intel obviously much bigger, and there was definitely, um, Jeff: Probably a little bit. Jeremy: of, of culture, if you will. Intel had this wonderful vision that Mastery was a small part of, hence the acquisition. And they would come in and, and pull our architects off, key engineers off to go work on this vision. That was more just proof of concept than anything else. And so we had a lot of, , uncertainty, Jeff: Mm-hmm. Jeremy: business. And, you know, that created challenges for us, especially as a product organization. could we build or what should we build? , how can we get the velocity that we need? What is gonna happen to mastery, what's gonna happen to our customers? So lots of uncertainty , and confusion and chaos to a certain extent. And, there, it, it was really, I know it sounds straightforward, but it's like getting back to the basics. Like what are the problems are we solving? [00:18:00] You know, for whom are we solving them? Why does it matter that we solve those problems? So, just even just kind of get the product management core, the what I would call, at least at Mastery, it was the beating heart of the company. Every group is important, but you know, product was such a strong function, and so having the PM team be confident and strong was really important to helping the rest of the organization. So first step was to get the PMs. Just again, aligned back to basics. What Jeff: Yeah. Jeremy: that we're solving? Why are they important to be solved? And then how are we gonna solve them? then communication, communication, communication. That was really the second piece of the puzzle, which was as the being heart, at least for mastery, strong product management function. We had to be visible. We had to be overly visible. For lack of better phrase, but you know, make sure that we weren't just hiding because we ourselves were uncertain and had lots of doubts. We had to be reaching out to folks both internally and externally. So, know, [00:19:00] adhering to our rhythm of how we were communicating on a regular basis, whether it's via Slack, via email, you know, webinars or presentations. Just being active was another piece of the puzzle of kind of maintaining the strength of mastery. And then the third piece I think was just being people-centric. Again, pretty obvious, but I think even more important these days. I have some mistakes in there too. We were perhaps in some cases to people-centric, , trying to keep teams focused on a feature that we had decided to invest in a year prior, when. should have revisited that decision, but we were just too scared to make too much change in the organization. So just let that team go that was a mistake. But just generally being there for people, , was just really important to getting us to weather the storm, if you will, of this uncertain period. We came out at the opposite end in a good place as we were divested or moved across to TIBCO and school [00:20:00] enterprise application platform. Jeff: Yeah. Jeremy: and so again, those that pm basics, communication and people centricity were the three ingredients I think that really helped us weather that period at Mastery at Intel. Jeff: It makes sense. And then, you know, going to tibco, it's interesting because I'd, I'd wager, everyone thinks big company, probably same problems, but at some level. New problems. Different problems, still problems. , and I'm curious, I've been through that too. I've been at the company that was acquired by, a company that was multiple, multiple, multiple x bigger than us, to the point where they didn't even have to report us on their public disclosures necessarily. 'cause it was such an immaterial thing to their revenue. Going in and just realizing kind of speed of delivery is, is expected to be slower. , and how do you kind of square that mindset, these start people you've brought with you who are used to, you know, move fast, is it's move fast or die a lot of the time at a startup. , and how do you kind of push that forward, but also , what can we [00:21:00] learn from that in kind of this new world where maybe, you can't take two years to ship a small feature. Jeremy: Yeah, that, that's for sure. Um, and, and definitely, you know, TIBCO was a, a much better home from ri like we could say APIs and they would know what APIs were. Uh, they had, had a different view of, of APIs. Again, they were Jeff: Yeah. Jeremy: software. They were just starting to get into the cloud-based business and we Jeff: Mm-hmm. Jeremy: software as a service. And, you know, just completely different mindset of releasing features on a weekly basis that would be actually visible and usable by, by customers. And I, I think that one powerful lesson to take is, , going faster doesn't always result in success. Jeff: Mm. Jeremy: you gotta move slow in order , to provide value to customers. think being thoughtful about how you invest is super important, especially in the AI era where I, I believe that trust in systems will become that much more important. If something is failing, you know, it gets me from zero to [00:22:00] one like that and then falls over when it goes to two and three and four and beyond. I think people will get, there'll be fatigue around that. And so investing appropriately , in robust systems , as needed, becomes really important. why I bring that up is, you know, I think one of the key attributes of a cloud-based platform, a software as a service, infrastructure as a service, whatever, is this notion of an incident Jeff: Mm-hmm. Jeremy: when they happen out there in the cloud, it's not so much fun because customers can't get access to the application. Jeff: Yeah. Jeremy: getting the value that, that you sold them on and. About a year into our TCO our TCO era, if you will. We, we started having many, many, many more big incidents. Like we had a, i, I call it the year of incidents Jeff: It's a long time to be a period of incidents. Jeremy: It was intense. I think Jeff: Yeah. Jeremy: was very concerned about my health as lots of weekends were spent trying to, to[00:23:00] Jeff: Oh Jeremy: rooms and resolve issues for some big customers who were losing, you know, millions upon millions of dollars during this timeframe. And, you know, I think it came down , to trying to get more attention from Tipco. Jeff: Yeah. Jeremy: who did step up to, to wanna say, okay, how do we invest differently in this Jeff: Mm-hmm. Jeremy: And, and this is where it came down to framing the problem up correctly. Hey, TCO execs, we have customers like Starbucks who are losing tens of millions of dollars each day that we're down. You know, that's super important to us, but also really important to them, obviously, using data strategically. I remember putting together a chart of, API traffic along with amount of r and d investment. So people, in time that were investing in the platform at the beginning of mastery, you know, API traffic or usage of our product goes up and up and up Jeff: Mm-hmm. Jeremy: and d spend goes up and up and up because we're trying to grow the business. And then we [00:24:00] got picked up by Intel, API Traffic or usage of platform continues to go up. But our investment in the platform plateaus and then starts to decline. And so you can kind of see that quite clearly the growth of the platform against the decline or diminished investment. And then we could start layering in the incidents that were happening. And it was this, this wonderful picture databased that was eye-opening for us all saying, Hey, we went through a period of non-investment or diminished investment and that has now led to. The fraying of our platform and incidents are having severe business impact for our customers. Here's what we need to do. So the solution becomes quite clear and just being clear on the solution was just as important as framing up The problem with supporting data, it's, here's what we need to do. We need to hunker down, we need to fix our processes, we need to regain Jeff: Mm-hmm. Jeremy: knowledge as people have left. Post acquisition. , ultimately really [00:25:00] focusing on the stability of the platform as opposed to building new features or responding to one-off requests from classic Jeff: Yeah. Jeremy: customers. , so that was an example I think of, of going slower, if you will. We taking Jeff: Right, Jeremy: step back and, and pausing and really focusing on our platform. But that's not every day, and this is Jeff: right. Jeremy: you know, equal example of looking at. When we were trying to do, , many different enhancements, , adding simple forms on a field, simple forms on a page, you know, ended up taking weeks upon weeks upon weeks just way too long. And in this era of ai, especially, , any company that takes a long time to do simple features, I think is is not gonna be around for too long. Um, Jeff: Yeah. Jeremy: are some complex things that just take longer time. Under, infrastructure management, distributed systems, not everything requires that. And I think having this mix of where to spend your time, when to go slow and when to go fast becomes that much more [00:26:00] important in this day Jeff: Yeah, although I'm gonna push back on you a little bit here just in that it doesn't. Sound like necessarily the value came from moving slow. It, it came from speed. Doesn't have to be about shipping. Feature, feature, feature, feature, feature, feature that are all public facing. Like those issues that were causing, you know, Starbucks to lose tens of millions of dollars a day. You want to fix those behind the scenes problems fast. It just might not result in. Something that was visibly changed to the end user. You weren't shipping, , a new feature, a new capability, , I would argue it's probably behooved you to solve that problem quickly as causing that problem for Starbucks. Um, and that comes down to right, like. Being, like you said, clear on the problem, clear on what you want the outcome to be, and then in that world, still bureaucracies are gonna kill your ability to do that. If you have to go through five or six or eight people who have to approve how you're going to fix that problem. If you're going to argue about , what does fixed really mean? , which, and I, say this 'cause I've had these conversations at bigger companies before when we're [00:27:00] like, well, let's fix it. Well, let's define first what fix means. And like maybe we can fit it into like these points and that's the wrong team to work on that. And you run into all these things where. Yes, you want to take the time to assess and do the right work, and it might not always look like you're flying forward, but you still want to accomplish these things that you know you're moving quickly. Even if it's not the typical. Move fast and break things and ship, feature, feature, feature all the time kind of stuff. Jeremy: Yeah. I, I love that, and thank you so much for, for pushing back because I do think it's, it's not a question of going slower. Sort of platform work is always gonna be perceived as going slow by people on the platform. Jeff: Yeah. Jeremy: you look and read platforms, you're like, Hey, actually you, you could be going very, very fast, but still making small changes over time simply by nature of the beast of, of how big that platform Jeff: Yeah. Jeremy: Um, but yeah, you know, working. Jeff: Right. Jeremy: Intentionally, aggressively towards solving customer problems, even if they're, you know, backend platform issues.[00:28:00] Jeff: Yeah. Jeremy: super, super important. Jeff: Or, um, I mentioned SA, uh, de earlier, but her husband Aji, who I, who I know really well as well, , I think he's brought up the idea before of like when he was at Twitter. The idea came about being able to edit posted tweets, which seems like a very simple, you know, yeah. Just. Let me edit the tweet that I just posted. Why is that so hard? It seems like a pretty simple, just turn the permission on. Uh, and in reality it was the way a lot of the architecture had been done over, you know, 36 or more different Submodules, was that these were indelibly written not to be edited because of how it had to interact with other systems. And so, you know, you can move quickly and check off, , system one subsystem, two subsystem, and maybe you're moving quickly through, the 36 or whatever number it was, subsystems. But, , changing , what is perceived to be one little thing might take a while. So, what I always kind of push here on is let's move quickly and show that we're making progress and at least [00:29:00] extoll internally. We need to move quickly through all these things. It might not always look externally, like you said, there's, you know, sometimes big, big feature sets that you need to move slowly externally looking because there's a lot going on or, or a really highly sensitive system that you wanna be very careful about security , or durability of data. But, once you kind of know what you're doing, , let's not waste our time with stupid decisions that we know that's the right thing to do, kind of stuff. Jeremy: Yeah, definitely. And actually one of the things just kind of sparked the , recent work here at WP Engine, , where , we've spent, you know, considerable amount , of time. our platform to match the expectations of our customers around performance and scale in this modern era. And, been a lot of things going on behind the scenes and, you know, if they're successful, which is great, but to your point of like laying out the plan and communicating the progress against that plan, is really effective. Even if it's not the, you know, the fun little shiny ball feature Jeff: Right. Jeremy: get excited about. Um, a rational laid out [00:30:00] plan that people are moving against and can show progress , and people are supportive of. And I would argue people both on product and engineering that can corroborate the complexity. Um, I think that's important too, so that people Jeff: Yeah. Jeremy: that even though it's a small little visible change on the front end, is why it's gonna take six months. We're aggressively moving Jeff: Yeah. Jeremy: problem or solving the problem, but still takes six months. of these reasons, and here's how we've broken out the plan and here's our progress, , at WP Engine that's been working so successfully in getting everyone on board with these types of major investments that improve customer experience, but not necessarily in , a shiny ball, , visible type of way. Jeff: When I was younger I ran track and this is one of those times I kind of harken back to, I feel like there's certain areas where it doesn't have to be sports, it can be different activities, but something you're competitive about and has kind of organized structure to that competition is just so helpful from a framing of knowing this because,, looking back [00:31:00] right when I have just run for running sake and for, you know, being in shape, I'll generally just go. Jog a couple miles and that that is what it is. But when I had, races lined up or things I was competing on, , and the metaphor would be to having, , a big goal or capability you're shipping towards for a product. You're willing to do those kind of, not fun, hard, kind of eat your vegetables, things like you're gonna do the sprint workouts, you're gonna do the hill workouts, if you know you have a certain race or a certain competition where you need to be at a certain level, , same if you're shipping the product, you're going to do the backend, maybe database cleanup work or the other things that are not that fun, but they're gonna make the product capable of handling this really cool capability. But if you don't have that big goal, eating your vegetables kind of activities, just. Feel like eating steamed broccoli, and that is disgusting, Jeremy: I a hundred percent agree with you. Whenever my wife cooks steamed broccoli, I'm like, what are you doing? You're killing me here.[00:32:00] Jeff: but it's really healthy for you. Jeremy: Exactly. So she's not killing me. But Jeff: Yeah. Yeah. Jeremy: tasty. Jeff: I do wanna hit one thing because I think you, you've had some cool experience and this, we promised everyone that this would wrap into this kind of meta lesson, and it is now we live in a world where, , we're being sold 25 sausage makers a day. There's just a different AI solution coming out every day. But also like the expectation is you can ship your own stuff. The contribution level that people can have is so much higher to prove that kind of zero to one or to prove the storytelling or to make the point that this is something we should work on, or, you know, to make the wrong statement. Even so someone can come in and, and correct you versus have to go zero to one. You're at WP Engine, just such a great exposure to, to so much of the web there like. How are you there, you know, using AI with a team, so not say even in the product, but just with your team. , how do you, within the workflows use it? How do you enable your team to also kinda move forward? Use it, how do you move with speed? It's not all about playing with the new shiny toys, it's how you're using this to be, you know, better, faster, stronger [00:33:00] kind of stuff. Jeremy: Yeah. Uh, to have us eat our vegetables, Jeff: How do we, how do you eat your broccoli over at WP Engine? Jeremy: Yeah. Yeah, exactly. , I think as you were describing that, I think there's, part of that , for me at least, it's lowering the barrier to entry. Jeff: Mm-hmm. Jeremy: there are tasks that I need to do that we all have to do that are eating our, vegetables, and it's just like, uh, I've gotta go to this site on our internet to get this form. Jeff: Mm-hmm. Jeremy: it, to fill it out to, to whatever it is there, there's always steps to doing something. in many ways I think AI removes a lot of those steps and whether it's, you know, doing things that I may not wanna do, like perhaps in-depth competitive intelligence gathering or. Some data querying or I want to, you know, put together a small proof of concept of something like, it just feels like the barrier to entry to get going has been dramatically lowered and, and that's what I've been trying to do more and more is just leverage AI tools to get me going and engaged in the [00:34:00] problem and work towards a solution much more quickly than before. kind of a mindset we're trying to get more and more , into the heads or the minds of, of our product managers. , we're still early on in our kind of collective use , of AI here at WP Engine from a Jeff: Yeah. Jeremy: management perspective. We have other parts of the business, like our support team that is using AI heavily to improve the service or level of support that we deliver our customers. Jeff: Mm-hmm. Jeremy: a kind of a product management perspective, it's still early days. You know, think of that more as shadow IT people are using Jeff: Yeah. Jeremy: tools of choice. They're exploring chat, GPT and claw and lovable, and bolt and cursor and so on and so forth. I. All sorts of tools out there. Uh, we are in the process , of helping them get beyond just shadow it. And this is where, you know, we're at a moment where , it's good to have, you know, your own spend perhaps , to play with it. Not everyone can afford to get, you know, more advanced plans. So let's give them access to the right set of tools that we think will help [00:35:00] them. Tools like Claude and Chat, PT amongst others, getting them. support and the time to invest. So people , can know that they can actually spend the time and use these tools in different ways, whether creating product briefs, creating the stories that get fit into Jira, doing that query for, you know, product usage analysis. It's okay to do that. I think the third area that we're we're focusing on is providing examples. So I talked about access, I talked about support. It's the examples of what you can do with these things. And I've been trying to do this more and more on my end. It sometimes could be weird for a VP of product to create a product brief, and my point is to not take their jobs away from them at all. It's the, Hey, I am using AI as part of my process. Jeff: Yeah. Jeremy: Part of this product brief is half Jeremy and half Claude, or 75% Jeremy and 25% Claude or whatever it is. Um, not [00:36:00] to show the the finished artifact, but actually starting to show the steps that I went through. \ , in this case, I, I typically use Visual Studio Code Plus Klein. I'm a big fan of, that world, but just going through the steps of, here are the prompts I used, here's the back and forth I went through. it may not be the right way to do it. It may not be the perfect way to do it, but showing the example of what can be done and how to approach it, especially through higher level leadership and saying, it's okay to do that. We can be vulnerable in our journey here. And here are the mistakes, here are the, the successes, and together we'll, we'll learn how to do this most effectively time. that seems to be really. Taking root here at WP Engine. And I think why it is, is because every company has a great culture. I get it. Uh, WP Engine I think is a special place and we're so focused on the people, both ourselves and our customers, this kind [00:37:00] of, the human centricity of the AI world is that much more important. We're all navigating the implications of AI, both for our customers and for ourselves, and. Approaching it from that human-centric way, I think is also being quite effective because it speaks to our values and feel less scared in jumping into ai. Jeff: Can you maybe talk about, like, any specific, what's something cool that someone has figured out that, you know, has saved time or, , been maybe better output for the same amount of time , from being able to do all this? Jeremy: So huge impact that we're seeing, , is in the search base. So we have a new product out there. , it's been out there for quite some time called w VP Engine Smart Search. you know, it's a, it's an AI driven. Search engine, if you will, that can be integrated with our customer sites. And when comparing to out of the box search from WordPress and third party bolt-ons, we're seeing dramatically improved [00:38:00] performance on of onsite search. Especially in those situations where the visitors are not exactly inputting information, you know, in the right way, Jeff: Mm-hmm. Jeremy: If they're not quite remembering what they're, they're looking for, so they're being a little bit vague in, in their search input terms. Typically in the past that would result in no results or Jeff: Yeah. Jeremy: Uh, with AI driven search, we're seeing . Much more effective search performance, especially for e-comm type sites where people are, you know, wanting to get to the product in question Jeff: Mm-hmm. Jeremy: a kind of a product, , market facing value where we've created using ai, , internally from a , process perspective, know, it's, it's more around the creation of product briefs. Jeff: Mm-hmm. Jeremy: level. Investment thesis, if you will, that we kind of start off with, with any major investment. , and, you know, what was taking, week two weeks can now be done , in single digit [00:39:00] hours. Jeff: Mm-hmm. Jeremy: and that's the, you know, rough forming of, of the thesis. The problem, not worrying so much about language and structure the document, um, but using kind of more raw formed thoughts, well thought out. You can't just not think. But this kind of new process of creating these high level product briefs goes from, you know, many, many weeks of to get the right energy, trying to great get the right perspectives, trying to get the time to actually do the writing that you wanna share with your fellow product managers, to something that is much more quick to get it to a V one that is worthy of a review. using AI to take your thoughts, engage in a collaborative feedback loop and edit loop. And then get to a a v one again within single digit hours as opposed to single digit weeks. Jeff: I have talked to so many people kind of across the country now about how teams are using AI and especially product teams 'cause that's kinda where I spend a lot of my time [00:40:00] with and writing comes down to it because it's such a huge part of how we communicate. , 'cause one thing to talk, and I think it's a great way for ideas to free flow, is to speak. But at some level or at some point, you need that durably recorded in a way that can be referenced back I feel like you and I can have a conversation and we can walk away going, oh yeah, I mean, Jeremy's on the same page with me. , we're simpatico, we get what's going on. We have the same idea here, but in reality. It's very easy to speak to each other and come away and think we're on the same page and really be, you know, maybe 15 degrees off. When you write it down and people read it and get it, I feel like it's a much more, you either get it or you don't. And if you don't get it, it's gonna be very clear that we're not on the same page. , and just across the board, I've seen so many people talk about how do you write more clearly? How do you more quickly write, how do you take a lot of information and condense it down into just the really, really salient. Written points really fast. , and then how do you interpret that? And like you said, then, how do you search across that? I mean, even as [00:41:00] far as doing these podcasts, it used to take, I don't know, eight, 10 hours for each episode to like, prepare for and get everything together. And a lot of that was just. You know, in your case it would've been going through everything you've ever written on LinkedIn, everything published in the past couple years about WP Engine, , and kind of trying to parse that together in the context of some things we talked about, you know, a couple weeks back. And now we're able to use a couple agents to kind of feed that together. You still need the taste level, right? We still need to, . Just people know, like before we recorded this a couple weeks ago, we got on a phone call with, , you and, , our producer, em and myself, and we talked through stuff and we kind of had an idea of story structures and , we still did the human level of talking through how we're gonna make this work, but to go out and fill in the color around that. We're able to do that 20 times faster now, , and really make sure, and it. It doesn't do the work for us, but it does the, the grunt work. It does the sanity checking. It makes sure I didn't miss an important point that we talked about. Make sure that there's maybe an [00:42:00] angle out there in the world that we could discuss. I think it's made for a much more rich, , discourse and, and I have more time to kind of focus on doing this well versus just going and reading a bunch of LinkedIn posts. Jeremy: Yeah, and it's great. I love it and it's the, at least for PMs, I think about collaboration of I, I think of my AI as Jeff: Yeah. Yes. Jeremy: deferring to them. Um, and I, I, I put together a gamma presentation. Gamma is awesome for presentations from Jeff: Yeah. Jeremy: driven content. it was just about my own journey. And one of the key points I, I made was to, Hey, if you're gonna have to present, if you're gonna have to be in a meeting and defend that document, you better be engaged in the process of developing that content for that document. You Jeff: Yeah. Jeremy: do a prompt. Produce a product brief and then call it done. It's in that loop of editing and exploration. I still feel like you can create good written content from a communication perspective, but also use the writing process, which I think is really [00:43:00] just as important to refine your thinking and approach, you get more invested in the problem that you're trying to solve. And if you lose that as a pm. You're gonna fail miserably in that product brief defense meeting because you'll be like, I don't know, the AI wrote it. , Jeff: Yeah. Jeremy: not gonna flow off the tip of your tongue as you go to talk about the details. Jeff: Right. You can't just kind of hand off responsibility. But at the same time, I, I feel like product people more than almost anyone else have just this like. Franken stack of places where you have data and context and information and just, it takes so much time to get across and understand any singular thing that, you know, they can do a lot to help you there, pull it together. But you have to bring the experience and the taste and the understanding to put it together and, and finalize it. So it's not going to do your job for you, but it can help you do the parts that are the broccoli. Uh, Jeremy: Yeah, definitely. Jeff: I could keep you here all day, thank you so much for coming on, Jeremy. It was a, it was a [00:44:00] pleasure. Um, if people wanna reach out, they wanna ask questions about ai, how you guys are using it, or they have, you know, thoughts maybe about how, what they've seen work really well. , is LinkedIn the best place or is there a better place to reach out? Jeremy: Uh, LinkedIn. I'm on Twitter, Jeremy dot Pollock, or if you wanna send me an email, go old school at jeremy Pollock at WP Engine. more than happy to engage on email as well. Jeff: Nice. Awesome. Going to old school. I love it. Well thank you so much Jeremy, for joining. , I think there's some things I wanna talk to you about down the line, so maybe we have it back on in a few months. We see how things are going, but appreciate this, this was a blast. I, I love getting into it. So thank you so much for coming on. Jeremy: Thank you and it's, it was better than broccoli. Jeff: It's a high compliment. Thank you so much. Have a good one. Jeremy: Bye.