Leading Product: The Sparks, the Challenges, and the Victories, with Alexandra Lung

Episode 149 · 38:34 · SRT · archive.org · all Tanzu Talk

Well, this is another one of our series of kind of previewing talks we're having at SpringOne Platform down there in my hometown of Austin, Texas, pretty soon here. And I have half of one of the speakers, so to speak, on today for a talk that will have two speakers. But why don't you introduce yourself and tell us a little bit about what you'll be speaking on. Yes. Hello, everyone. I'm Alexandra Lung, and I work as a senior product manager in the Pivotal Labs Paris office. So what I do on a day-to-day basis here at Labs in Paris is that I work with different clients from various industries, and we help them build better products by coaching them to new methodologies as lean, agile, user-centered design, and new ways of collaboration as a team. And I remember looking over your proposal. I think it's in the leadership track, right? Yeah. Right. Well, so I'm one of the people who reviews for that. And I remember, and I think at some point, anyways, I forget how it came about. But I remember looking over and thinking, this is perfect, because it's about two very, well, I wouldn't say very, two usually obscure topics. One, like what leadership is, and the world of managing that area of sort of like, let's make sure our software does something useful, like on the product area. But then also the area of product management, which I think, obviously, for someone like yourself is, and people who work in software vendors and some other people is sort of obvious. But I find that in the, let's call it enterprise space, I don't know what you see, but there's not always a lot of product managers. Like, it doesn't seem like a overly common role. But I guess that's, that's the first thing to ask is like, do product managers show up a lot in non-tech enterprises in your experience? Hmm, wow, great question.

Actually, I think, it's really, really interesting. And this is actually one of the reasons I, I wanted to give this talk at SpringOne Platform as well, for the fact that we talk a lot about product management and product management, the project product management role is more and more kind of out there. Like when you search on LinkedIn, you get a lot, a lot of hits, but it's still a little bit unclear on what a PM should do. Like, and also, there are a lot of mixes, like, are you a PM, a product manager, a product owner, a project manager? Like, in some cases, they even ask for the product manager to do some design, to do some whole tangent marketing. I mean, it's, it's still a little bit blurry. And I think a lot of times, it's still misunderstood. Like, for example, I coach a few people in PM roles in different organizations. And I still get this question in my first sessions, you know, where, where the, where the person I'm mentoring and coaching asks me, oh, can you tell me all this, like, a list of skills or stuff I need to know in order to do? Right. And actually, I'm like, I'm sorry, but there's no perfect recipe. Like, it depends a lot on the industry, on the product, on company, on the market, like, on so many things. Yeah, yeah. No, I, it is, and in a related area of, like, the many definitions and faces of, of, I don't know, enterprise product management. I was talking with someone just yesterday, and they were saying, you know, for better or worse, usually for worse, sometimes when they're in a large organization, and they meet, like, a scrum manager, they sort of become a de facto product manager. You know, which is usually not what a scrum master should be doing in totality, but I guess, I guess by, well, for two reasons. One, they're available. It's a person who can do the work. And, and, and two, you know, I think a lot of what a scrum master or an agile coach or whatever would do would help you kind of come up with the features or the stories you were going to do and kind of help, like, prioritize the backlog and do some of the things that sometimes product managers do.

But it was, it's kind of to your point of, like, this role tends to be sharded out amongst many different. Yeah, and, like, even for me, actually, as you're asking of, like, non, non, maybe non-software products, like, actually, I started working as a PM in software while I was working at a company that wasn't doing software at the time, and I was a product manager, but mostly, like, product marketing manager. Ah, right. People wanted to start being a software company, so they're like, okay, we're going to start this amazing new software product, and we need a product manager. How about you do it? This is how I kind of started, and it's funny because it is very different depending on the product and if it's software or not. Like, you do have some mechanics it can be like, but it is very different, and it does take quite a few specific skills and some experience in understanding the mechanics and really leading the product. Because for me, like, what's really similar between all these jobs and when you have a PM is that the PM is the one who leads the product. And you were talking about leadership at the beginning, and it's really interesting because, you know, as a PM, you are not the boss of the team. So, you're not the person that is actually, like, you can't be there, like, oh, you do that, you do that, and then, like, give me a report at the end of the day. It's, like, silly. So, you really need to find a way of leading the product and attain towards success, but without this really official authority. Yeah, and, you know, maybe as a way to kind of, like, continue to feel ourself around not only what a product manager does, but how they go about doing it. Like, as you were saying, you're not necessarily in the role to tell people what to do. And given that lack of, like, command and control, I guess, like, what is, what's, like, the outcome that a product manager is going for?

Like, what's the goal they're trying to arrive at? And then, as a part of that, I mean, because the answer is always it depends. Like, how do you figure out what those goals are you're trying to achieve? Well, I do think that as a product manager, you always want to build a product that is really relevant for the users and that makes the business grow, like, whatever industry you're in. But I think another important, like, outcome that you want to have and that would really help you be successful is really the team and the collaboration. Like, really, the people. You know, as I was saying, you can't go there and be like, oh, you do that. And it does happen like this in some companies. It's not a, sometimes it's a PM. Sometimes it's a CEO that goes and tells the team, look, you have this list of features. You have three months. Do it. But that's, like, we all know that that doesn't get us to have a good product. And eventually, it will also lead to no team because that's so not motivating. So, for me, a very important part of the job of the PM is also, while leading the product to inspire the team and to really empower the team through really, really good collaboration. It's like, for example, what we do a lot at Pivotal and what we get more and more into our clients' mindset as well is to work with small teams that collaborate very, very closely. Like, usually, you will have a product manager, product designers, and engineers. And they will have all the autonomy to take different decisions in building the product. And everyone will really have its say. And as a PM, I always make sure to include the different members of the team, you know, in all the different activities. For example, when we build our roadmap, I won't be there with one stakeholder and be like, okay, what should we pick and choose?

I will have in that workshop, there will be designers that can advocate really for what we heard from the user. And we will have engineers as well, and they can advocate for the technical feasibility or for different things that they have heard during user interviews or from business. And that makes it really interesting as the team is really building the product together. And our different views are really enriching the path to our product success. And so, I've got all sorts of follow-up questions based on that. And to sort of facilitate that, like, do you have, like, an example of, like, an application or a product you're either working on or working on the past that we can kind of use as an example of those points? Yeah, I think a great example is one that I'm going to mention more in depth at SpringOne Platform as well is a project we've done with Orange here in France. And I think, yeah, for Orange, we did reach to implement all these different aspects. Like, I think as all big organizations, you have, you usually have a lot of teams, a lot of, sometimes multiple layers into decision making. And actually, we got really, really great leaders from Orange that wanted to try this new way of working with small teams that are really, like, empowered to make different decisions. So, what we implemented with them was, like, really small, what we call balanced teams. And we, like, we went doing everything together. We started with listening to the user, doing some user research, gathering more and more data, and then building together a roadmap and started iterating in a very lean way. We wanted to do risk very early, so we were building really small pieces of software, testing them, and then going iteratively more and more into releasing more and more software.

And actually, it worked really, really well for them, not only on this project, but they, actually, the person I'm going to speak with at the conference at S1P is a product manager for Orange that worked with me on this project. And now, she is implementing the same methods of work and same product mindsets that we have here at Labs within another team in Orange. So, it's really cool to see how they can actually scaling, starting from what we did together here. So, she's doing the itinerant product management thing where, you know, you establish and learn how to do something on one project and help the other people. And then, you sort of rotate to another one to spread the new way of doing things. Yeah, and it's really great to see how well it works for them in that project and, like, how it works really well on, like, new projects as well in the same organization. So, what, like, what did the product do? Like, I mean, however detailed you can or can't get, like, what was it? The project was on the online assistance. Actually, we were rebuilding the whole online assistance for Orange here in France. And it was actually a pretty, a very interesting project because there were, like, as an old big company that has a lot of products, a lot of customers, there was, like, so much information, right? And we were trying to help customers get an answer to their questions. But you can imagine how wide the questions would be for a very, very big company. So, the interesting part is that we started, as we usually do, and we wanted to hear the users. So, we went, and we started doing some user interviews.

And so, we would put a user in a room with us here in our office, and we would ask them, okay, so imagine that you have a problem with your operator. What would you do? You have this big problem. What do you do? And they were, like, I would call, but we were trying to digitalize the whole experience more and more and make this experience better. So, we would be, like, okay, but imagine if you cannot call. What would you do? So, actually, the persons were trying to give, the users were trying to give us some answers. But what we saw is that it was very, very hypothetical. In this case, it was really hard on a sunny afternoon, drinking a nice coffee, to imagine that you have this big problem. And if you don't solve it, your boss is going to fire you. And it would be even more difficult to imagine that you wouldn't do what you usually do, which was calling. So, it was really interesting for us to see that, in this case, we couldn't use the user interviews. Like, in a lot of projects I worked on, especially here at Google Labs, it works wonders. Like, you see the users, we really have really gifted product designers that know how to ask these questions, really unveil the different problems and pains and opportunities for our users. But in this case, it simply didn't work. And so, we were like, okay, so we can't gather, for now, information directly from the user. And we need to work with data, but we had absolutely no data. So, in this case, we decided that we have to build our own data. So, we started implementing some data workshops in the team, within the balance team, to start figuring out what data we need to start gathering and how we can run very quick experiments in order to start having this data.

Like, for example, we added, we added a search engine. Even if it wasn't, like, a working, very well-working search engine, we really spent a minimum amount of time. But we wanted to know what people were looking for so that we can prioritize what information we should display first. Because imagine you have, like, 10,000 topics. You cannot simply start with everything. So, we really figured out our way, little by little, and we will give more examples and more details about this in the conference, of how to build your data in a case where you cannot grab it directly from user research, and when the company doesn't have the data initially. Yeah, that's interesting, because it is, I mean, tell me if I'm thinking about it wrong, but it does, it seems like one of the roles, and, of course, you want the whole team to be responsible and have ownership, but one of the things a PM might be concerned with is, like, we don't really know what we're doing here, right? Like, and the usual tool we would have, like you were saying, is we could interview people and ask them what they want, but, as you say, when they're having coffee and things are good, they don't sometimes really even know how they would go about doing things or what their problems are or things like that. So, then, I would imagine at some point, like, you or, you know, your pair there, if you will, had to sort of figure out, like, all right, we need to figure something out here, right? Like, we can't just make assumptions about what we're doing. We don't really have that good of an idea, or as good an idea we would like, so let's, as a team, let's come up with ways to actually fix that and gather that information. Yeah, that's exactly, that's exactly what happened for us. And then, and then, so, so with that example, this, I'll go back to one of the questions I had before getting the example, which, it's another one of these, like, basic examples, but I think it's, it's instructive to talk about a little bit, because it, it, it explains a lot of what we take for granted, and then, therefore, the advice that we give when people seek to improve their software.

And, like, so why, why is it important for teams to be kind of, like, autonomous, rather than told what to do? Wow, thank you for the question. Well, I think there are multiple reasons. One of the things is also that the team and the team members are the ones that are really in contact with the users. They will really hear different, the different information from the user. Also, the team, like, for example, I'm thinking now about the engineers, really know the tech stuff in and out and pretty in detail. And we also have, for example, the PM discussing with stakeholders and leaders, we have knowledge about what's important for the business. So, the team really has all the knowledge and the skills to, to take the decisions that are, that are relevant for the product, and that will benefit both the business and the user. Another, another important aspect is also team motivation and, and team, you know, empowerment. I've been in companies where we were told what to do. And, yeah, the teams would do it, because it was their job, like, it's right. But here, when, for example, as an engineer, if you go and hear the user in an, in one interview, I mean, I'm not saying like a whole team needs to, needs to be there for all the activities, but you hear them out, you hear their, their pain. And you, so when you actually build that feature, you know why you're doing it. You know that you're really going to help someone with that. You know that, that there is really a meaning. It's something very, very meaningful that you are, that you're building. And it's like so much motivating to know really the why. Yeah. Of why you're doing it. And especially also when you can really work as a team and you have this great collaboration, you really feel that you're going all together in the same, in the same direction.

And I think, you know, all human beings, we want to be part of something bigger. We want to be part of something positive. And while you're in the middle of all that and you know why you're building it and you can also take the decisions in order to build it. It just creates a kind of magic in the team that leads us to really great products. Yeah. Yeah. I mean, that, that, you know, obviously it's sort of a leading question. Why autonomy is important, but I think, you know, you know, to, to sort of like highlight some of the things you were saying. And when, when I think about the why autonomous is question, you know, the question, like, like, like, it seems like there's two things. And again, tell me if, if, if you see this one, no one person can know or do everything. So you, you have to have, as you were saying, right. Like the developers or engineers, like they know what is technologically viable in kind of the constraints that you have. Right. So, you know, as a, as a, as a product manager, you couldn't tell them to like, you know, invent real artificial intelligence that just to use an absurd example as, but especially when it comes to, you know, helping people look up customer support things. Like there's just limits to what, what you can do despite what happens in movies. And I don't know, maybe there's some super PM somewhere who could do all that and program. They just, they just, but probably not. Right. And, and then similarly, like all the roles like that, uh, like you just don't have those skills there. And I think, and then at the end, I mean, you were hitting on something that I think happens. I don't know. I mean, it'd be interesting to know how you quantify and convince, let's say upper management, you will, if you will, of these things. But like, I think, I think in someone in a role like yourself and then someone like me, who's lucky to talk to people who actually work on software, like if they're happy, they usually do their software better.

Right. And if they have, as you were saying, they have that sense of like fulfillment and doing things, but it's almost like, it's kind of hard to convince people of that. And having, having, allowing people to be autonomous, like really feeds into happiness, right? That they're not just, uh, gears in the factory. Yeah, definitely. But, uh, there's another point, uh, to this as well. It's like, I'm talking about teams that work in autonomy, but not in isolation. I mean, it's very important to, to know, and this, this is a lot of PM's job as well, is that you, you need to communicate a lot with your stakeholders. Like they, for example, every product comes with a vision, right? And this vision is usually defined with upper management, with, with leaders in the company. And it needs to, to, to, it will, it will be coherent and it will feed into the bigger vision of the company. So your leaders help you build this vision. And then while deciding, um, how to get to this vision and getting more into the implementation part, the leaders are, are still there next to you. They will, will not be there to tell you what to do every day. But as a PM, I'm very careful to invite, uh, managers, um, to certain activities that were, that were creating. For example, if creating a roadmap that is based on, based on outcomes versus a list of features on a timeline. If it's the first time that we're doing that for, with a company, I make sure that the management is there as well to understand the how and the why, and to really be on board with how, how the team would be going to do things. And, and so when you like, like, for example, with the, uh, the application you were mentioning earlier, like as, as a PM, what does it look like at the beginning when you're trying to figure out what that kind of vision is? Right. Cause the way you described it visually to me, or at least spatially is sort of like there's, uh, there's leadership or upper management and they come up with some, uh, some general directions and desires.

They want for the organization. And then, and then that kind of like trickles down to be detailed and executed into the organization. Um, and so like, at what point does a PM sort of like get out a bucket and capture the vision and, and, and the strategy and translate it to what the team actually does? Well, I think it depends if you're already, like, if you're there when the, when the vision is created, um, it's interesting if some of the PM is part of it, right? And once we have this vision, we also need to make sure that the product really, uh, would really make sense for the user, for the market. Like that vision will usually touch a need, but up to the point that we need, when it's just a new idea, we don't know yet if it's really going to make it or not. So actually what the PM does, and ideally with a team at the beginning is, um, what we call discovery product discovery. We are going to go out there and use data uses, uh, technical, technical exploration and see if this product is feasible for the user and for the business. And what do you mean by for the business, for the business, uh, it, it depends on the company, but it can mean, uh, it will help us, um, earn more money in this sector or position ourselves on a new market or minimize costs sometimes. Right, right. Like, like it, it, it does something useful for the business. Yeah. It will help the business be more successful or grow. Yeah. Uh, yeah, you know, that, that's an aspect, um, uh, at least, at least in my, my reading of, of product management over the years that it comes up every now and then, but I always feel like there's not enough emphasis on, you know, I don't, I don't know what the words are nowadays, but you have, uh, you've got two parties. I mean, I guess there's three, there's the team that you're serving as it were, like making sure you're creating value for and making sure they're happy and productive and everything we were talking about.

And then you have the, uh, the customer or the end user, uh, and you want to make sure the software is useful to them. And then there's also the, I don't know, stakeholder in the business. Like you said, you also have to manage the priorities and the needs of the business side and not, not just those other two, uh, areas. So that seems like a lot of the work, I don't know, I'm not really familiar with a lot of how PMs interface with like, I don't know, the strategy function or, or all of that as you're talking about, which is, uh, which is an interesting bucket to think about. Yeah, I think this is one of the, like the fact that the PM is in the middle of, um, stakeholders, team, um, users. And, and when I say stakeholders can be leaders, but also so many other teams like legal team, the marketing team and so on. It's challenging, but it's also like really, really interesting and it's really vital for the, for the PM to be in contact and to communicate with all these different roles. For example, there are companies where the legal aspect is vital. It can really kill our product. It's not really like, it depends, but it's, it's not very fun for some PMs to do that, but you do it. Yeah. I, I, I, I often wonder who, who finds that fun. I guess maybe the lawyers who do it, but, uh, yeah, it takes, uh, there's not that many people who get excited about it. Oh, goody. We get to do some policy and regulation now. But it is vital as well as working with marketing and, um, making sure that their objectives are met by your product and vice versa, right? Like, how can you bring more leads or work with sales? Like in some companies you launch this amazing product, but sales still sell the product from last year. Why? Like the PM works with sales as well in order to, to keep them updated in order to inspire them with a new product. But also simply help them understand how they will meet their own goals at sales if they sell more of your product.

Right. And I would, I would imagine like with the, you know, with any kind of customer service or a customer facing thing, like the, the, the app y'all were working on, you know, you would be from the business side, you would be interested in from other cases. I read at least two things. One, uh, it might be, I don't know if cheaper is the right word, but it might be more efficient and better to do things through, um, like an online customer service tool than call centers essentially. Right. Uh, I don't know, call centers don't seem great for, for, for, for anyone. Uh, they're just sometimes the best way to solve the problem, even if the experience isn't everything you would want it to be. And then related to that, uh, which is another one of these kind of unquantifiable things that I think actually is incredibly strategic that comes up is you just want like better customer experience. Like you want your customers to actually enjoy being a customer and using your service, which I think, um, to use another field, like in banking, uh, where it's kind of possible to move from bank to bank pretty easily. If you really want to like having that good relationship with your customers seems well worthwhile. Um, I don't know if you can kind of determine what it is and measure it, but I, those are like two things in my head. I'm always thinking of like, what is, uh, what's the business stakeholder requirement, so to speak, or, or, you know, thing that a PM should keep their eye on? Yeah, I think we, every time we start a project, we, we look at the business objectives. Like we look at product objectives, maybe sometimes we have technical objectives, but we look very closely to, to the business objectives. And as a PM, we always try to focus on, okay, we all say we want a successful product, but what does success mean? Right. Because we can all have different definitions and just assume that we have the one that's not going to work.

So it's very important to ask ourselves what does success look like and quantify it. Yeah, absolutely. Yeah, absolutely. We look metrics that are, that are objective and quantifiable and also check, check on it from time to time. Like, for example, when I create even the first iteration of a roadmap for, for a new, for an existing or new product, I always go back to the objectives. And I'm like, okay, does this really help the objectives? Does this go hand in hand with the objectives that we have? Yeah. Yeah. Which I guess highlights that role, you know, we've, you've been mentioning of the PM of having a, I always, I don't like the phrase big, big picture, but, but you have a big picture view of the different parts that come together. Right. Like, like, like I like the way you phrase it where, uh, you know, uh, engineering and design might say this feature is great and, and viable and it's done well. And we have proof that, um, people use it in a productive fashion, but then we also need to make sure that it's like valuable to the business that they're like the way we prioritize our effort. And, um, making sure this feature exists or, or evolves, like it has to also be, you know, viable for the, uh, the ongoing operation of the business. Yeah, exactly. And it's also, uh, sometimes as simple as it needs to make sense in the whole of the company, there can be problems of, you don't want to cannibalize another product, or maybe there is some political, um, context that will make you things, make things differently. But for this, you need to really communicate with your stakeholders and understand what their stakes and what their constraints are at every moment. Like it did happen for us as well. Sometimes we discover amazing things about the users and we're like, this is such a great opportunity. And sometimes we don't go forward because of political constraints of the company or because it doesn't make sense at the moment for the business.

And it might make sense later on. Yeah. Yeah. Or yeah, there's always, you always have to be on the lookout for, uh, some, something that makes your wonderful idea not work in the overall context. Exactly. And it's not easy, you know, because we are, sometimes we are emotional people. We are, we empathize with the user and we see this great opportunity and we want to advocate for that. Yeah, exactly. We need to be able, and especially at VM, you need to be able to take a step back and be like, okay, is this a great opportunity for all the different aspects of business, user technology, and so on? Yeah. Yeah. That's, that's what you get when you have a, a team of lively, excited problem solvers is every now and then you have to say, all right, that is an exciting problem, but let's not solve it. Yeah. We have, we have too many solutions. We need to have less, less fixes and, uh, focus on just a core of them. Well, you know, I don't, I don't want to go into all the details of the talk because, uh, you know, if, if people are interested, they should just come to SpringOne platform and see the talk. Yes, come hear us. Yeah, yeah, definitely. And, and then you'll, there'll be, uh, there'll be both of you speaking on it, which, which will be great. Uh, I'm, I'm excited to see it. And, um, but before, before we wrap up sort of apart from that, I'm always curious how people ended up where they are. So how did, how did you end up being a product manager and doing this role? Wow. Huh? It kind of comes a long way because, uh, it's interesting. Actually, I'm an engineer and I've done engineering studies and, um, ever since high school, I started volunteering in different NGOs. And this is how I discovered at the beginning projects and marketing and then kind of building a product. And I started being really, really passionate about it. So after finishing my tech school, I actually started, uh, working in, in product at the very, very beginning as a consultant, not really as a product manager, but little by little, I got really, really passionate by, you know, building things that, that make sense, that are really like, that help people.

Or simply just the whole thing of discovering a new idea, seeing if it makes sense and then putting it out there and seeing it work. So it just, it keeps being pretty amazing for me. Yeah. Yeah. Especially the fact of like not doing it, you're not doing it by yourself. And the fact of like having an entire environment that you get to, to motivate and to go in the same direction and build that as a, as a collective success is, is really, as we're saying, only a magical. So, yeah, you, you, you sort of have the, the, the whole machine of the team and the process. And, and then also, I mean, to go to the thing, uh, the kind of underappreciated forgotten thing we keep mentioning. You also have that wider organization or business context that, as you mentioned, can have annoying so-called politics involved, but they also like can be that same kind of environment that brings you the, uh, the customers and the opportunities and the market, so to speak, you're operating in. So you have, uh, you've got all the tools in the workshop if what you like doing is product and, and tinkering with product. Yeah, exactly. And I think it's like, as in everything, you have these challenges because, you know, like here we're talking about, you should do this, you should do that. And like, it seems pretty easy, but actually in day to day life, it is hard. It is pretty hard depending on the, the product, the company have a lot of challenges. And that's what we wanted to talk about, uh, at, at the conference as well together with Pani. It's like, you have all this challenge in order to get to success. And it's like really cool to, to, to see the whole process. And at the end when, when it worked well to be like, okay, all this was really worth it. And we have something great now. Yeah, you've got a good, you've got a good, uh, reward feedback loop in place. Well, great. Well, I, I think this, this is, uh, it's, it's always fun to talk about product management and, uh, get a little preview of the talk. So do you have, uh, you know, in the meantime, while people are waiting, you got like a, a web blog or a Twitter account or anything you would, you would, uh, point people towards?

Yeah, definitely. I have my, my medium account, Alexandra Lung. So that I, I post articles from time to time. If you want to follow me, if not, yeah, I have my Twitter account. It has the same name, um, LinkedIn as well. So don't hesitate to come back to me with any questions, stories, chats about product design. I'd be happy to. Yeah. And you know what, what I noticed about most, uh, especially in Pivotal, but most product manager people I talk with is they're very eager to, eager to talk about product. How many great stories we share, like when we meet between product people, it's like such a, such a knowledge base and like a lot of amazing, amazing stories. Yeah, yeah, yeah. I mean, it's, it's, it's a, um, obviously not all developers are like this, but there's a stereotype of developers that they don't, you know, really want to talk with people, which back when I was a developer, I soon learned that that meant that there were just topics. I didn't really talk about with people, but if you want to talk about programming, I could talk all day about it. But, uh, yeah, I mean, definitely, uh, PMs tend to be very cheery and, uh, open to talk with anyone, which, uh, which should be good for the talk. And just, so. Yeah, come see us, like contact me beforehand or come see us after, before, after the conference. So I'd be happy to, to chat more in details about certain aspects of PMing and building products. Yeah, well, it should be fun. Well, uh, again, it's at, uh, it'll be at SpringOne platform. And if you just go to SpringOne platform.io, you can, uh, get all the information and I'll put a little link in the show notes to get like, I think you get like $200 off registration or something. Uh, and I don't, I don't know if we've scheduled the exact day that it's on, but the, uh, the name of the talk, which I'll also put a link to. Yeah. It's on Tuesday morning. Oh, that's a good time. First talk of the morning. Perfect. Yeah. So y'all should come check it out. It's called leading product colon the sparks, the challenges and the victories, which, uh, that sounds very, very hopeful.

So, uh, thanks again for being on and, uh, we'll see everyone next time. Bye bye. Well, I hope you enjoyed the interview. I think it was pretty good. If you want to come check out SpringOne platform, remember it's in Austin, Texas, October 7th to 10th. If you go to SpringOne platform.io, you can use the code S1P200 underscore Coté to get $200 off registration. Use that $200 to get yourself something nice from Austin, some fancy food, whatever you may be up to. You could put it in the bank and just, uh, sort of look at it every now and then and be admiring the fact that you, uh, not only went to a great conference, but you were savvy enough to use the code S1P200 underscore C O T E to save 200 bucks. Well, I hope to see you at the conference in Austin. Bye bye.

Tanzu Talk · 🍕 Get more pizza.