The Craft of Product Development + The Product Mindset w/ Scott Varho, SVP of Tech at 3Pillar Global

Hey everybody, this is Mike Belsito and I'm the co-founder of Product Collective and we are back for another industry interview. So thank you very much for joining. I hit the broadcast button about a minute before 1 to let people sort of filter in here, but I figured I have sort of housekeeping to go over first, couple minutes of that, and so we could do that, get that out of the way before we get to the meat of why we're all here. So, um, I wanted to first welcome you. If this is your first industry interview, thank you so much for taking part in this. Industry interviews are a part of what we do at Product Collective. So Product Collective, for those that aren't familiar, maybe you just saw the webinar link and registered and thought, hey, I'll turn up, this is awesome, this looks like it'll be an awesome conversation. Um, Product Collective is a community for product people. So we got started back in 2015 and And by community, I mean, you know, we do a whole lot of things for product people, sort of help educate product people. You know, when people ask us why we do what we do, we say, hey, it's to answer the question that we were asking ourselves way back when, you know, am I, am I doing this right? So everything we do, you know, we're trying to help product people, whether it be these industry interviews where we do two of these every month, usually on the first and third Wednesday of every month. We also do a newsletter every single week. We have about 20,000 people that receive that newsletter and every week it's a different topic. So, you know, one week might be on product marketing, the next week it might be on finding product market fit. There's all different topics that are relevant to us as product people, right? So every week we focus on something different. So there's that. And then we also have a Slack community that's very active. There's about, I think at this point, 7,000 people in the Slack community. So every day, you know, trading ideas, best practices. So if you want to access all of that, it— those things are all free. You just go to productcollective.com, you could register, and, and then you'll start getting invitations for these video chats. You'll start getting the newsletter. And if you wanted to meet us in person, we get together in person twice every year, once in Cleveland, Ohio in the fall for Industry, the product conference. That's sort of the, the one in the, in Cleveland is sort of our flagship conference. We'll have This year, probably we're getting close to 1,500 people that we'll have. Last year they came from 37 states and, and 10 countries. Um, last, uh, or I should say, this will be our 6th edition. But in March, in 2 months from now, we will be in Dublin, Ireland for the European edition of Industry. So I'm really excited for that. This is the 3rd time we'll be back in Dublin for Industry Europe. And, uh, and you could learn more about those conferences at industryconference.com. And when I follow up in an email, I'll send you a little bit more information about that. So that's what we do at Product Collective. If this is your first industry interview, just a couple things about these. We do these with product leaders from all over the world. We love having these conversations. You'll notice at the bottom of the screen there's a chat, and then there's also a Q&A. Some of you are already joining the chat, and that's great. You're doing exactly what I was about to ask you, which is You know, let us know where you're from, maybe what product you're working on. It's fun to see people from all over, you know, just looking at the chat here with people from Central Wisconsin, Minneapolis, Minnesota, Fargo, North Dakota, Sioux Falls, South Dakota. So we have North and South Dakota here, Orange County, people coming from all over. So thank you for joining us. I'm in Cleveland, Ohio, as I usually am, and, and the sun's out today. So it might be a little chilly, but at least the sun is out. But my guest is actually from the DC area, nearby the DC area, and that's Scott from 3Pillar. Scott, thank you so much for joining.

Thank you for having me. I'm excited to be here.

I'm excited for having you. And, um, I know we, you know, I've been familiar with the team at 3Pillar for quite some time. You know, we've had folks from 3Pillar, um, at the conference at Industry, actually, you know, you know, involved. We had, we have these Talk Shop sort of interview sessions. I know Three Pillar was involved with that a while back and have had, you know, you and other folks involved with these industry interviews as well. And so anyway, I'm excited. I know there is a book that recently came out which y'all were involved with. Maybe you could let us know about that. And then I definitely have questions for you. Actually, I do want to let everybody know if you have questions for our guests, there's a Q&A section too. Feel free at any time, put questions in that Q&A section. I'll be looking at that throughout, um, especially towards the end of our conversation. I'll be pulling a lot of questions from there. So if you have questions for the guests, use the Q&A section. But, um, yeah, maybe you could, maybe you could just let us know a little bit more about the product mindset, and that'll be a good segue into our conversation here.

Absolutely. So as you mentioned, uh, we actually released the book on this, but this has been really a cultural component of 3Pillar since its roots. And if you read the book, you'll, you'll hear David telling the origin story of 3Pillar very much through the product mindset. You know, the product— what is the product mindset in a nutshell? And I definitely recommend checking out the book because it provides a lot more layers and texture. It is a mindset. And so I think much, much like Agile, for those of us who are— who have become avid Agilists, It's as much a set of value system and a set of principles that guide us through how to build together well, how to collaborate. Product mindset is what I feel was missing from my career. I was a product manager, then I was leading product teams, and now I'm leading engineering products, UX, DevOps, all the crafts that build products here at 3Pillar. And my younger self really would have benefited from the product mindset in that The product mindset really is an approach that teams can take to what it is that they're building together and why. So it starts with a really deep focus on the business outcomes that the team is aiming to accomplish, which does two things for teams and makes them more cohesive and more high-performing, which is, you know, Agile doesn't tell us very much about how to prioritize. We've all had to, you know, those of us who've been sat in that seat know that there's as much art and instinct as science to, you know, what should be the next thing out at the top of the backlog. Sometimes we're, you know, trying to assuage angry stakeholders. Sometimes we're working on actually the most important business thing. Sometimes we're trying to clear a dependency, right? There's not a clear— Agile doesn't have a lot to say. It just says work on the next most important thing, right? So I feel the product mindset, one of the things that I've seen it do for our teams at 3Pillar repeatedly and help them become high-performing is it aligns all the teams are ultimately multidisciplinary. You've got QA people, you've got front end, you've got back end, you've got maybe an architect, you've got QA. Each of those individuals in their practice and their view on the product means that they have a different set of things they think should be at the top of the backlog. The product mindset says, I see all that, and yet the business outcome we're trying to do is this. So, so how do we marry the two? Which provides a level of clarity and cohesion in the prioritization. And, and I, I just can't, you know, under or overstate, I think, how important that is to producing high-performing teams. Because at the end of the day, how we integrate our functions and as humans is really where the high performance comes from. And our level of commitment to one another, the level of integration of those teams produces— it sets the stage to build great products together. And so that, that's in a nutshell, that's what the product mindset is. The book goes on to talk about ways in which product is different from other types of technology work that, that really sort of sets the stage for why a product mindset is particularly important for this type of work. When we're trying to— when you're trying to unlock revenue and growth and so forth, you're on a journey of discovery. It's not, I have a business process and if I automate it, I expect a 10% gain in efficiency. So I'm going to do a 10-person team because I know the ROI and my payback period is— products aren't like that, right? Products are journeys. We're trying to unlock what delights the user, what delights the payer, which is not, you know, in B2B markets in particular, they aren't the same thing. What delights our channel partners, right? So it's a complex landscape that you're entering there. It's— we have a notion, we have a hypothesis. And we have a, we have a team and that's, that really makes being clear about your business outcomes really important because you can unlock creativity, new ideas, fresh thinking. Yeah. So I think, I think in a nutshell, that's, that's what the Product Mindset is all about.

Yeah, that's great. Let me ask you, so when it comes to putting that into practice, I imagine some people, you know, you're, maybe they read the book or they're going to listen to this talk and they're thinking, well, this makes a lot of sense, but what do we do with this? And I'm curious, like, when people do put, put these principles into practice, like, what is the right way to do it and what, what often goes wrong? Like, what are mistakes that people might make along the way so we might be able to look out for those?

Yeah, so, you know, um, I think a good way to, to, to approach this is, you know, the younger version of myself really felt like I was responsible for for the product, for the vision of the product, and for leading the team through that. And while that was true, some of my greatest moments building products came when folks deep in the trenches came to me and said, you know, Scott, I've been thinking about what you've been talking about and I'm watching the work and, you know, I have some ideas or I have some thoughts. Or, you know, a great example is I had a, you know, a QA lead come to me once and be and say, look, I'm going to pass this ticket, but I don't think that we're doing the spirit of what you were trying to accomplish when you talked about this at release planning. I don't think that's what this is accomplishing. And let me tell you why. And, you know, one of two things would happen in those cases. I'd either get a chance to clarify why this is aligned with the spirit of where I want to go, or I get this wonderful aha moment like, oh my gosh, you're right. The letter of the user story got met, but the spirit of the objective got lost. And How do I— and then I can restore that. And so, you know, just really engage craftspeople. You know, we will build better together. You know, my requirements, I used to always say the stuff that I write, 20% of it is wrong. It's up to the team to help me find the 20%. If I knew which 20% it was, I would have already, like, you know, exercised it from the backlog. But, you know, they can— the teams, high-performing teams that are applying their crafts can make products better. And I think as product owners and as product managers with all the accountability and the tensions that we're managing from the business side, we can, we can feel like, you know, we need to be clear with the team and tell the team what to do when really what we should be doing is sharing context and bringing them into the problem that we're trying to solve so that we can bring the best out of them as well. At the end of the day, we have to disagree and commit. That's, that's part of sprint planning. That's part of the roadmap process, right? But, but I do think that in the end you get better outcomes when you, when you can set the table and say, this is what we're trying to do. These are our resources and constraints. Now we get to fill in the middle. Here's my hypothesis. Come join me, make that better. You know, whether it's UX, which is going to help me figure out customer delight, you know, what, what, what is important to our customers? What, which buttons on the screen are particularly sensitive to them? Like, you know, where you need that, are you sure moment? Those are, those are many insights that are really important to executing authentically on a vision. While as a product person, you should be focused on the commercial go-to-market. How do we talk about our product? How do we position it? Who are our partners? Where are those features that sell really well to the buyer? They may not matter as much to the user. And how do you navigate that? And how do you find as many opportunities for, for two-fers where you can satisfy both, both parties with one set of development? You know, so there's lots of room here for good craftspeople to be able to join your journey and fill in the parts of your, your vision that, that frankly aren't your specialty. And so I think that that's the mistake that I made as a young product owner, feeling like that was all up to me. I needed to be brilliant. I needed to be able to do the database design, and I needed to be able to do all these things better than everybody on my team. And ultimately, I would have been better served by a more open invitation model.

I'm sure I've made that mistake too, and I've made a lot of mistakes when it comes to being a product person, but, but it's definitely a common one. So, you know, I don't think you're, uh, I don't think you're alone in that. Um, you know, I was curious, and actually, first, before I even ask this next question, just another reminder, everybody. I saw one question come in, and I'm gonna, uh, address questions in just a little bit. I have a few more for Scott. Keep those questions coming in the Q&A section. I would love to address as many of your questions as I can. And once there's a bunch of questions there, you could vote on questions, you know, so I can make sure I'm asking Scott the questions that you all want to hear. So definitely do that in the Q&A section. But the one question I want to ask you is, you know, in the description of this session, you know, when we were planning this, you know, there was a line about how oftentimes details get overlooked. And, you know, I was curious about, from your perspective and, and going through, you know, as you and your colleagues all research, you know, for the product mindset, what details do you often see that get overlooked and why do you think we overlook those details as product people?

Well, and it's, I think that last part for as product people is really important because I think each craft has its blind spots. You know, when it's backend engineering, I would say we often forget that our frontend has to consume it. And we don't design our APIs to be easily understood by people who didn't build them. You know, for example, we don't think about the customer experience in that case. You know, just to, just to pick a case. As product people, I think one of the situations that I see that, that really can drive me crazy because it's such a missed opportunity is when we don't internalize the importance of what I'll call scaffolding. And so this is a great example of a place where, gosh, if I'd known what I know now, then I would have operated so differently and I would have been so much more successful building products than I am, than I was, which is, which is for product owners and product managers to really appreciate the value. I'll give you a metaphor that, or an actual story. This happened to me. I was building a shack in Costa Rica on a buddy of mine's. He bought a piece of land down there and asked me to come down and and help him build this shack. So he had a place to throw his surfboards while he wasn't there. He wound up recruiting somehow 4 construction guys that were visiting from Newfoundland to come and help us roof it, to put a roof on this thing. It's a hilarious story. It can only be true because I couldn't make this up. These 4 guys spent, you know, they only had 4 hours till they had to leave. They're like, look, we'll give you 4 hours of our time, you know, we'll give up surfing and come do this for a case of beer. And they spent the first hour and a half of the 4 hours just putting scaffolding up. And it was, it was so insightful to me. I was like, wow, like the scaffolding allowed them then to crank. I mean, the way that they worked after that, the way they laid roof, they roofed half the house in the remaining 2 and a half hours. And it just made me really appreciate the scaffolding. The corollary for us is DevOps, code pipeline automation, you know, environments, our coding standards, our branch strategy, right? These are the things that are the scaffolding of teams that are building products. And as a product manager, a lot of times we can say, oh gosh, you guys have gone all technical and this is not stuff I care about. Remember, we have features to build, right? And I've seen teams work that way. And it's like, yeah, that's real important. But, but if you, if you forget about our ability to, to the scaffolding you'll lose sight of what I call the throughput myopia. Agility, ironically enough, calls it velocity when we're really talking about capacity, right? Like when every, you know, velocity in agile terms is really how many story points can a team do over an increment of time, which is capacity. Velocity would be cycle time. How long does it take an engineer to go from, you know, picking up a user story to be able to merge code into the branch or even deploy it to production? Depending on how you want to measure it. And that's, that's true velocity, which also then from a business perspective, now I have the tools with product mindset to be able to articulate, like, in the digital economy, you're— one of your greatest competitive advantages is to be able to react to new information quickly. If I know I have a defect in production and the fix takes my engineer half an hour, how long before the customer gets the benefit from that half an hour of investment? And a lot of companies, the answer is months, because the set of things that you have to go through so that we have a predictable release that we all believe is okay, we're safe, we can press go, right? So those investments in CodePipeline automation, merge, security, dynamic and static automated testing for security vulnerabilities, right? All of those things increase our confidence on pressing go on dev work that's done and then getting value back into the hands of users. In the digital economy, that kind of velocity is really meaningful. So, you know, I think, you know, I said a lot there, but what it comes down to is the craft of building and understanding the scaffolding that makes us move fast. That feeling of speed that we made a decision in the boardroom and we see code in production within a matter of weeks or days or minutes. That's real speed. And that's not capacity. That's cycle time. So I really would love to see us as product owners really take that seriously and support engineers as they try to figure out how to make the right investments to achieve that, because it is a business game.

Yeah, I love that. I love thinking about velocity as not— because I've definitely been in situations where, you know, velocity was a metric, but it was just really measuring like how fast we're doing stuff. But it's like, well, are we doing the right things? And are those things actually helping our customers? Like that, that there weren't metrics for that, right? But we were fast, right? So I like thinking about it maybe a little bit differently than how oftentimes velocity is thought of. So thank you for bringing it up like that. One of the things I wanted to ask you is, you know, part of the product mindset, right? It's these, these principles that we can live by, but we have to put them into practice. And what I'm curious about is when we do start to put things into practice, and that might translate into building a new feature or, or, you know, building a new product, um, how much, how much sort of information do we need before we can act on something? You know, so we might do customer research, but it's like, how much customer research? I'm curious if the product mindset, you know, like the framework sort of covers this and, or just what your take on that is.

Yeah. So, I mean, one of the things I think is— so yeah, how much is enough is a great question. And certainly there's, there's a lot of research about if you do truly randomized, you know, user research, then you can actually do a lot with a small end size. So, so I'll leave that to the UX research experts to talk about, which, which we have, we have here and And the end size is surprisingly small, that you can actually glean a lot of insight from a small batch. The one thing that I will say though, that I think is so important is that the real competitive advantage is just not technology anymore. You know, and it's interesting to say this, but I've been proven out on this so many times. Like there's always new shiny objects in technology. Today it's, you know, blockchain, IoT, it's AI and cloud. But the fact is, is that no matter which technology hurdle we cross and which, which thing we're able to do new, what new tool we put in the box, everyone else has that tool too. And so the lead is not in technology. The real lead that I feel and really tried to work on unlocking is insight about the customer. If you, if you can understand your users, their behaviors better than your competitors, they can, they can copy your features. But if they don't understand why, they'll always be copying your features. And even better, they'll copy them wrong. They'll miss the nuance, the psychological insight, the mind mapping that you can gain from good UX research is really potent. And I feel like that's, that's the real competitive edge that is non-replicable unless they steal your people. So, you know, treat your people well. But, but that— so, so I don't— so the question, the direct question you asked around how— sorry about that— about how much research to do before you act. You just have to have enough to have confidence in it to find that insight actionable. And so that, and that's tricky for people, right? That we're always, you're always working with a smaller end size. And, you know, there's, there's, I mean, having navigated the space enough, there's always a reason why someone's going to say, why don't you do a little more research? But, but I think as a product owner, you always have the chance to get that information into your teams and take, you can even take micro bets. You know, okay, well, if this were true, what would also be true? And can we run micro experiments that don't— these aren't big roadmap changes necessarily. You know, like, it isn't always at the level of are we inventing a new business or product line. It can be at the feature level, like, I really think our users will appreciate, you know, co-locating this information, that there will be an efficiency gain there. And there's micro experiments that you can do with that kind of stuff. And sort of prove it out. And I think those are, those are empowering concepts because then the team can say, I realize our stakeholders don't believe it, but I do. And this is what we're going to do about it.

Great. No, I appreciate that. I want to take a couple audience questions now. So actually, if y'all have more questions for Scott, keep them coming in. I mean, I think we'll have time for, you know, a good couple few questions here. One of the questions was, you know, and this is specifically for an engineering team that maybe they just want to build. They like building, they're set on building. So the question is, how do you get that engineering team or other technical teams to allow the time for the scaffolding, as you put it, Scott? And again, in this case, they said, hey, our engineering team might not have much patience for the planning, they just like to do. So how do we encourage our team members on the technical side to put in that planning work?

So it's interesting. I would— I actually think those should be two different things because there's the planning work, which is, you know, sort of talking about what are the right things to build. And there's a scaffolding work, which is what's the right way to build, right? And typically the question that I'll— the kind of a remix of this question would be, you know, well, isn't building scaffolding just like investing in the engineer lifestyle? It makes it easier for them. It's a— you know, we're going to let engineers clean their desk kind of, kind of concept. And the fact is, is no, like actually much like construction, you can't build, you know, impressive buildings without some scaffolding. And so you do need it. But getting engineering to, to, or engineers to be interested in the work to be done and to really inform and engage the, the messy middle, right? Like, you know, here's business outcome and here's constraints. What do we want to do about it? And to invite them to that party. You know, the, the, the— I definitely find that different engineers present differently in terms of their willingness to go into the white space. A lot of them want like, hey, you, if you give me clear requirements, I'll get you quality code. That's how this works, right? There's a certain amount of engineers that, that approach it that way. Um, the— but I have found that when I step back and I present the challenge before I start talking about what I think our answer to the challenge is going to be, and I provide that uncomfortable pause, there's a certain subset of engineers that will step forward and be like, have we thought about this? And what about that? And that curiosity and that courage to step in there, it does require courage. Engineers are not necessarily all, you know, the business leaders that just haven't gotten there yet, right? They're like, no, they came to engineer. But I have found that if you leave that uncomfortable space, some of them will self-present. People who want to, want to, they just, they just want to do more. I believe engineers, at the end of the day, they want to impact something bigger than themselves. And so if you create that space, you create that invitation, you'll get some interesting creativity and, and be surprised. And that's, that's kind of what happened to me, is certain courageous people throughout my career stepped forward and said, I heard you talking and I just couldn't help but think about this. And I'm not sure what to do with this notion, but I have this idea, and really big stuff came out of those moments. And so then I started practicing shutting up, quite frankly.

Well, I have another question that came in, and it's a good one. It's, you know, at what point do you stop something that isn't right? You know, is there such a thing as stopping too late? You know, maybe we made the call, we're going to move forward with this, but then we get we get some information that tells us otherwise later on in the process, but we're already in that process. So what— and I don't know if that's a part of the product mindset, but just maybe you could give your take on that.

Yeah, and the product mindset doesn't say as much about this, but I'm a firm believer and, and, and think that as product folks, we have to take the courageous decision. We— one of the things that I've always preached to my teams, and I do here as well, is, you know, what we do is expensive. We have to— the the more we show the business that we take the level of investment they're making in us in order to make that investment in the product, right? We're a proxy. You know, the more seriously we take that, the more we represent that we take that very seriously, the more we earn their trust. And so when we feel like something's off-kilter, and at a micro level, we know this to be true, a user story can be totally— the ROI could be totally compelling at a user story size of 1 point. But at 21 points, there's no way I would ever have invested in it. And there's— we all have story. We can— I'm sure we could share plenty of stories of the 1-point story that became the 21-point story. It happens plenty of times. And so constantly reevaluating ROI. Like when we set out on this journey, we thought this was fairly simple. It's turned out to be a hornet's nest. It doesn't feel right. And this is where I think you have to let your instincts also guide you. I don't think the business wanted this so badly that the ROI is sufficient for this. I think we need to pause, pull back, show our responsibility. Every minute we spend on this as a unit is a lot of money. I mean, the fact is, any team of any size, it costs a lot of money to do what we do. And so I think taking that seriously, I think you pull the plug as soon as you feel, I just— this doesn't feel right. And I think we need to pause and take that seriously. So I, I think that courage— it takes courage to do that. Someone was obviously a stakeholder that was behind doing that, and so I definitely don't say that lightly, but I think it's, it's a really important part of the role.

Yeah, it takes a lot of courage to do something like that, but, but we're product people. We're definitely not here because we're, we're thin-skinned, right?

Hopefully.

Um, you know, I want to— we're getting close to the end of our session. I want to take one more audience question, and then I have just sort of a last parting sort of question to sort of leave for everybody too. But the audience, this is actually a combination of a couple that came in the chat. You know, earlier in the chat, somebody had brought up the concept of product ops, which is kind of a hot thing right now, or at least it seems to be. And then somebody also asked about DevOps and what it means to you in the product mindset. So I'm curious about things like DevOps, product ops, how do you see that sort of fitting in when it comes to the product mindset?

Yeah, totally. So, and gosh, the number of times I've had CEOs at— because all of my career has been at product companies and CEOs have pressured me to do something organizationally around ops versus build and innovation versus ops, which I'm like, there's a lot to not like about that separation. But, but here's the underbelly of all of everything that I'm talking about, which is a rich integration. The richer the integration, the more authentic the integration of all the crafts that it takes to produce and maintain great products and serve clients and serve stakeholders and serve channel partners, right? Like we have to— the product needs to be— it's an integrated ecosystem that's satisfying the needs of a lot of different people. And then on the build side, integrating the build process, the operationalization, customer success, right? There's a lot there. The more integrated, the better. So my view on all of this is separation is fine where you need it, because you just have to have specialization and capacity management, but integration. If it's not integrated, it's not going to give you the benefit. And the DevOps— obviously, the root of DevOps was dev teams should own the operational impacts of their products. We should reintegrate that back into teams. That was the original notion of DevOps. Now, DevOps is a proxy for CodePipeline automation. And tooling, which is interesting that that little sleight of hand happens somewhere in there. But as long as it leads to integration, fully integrating and getting your teams humming, your stakeholders working together, we all share the absolute— we should share the same objectives. If we don't, that's really the place, I think, to focus organizationally. But so I don't have any specific org structure that I think works. I think at the end of the day, you have to figure that out based on where you're experiencing the challenges. I've worked in a lot of different contexts and a lot of different types of products where we have to stretch and bend and where things start to fall apart or different. So you figure that out. But the thing that I've always been really, really hawkish about is integration. If you get integrated structures, you'll get great results at scale. And that's— that would be the meta piece that I wouldn't lose sight of.

No, I appreciate that. Well, we're already at the end of our time here. 30 minutes went by pretty quick. Maybe as a, as a sort of a final takeaway, if you could share just like what is that one thing you hope everybody could take out of this session? And, and knowing there are actually a few questions that I didn't have time to address, if you could also just let people know, you know, maybe where to keep tabs on you, your work, the product mindset, um, all of that.

Yeah, so I, I do, I do think the product mindset is a really important tool. Um, it can be used in a variety of teams. Again, I think you'll start to see that integration concept. So definitely recommend checking out the book. We just launched that this, it was in the autumn this year, fall this year. So that's out there now. You can benefit from it, it's a quick read. And then we do a lot of work, 3Pillar Global, we do a lot, put a lot out on LinkedIn if you're interested in following us. And so that's a good place to keep tabs on what's going on with us.

Awesome. Well, Scott, I really appreciate you making time for this. So thanks a lot for joining us.

Thank you. I appreciate you, uh, you having me. This is a fun topic.

Absolutely. And, and thank you all for being a part of this too. I appreciate you making time out of your day for this. Um, again, I'll send you an email later on with the recording for this. Um, also some links that Scott and his team sent me that I think might be helpful as well, uh, as well as info on Industry and Product Collective. So keep an eye out for that. And, and you could join us for a future industry interview too. We've got 3 coming up that are planned with April Dunford, who was top-rated speaker last year at Industry, and she'll be speaking at Industry Europe. Hubert Pallin, who's the CEO of Productboard. And also, we just— we haven't even really announced it yet, but it just went live today— there'll be one with Heaton Shaw. So we're excited to have Heaton with us as well. So keep an eye out for that. And until next time, I'll see y'all later.