The Role of the Product Manager: UX, Marketing, Strategy?

Alex Radu at UXDX EMEA. Video: https://youtu.be/d-tTzSWu7lc

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Poll one: what is your product manager team structure?

[00:00:00] Alex: Hello everyone, it's lovely to be here in Dublin, although not as sunny as yesterday. But in Scotland it's about the same weather, so I'm used to it. I'll be talking to you today a little bit about product management and what we think it is, but really most of this is about you, about your experiences and how you view product management, and how the discipline interacts with all the other disciplines involved in product delivery and development. So we're going to have a few polls, and if you scan the QR code over there you can start answering the questions.

[00:00:36] Alex: So the first question is, what is your product manager team structure? I've seen teams that have one product manager, or they're like uber teams of product managers that manage a lot of product lines with a lot of products in them. Which one of these are you? Right, interesting. Most people have one PM per delivery team. Some people have no PMs. Would you mind raising your hands, we can get a mic to you. Can you tell us a bit more, the people that don't have PMs, and what your thought process is? Has UXDX changed anything today for you? Anyone want to raise your hand if you voted no PMs? Oh, I see it's going down. How is that going down, is someone not being truthful? Anyone want to raise their hand for no PMs? No, it's okay, we're not here to shame you. I just want to know why you're here. Okay, can we get a mic over to the gentleman in the third row?

[00:01:38] Audience: We're just in the process of introducing it.

[00:01:41] Alex: Okay, so you're moving to a product-led type of organization. Exactly. How are you finding it?

[00:01:45] Audience: It's tricky. A lot of different points of view from executives on what it should be, where it should be, whether it's within the delivery practice, more focused around the actual UX practice.

[00:01:59] Alex: Yeah. And how are the teams involved in it finding it? Do you have anyone in project management that's a bit fearing for their job?

[00:02:09] Audience: A little bit. We've structured it with pillars within project management, in a sense, so we're gravitating a few of the project managers into the product delivery world.

[00:02:19] Alex: Cool. And one more question for you. What is it that made your leadership and your teams decide to move to product-led?

[00:02:27] Audience: We've been so successful with it on particular parts of the business that I've been working on, and it's been something I've pushed for for a very long time, and I think they're just starting to see that sector of the business grow quite exponentially.

[00:02:45] Alex: Yeah, awesome, good results. Amazing, thank you so much. Does anyone else want to contribute, do you have any other thoughts, how has your journey been? I can see there are a lot of people that have one PM per delivery team. How is that working for you? Is it productive, is it not? Do you want to share? We have another person in the third row. The third row seems to be on fire today.

[00:03:12] Audience: Thank you. So yeah, one PM per delivery team, and I've had that in a number of jobs now. I'm a user experience designer, so I've had one UXer per delivery team, or, as is the case right now, one UXer across anything and everything that's needed. I personally much prefer being embedded in a delivery team, because you become an expert in that area.

[00:03:39] Alex: Yeah.

[00:03:39] Audience: But I do think you need to have a cycle for a delivery team so they don't get bored as well, and they stay productive and entertained in what they're doing.

[00:03:48] Alex: Yeah. And have you had any experiments where you've kind of tried to mix up the number of product team members, or has it just been, oh well, it's working, if it's working we'll just keep on going?

[00:04:00] Audience: I've definitely had an experience where we had one senior, one junior, and that was quite fun, because you could see the junior growing literally day by day, taking over more of the responsibilities, and then you'd often find the senior would move on to something else and be able to look at other stuff. So it's really efficient. But I've also seen that being really taxing on a PM. So yeah, it's hard to speak because obviously I'm not a PM.

[00:04:30] Alex: Yeah. Sometimes an outside perspective is really good though. On that note, does anyone here have an APM, so associate product manager, scheme at your company? I'm curious to hear how those are going as well. Anyone? No one? Sorry, yes, it counts, any experience, it doesn't have to be your current company. Good question.

[00:04:57] Audience: Yes, in my previous company we had an APM program. It worked very well, because I actually personally helped a couple of people to shift into product, from being an analyst, an engineer. And it's a lot of fun, because they come with great expertise and knowledge in something else, and you just figure out where the gaps are and how to help them to grasp how to align stakeholders' points of view, who are the customers and what problem we are solving. I think this is the best shift you can do, to shift to being product within an existing organization, because you come with an insane background in something that will support you in this journey.

[00:05:44] Alex: Awesome, yeah. Anyone else thinking about adding an APM program now that you've had a good intro to why they're good for your company? I will say that we do have one for our Chase International Bank, which is our new digital bank in the UK. So we are looking at growing talent, because it's very hard. You don't really go to school to be a PM, and when people want to transition it doesn't really work that easily, because you don't really know what your gaps are, what you need to learn, what you already have. So having an APM program can somewhat help you transition into that role, and, to the point of the person before, it can also give the opportunity for you to learn from more experienced PMs and kind of facilitate that transition.

Poll two: what are product managers responsible for?

[00:06:26] Alex: So we're going to move on to the next question. What are we responsible for? There's a lot of options there. You should have the opportunity to select more than one, so be honest. What do you think we should be doing? What do you think a PM is responsible for, not responsible for? Oh, look at that shoot up. All right. Okay, we're going up. There's movement in there.

[00:07:04] Alex: Okay, there's a lot of product vision, there's a lot of business priorities, there's a lot of stakeholder management, prioritization, backlog management, continuous improvement, reporting, market research. Okay, so apparently we need to do everything. So how many people here think that's maybe a bit too much? I can see some of them are starting to go down, where some people are like, no, this is something we definitely need to do, but you might have to do another 20 other things. So I like the emoji reactions, thank you, I feel the same.

[00:07:42] Alex: So does anyone want to share, do you think this is all the responsibility of one PM? Previously a lot of you, the majority, responded that you have one PM per delivery team, and now we're saying this is all you need to do as that PM for that delivery team. How do people feel about that? The lady.

[00:08:08] Audience: I think most PMs are kind of flexible, and it all depends on the maturity of your team. So if your team is very good and on top of discovery, then probably you will be focused mostly on delivery, or on stakeholders, on strategy. If they're bad with discovery you will focus there. If you don't have an analyst embedded in your team you will start doing some experimentation and learning data and so on. So it really depends, again, where the gaps are, and we always need to wear different hats in order to make this team successful. And you're not always getting all the resources you need right here right now, until you prove that your team is delivering something great. So that's why we end up with all of that, and our T-shape is actually super, super long stretched.

[00:08:56] Alex: Yeah, exactly. So how do you think, and this is not just for you, it's for everyone here if you would like to share, how do you think that balance and that morphing needs to happen? If we're saying actually you need to know how to do all of these to some extent, because one day you might need to do it, how do you then hire for these people? How do you know what type of people need to be in that role? And are you literally giving someone a job description that says, beware, you might have to do one of these 100 things at one point in the next 90 days or 60 days or 180 days? Is this fair, and is this something that's in those job descriptions? Are we telling people ahead of time this is all we expect of you? Is this actually happening, or are we just saying, well, if you are a PM there is a time when you might have to learn how to do one of 50 things because we might need you to? And is that fair towards product teams, product managers? I saw you smiling.

[00:09:56] Audience: Yes, I'm one of those product managers actually that has switched from being in engineering for eight years of my career towards product. So you can actually apply a lot of things that you've done through your education or other roles in a company into product management. So these are applicable skills. But yes, it is a tough one, because product management is such an umbrella term for so many things, for so many different companies. If you look at job descriptions for PMs, they could actually sit in a marketing team, or in a product team, or in engineering, or somewhere else. So I think it's not standardized, and I think companies need to be a little bit more descriptive in their job search, when they put the jobs up.

[00:10:45] Audience: And another thing, you learn by doing. It's honestly one of those things that you just need to be flexible, curious, experiment and learn by doing. And there are senior people in product across a lot of companies, amazing talented people, people that you get to learn from. So choosing the right company for you and the right mentor maybe for you, doing some coaching, mentoring programs, there are a lot of them out there that help you build some of these skills.

[00:10:58] Alex: Awesome, thank you. I will flip that statement into a question. So we're saying there are a lot of transferable skills, and we're saying there are a lot of things that you can learn by doing. Why is it so hard, or why is it so competitive to hire PMs? Because we're saying basically 50% of what you do can be learned on a job, or you can learn from other places, but then we're making it super difficult for people to get a product job. So what's happening there? Gentleman over there, actually it's our keynote speaker from this morning. Oh yeah, no pressure.

[00:11:46] Audience: One of my really good friends and I have had this conversation for a couple of years. There is a lack of consistency in whatever you call product management as a, I don't know what it is, like design is a craft, engineering is a practice, we have principles on both sides that are scientifically based, but product management takes many flavors. And since the schools, or I don't know if it's schools or education or industry, doesn't have those standards, then you get a disparity in practitioners in the same company.

[00:12:25] Alex: Yeah, awesome, thank you. Oh, here we go, there you go.

[00:12:27] Audience: I think you asked a very important question which is very close to my heart, that's why I raised my hand again, sorry, this girl in the first row again. I think PMs, as you mentioned, they're super curious and they're super flexible, so often they don't want to do the same thing. And many companies, they hire you on a track record. So if they're feeling issues of, I don't know, developer experience platform product, they want to look for someone who has done it in the past. But PMs often want to do a new challenge, so they want to be hired on potential, not on the track record. And we end up that companies are looking for someone who has done it maybe several times and successfully, but I don't want to go there because that will be the same challenge. I want to do something bigger, broader, bolder, you know. And we end up again with a competitive landscape and bigger ambitions.

[00:13:22] Alex: No, that makes sense, thank you.

Poll three: what is a UX researcher responsible for?

[00:13:25] Alex: We're going to move to the next part, and this is contentious. What's a UX researcher responsible for? We've moved from product to UX research. So if all of us as PMs do a lot of the previous things, what is research responsible for?

[00:13:46] Alex: Okay, market research, it's in the name probably, although I would debate some of market research is marketing but some of it is combined. Customer interviews. Solution validation. Reporting. Can someone expand, because I'm not entirely sure if we're talking about the same kind of reporting. Who voted reporting? I want to know why you're saying that reporting is the UX researcher's job. Do you mean in terms of reporting results of the research, or do you mean reporting as in reporting product success?

[00:14:26] Audience: I put in reporting as reporting your findings.

[00:14:29] Alex: I'm blinded by the light and I cannot see you. Yes, okay.

[00:14:34] Audience: But yeah, because there's really no point of you doing research if nobody in your organization knows anything of it. So I think that's a key responsibility.

[00:14:44] Alex: Yep, okay, thank you for the clarification. How about idea prioritization and product vision? Does anyone want to share their thoughts? We have the lady in the third row. Don't apologize, I also have a problem with putting my hand up too many times. I call it a problem, it's good practice, like keeping active.

[00:15:11] Audience: Yeah, it's exercise. I also got hooked on that and completely forgot the question, I'm so sorry.

[00:15:18] Alex: Sorry, it was around the prioritization, product vision, what your thoughts are.

[00:15:22] Audience: Yeah, so as a product designer we tend to get a bit obsessed about our product, so it kind of stands to reason that we would have a vision for where that product needs to go. Hopefully we also understand our business's priorities and strategy and how that fits in, but not all the time. Sometimes we just like to go on a whim and we're led by the users where it takes us.

[00:15:46] Alex: That sounds so poetic, sorry.

[00:15:48] Audience: Yeah, I like to think of my job as better than it is. No, I'm kidding.

[00:15:50] Alex: I love it.

[00:15:53] Audience: So yeah, it just kind of all flows into one for me. If you're feeling passionate, is such a glib word to use, there's another word I'm looking for, but if you're enabled in your job to really get into what you're doing, then you should naturally have ideas and thoughts and drive for any segment, and kind of stick your nose in even if it might not be your official job title.

[00:16:23] Alex: Yeah, awesome.

Poll four: what do designers do?

[00:16:25] Alex: All right, designers, what do they do? Oh, people are thinking about this a bit. Okay. Oh cool. How much time? Okay, all right.

[00:16:55] Alex: So we have product vision, business priority, market research, solution validation, continuous improvement. Interesting. So can you tell me a bit more about the market research part that you've attributed to designers? It's quite significant, so almost 10% said market research. How are designers responsible for market research? I see shaking heads. So if you feel strongly opposed to that view, we accept comments as well. So if you disagree and you don't think they should be responsible. Oh, I see someone in the back. Yes, and one over here. All right, who wants to go first? The gentleman on the right.

[00:17:49] Audience: I would say the main question is what type of designer, because for example if you're a full-stack designer, the UX research falls underneath it as well. So that's my perception of it.

[00:17:57] Alex: Okay, so this is in the hybrid state of, you're not just doing design, you're also doing research. Okay, thank you. The other view, gentleman on the left.

[00:18:06] Audience: Yes, so what I believe is that lots of ideas have already been discovered and well tested in other products. So you actually do market research in order to save money and actually learn off of other people, which is why you kind of benchmark and compare your solution, even within the same niche, or actually you can look elsewhere, broader. So there is usually no point in actually spending cash and reinventing the wheel if something has already been established and it's really working.

[00:18:34] Alex: Okay, so this is more to find validated solutions to problems you're trying to solve for your customers, as a designer.

[00:18:41] Audience: Yes, well, it's one of the points you can take into account when actually designing a solution.

[00:18:46] Alex: Okay, cool, thank you. Anyone else on the designer attributions, any other thoughts? Is there anything that we haven't put in there that you feel should be in there? Sorry, ideation. Hello.

[00:19:01] Audience: Yeah, I just wanted to make a little comment here. When you said about designers versus researchers, yeah sure, I think there are people who are just pure researchers, but I've never really met a designer, or particularly would want to work with a designer, who said I'm not interested in doing research. To my mind all designers should at least do some research, or at least be aware of what's going on.

[00:19:28] Alex: Yeah, no, I agree. I also like to pick on the fact that it said market research and not just generic research.

Anti-patterns: the mini CEO, the waiter, the former project manager

[00:19:37] Alex: We have another thing. What are some of the anti-patterns that you have seen within the structure? This is specifically more around product managers. So those three kind of anti-patterns: telling people what to do; collecting requirements but having no say in setting the product vision; and also the last one, the former project manager that is only focused on delivery, they're not looking at the actual product-led mindset.

[00:20:12] Alex: Does anyone want to share some anecdotes from how you've interacted? So if you're not a PM, how that felt to interact with those types of anti-patterns, and what impact it had on your job, whether you're a designer, researcher, developer, other product people? I'm trying to see, but these lights are blinding me. Rory's on it.

[00:20:36] Audience: Yeah, hi. So what I have seen lately is basically the waiter approach. Definitely we do have people who collect requirements from RFPs or from sales and just simply download those on the designers and say, oh, we need to get this done. And then we ask why, have you ever looked for a user, asked if they really need this? So this is actually something that we have seen happening more and more.

[00:21:02] Alex: And have you seen them at any point try to substantiate that? So have they ever come to researchers to be like, hey, can we run, I don't know, a survey, or can we do some user testing, can we actually see if this is working, can we look at our adoption metrics?

[00:21:20] Audience: We're actively trying to push that back and fight against it and questioning why, and eventually there are some changes happening, so that's pretty good. But that's still the case, in some cases they simply download the requirements that they get.

[00:21:35] Alex: Yeah. And have you seen any kind of results from the customer side? So have you seen an impact coming back from them doing that, so, I don't know, disappointment or frustration from your customers? Is there anything coming back through the journey back to them being like, hey, this is not really okay?

[00:21:52] Audience: Yeah, that happened, and that's where we could say, okay, now let's please use our skills to avoid this. Yeah, that definitely happened as well.

[00:22:03] Alex: Awesome, thank you. Anyone else, any other experiences? 60%, that's a big number. Don't be shy, you don't have to name names.

[00:22:16] Audience: Thanks. I think it's just worth mentioning the impact that it can have on culture and on team dynamics and on just the general vibe of the team, if the PM, and I come from an engineering background, but if the PM doesn't feel empowered or isn't empowered to provide a product vision, or to make those decisions, or to create an environment where innovation can foster, then that has impacts up and down the chain. Engineers obviously will feel that as well, that there's no point trying to innovate or trying to create new ideas, because there's a barrier there further up the line that they just won't get any further. And obviously it's not healthy for a PM if they don't feel empowered, and they end up adopting that waiter persona then, which doesn't really help anyone.

[00:23:12] Alex: Yeah, thank you so much, that is a very important point. Yes, welcome back.

[00:23:16] Audience: So to me the mini CEO and the former project manager are very similar. It's just that their rationale of why things need to get done are different. One is, I don't know, maybe business reasons, and the other one is just viability, or visibility. So to me the consequence of any of these anti-patterns is lack of clarity in decision-making and lack of leadership. And then the team takes the other responsibilities, trying to fulfill the gaps, but that slows down the whole process and creates conflict and that kind of stuff.

[00:23:55] Alex: Do you think that sometimes, because we ask them to do so many things, it's easier to just be, well, I'm just going to look at what needs to be done and I'm just going to go and tell the teams to do it? So do you think the fact that we have so many expectations, or the fact that we have such vague expectations, can actually make it worse, and these anti-patterns come into play because we're not actually telling people, okay, this is what you're actually hired to do and we're empowering you to do that? We're telling them you have to do these 500 things and they have to be done as soon as possible and you have to figure out how you do it. Is that maybe also a reason, because we expect so much but we give so little direction that sometimes it's just easier to just fall into one of these?

[00:24:42] Alex: I will ask the question, is anyone else wanting to contribute, because we have a serial contributor here. Can you hand in the mic? I can hear someone. Is the mic working? Yes, it is working, okay, perfect. This is weird.

[00:24:57] Audience: I think one thing that's interesting is that you've added there, for example, former project manager, maybe it's, I don't know, engineering background. For me, I used to be a software engineer and then I got an interest in moving into product, and I don't see a clear linear trajectory into there. It seems like there are different industries with their own degrees and, I don't know, boot camps, they have that formal training, and then you're just thrown into this new job and then you just bring in the old patterns. I've noticed that as a former software engineer, I'm just used to maybe delivery, maybe not the research aspect, etc. So maybe one of the reasons for the anti-patterns is because there's not really a structured pipeline into product management. It just seems a bit random. I don't know, maybe I'm wrong.

[00:25:47] Alex: Yeah, I think we just can't make up our mind about how to get there and what to do when you got there. So no, I totally agree, it is not very straightforward. I think out of all of the careers and roles that I've had, product management, and to some extent product marketing management, are some of the most random careers that I've had, where people don't really tell you what to do. They're just like, okay, we need you to fix this. And it's like, cool, how, what do you want from me?

[00:26:21] Alex: So I think there's a lot of learning how to relate and how to go back to product and the customers, and those things are not maybe innate in things like engineering or in other industries, or in other roles where you're like, okay, I know what I need to do and what's expected of me. And this is more, we need you to do this, but we don't really want to tell you how, or we don't have what to tell you, just figure it out. So I completely understand, and maybe it's something we need to fix in the industry.

[00:26:50] Audience: And just one thing I wanted to add. I don't know, this is just my theory, but I feel like this role, it's a new role, it's almost like the glue, they call it the CEO of product. You want to connect the marketing, the engineering, the finance, you're connecting everything. So it's just shifting depending on the type of business you're in, the needs, etc. It's not really formalized, and the only way to get there is through that business intuition that you only get with more experience. But obviously if you don't have the experience it's hard to enter that role. So it's a tricky one.

[00:27:24] Alex: It's a vicious circle potentially. But I think also I want to mention this: sometimes people work so hard to get into product and to become a product manager, and once they get there they realize it's nothing like what they wanted, and then they're a bit stuck, and then they're thinking, well, I just gave up my other career to make it here, and now I'm here it's not really what I expected. And also if you change companies things can change drastically, because again there's no consistency and there are no expectations set across the organizations. So just for people here aspiring to be a product person, just make sure you do research before you jump in, because it might not be what you expect, or it might be more than you expect.

Product teams, guilds and communities of practice

[00:28:12] Alex: I think we've gotten to the end of our questions. Are there any other questions or any other thoughts that people want to discuss, because it is a forum, so it's all about you? Yes.

[00:28:27] Audience: At the beginning you mentioned that the majority of people said that they have one PM per team, was it that case?

[00:28:35] Alex: Yes.

[00:28:35] Audience: I think one of the problems is that a PM can get very lost, again because of everything we've discussed. And I don't know how many companies have proper product teams, being a PM as part of a product team where you are really not just servicing a delivery team, but you are first and foremost part of that guild, that team of other PMs and designers and UX researchers, where you meet, where you discuss, where you solve things together. I think that is a piece that can fix a lot of this uncertainty and feeling lost in what's expected of you and what you're supposed to do. If you join a company that has a proper product team where you can rely on others to help you, that is one way to help with that.

[00:29:20] Alex: I also have another suggestion. So we actually have communities of practice. I'm sure a lot of you have heard about them. We actually have a very good framework, we have them firm-wide, location-wide, and kind of theme-wide and topic-wide. So we actually do have a product management and product community, and we have people from across our organizations, our teams, that again are kind of isolated in their delivery teams, but we all come together and we discuss. Some people have physical products, some people have digital products, some people are senior PMs and people are junior PMs.

[00:29:59] Alex: And we meet. We sometimes just meet to talk about, hey, there are these changes happening, I just want someone to talk to me. And that might be, we bump into each other in the kitchen and it's like, hey, do you want to set up just an informal coffee chat with everyone in the community, because we all are feeling a bit stressed? And we just set it up, we talk, we try to get some of the teams that are involved in the transformation or changes.

[00:30:23] Alex: We're setting up a mentorship program internally, so we can get people that are aspiring to have a product role, or people that are more kind of at the beginning of their career, with more senior ones, so they can learn from each other. And it really brings that sense of, I know what I'm doing to an extent, or someone can guide me. We do things like roadmap sharing, so people bring their roadmaps and we just kind of discuss what you're trying to achieve with it, like how many types of roadmaps you have, because some people have three or four depending on their stakeholders.

[00:30:58] Alex: So just to give you an idea, if you are in that situation and your company is maybe a bit smaller, or maybe a bit more separated in terms of your product teams, you might want to look at creating a community of practice for your product teams, because that brings them together, and to some extent it might dispel a bit of that uncertainty and give them a sense of support to each other.

[00:31:22] Alex: So, are there any other contributions, or are we at time? One more.

[00:31:28] Audience: Yeah, I think it really comes down to collaboration with the stakeholders and their willingness to do that, especially in the anti-patterns. I worked on a team which you didn't capture there as a scenario, but we had three PMs for a larger delivery team. One would say no to everybody, one would say yes to everybody, and I would ask everybody why. They'd always try and go to the yes guy first, because they don't want to try and explain themselves, and you have to work with them to change that mindset. You want the result to be better than either of those scenarios.

[00:31:57] Alex: Yeah, I love that. I think the why person is usually the most hated one, because at least you get a definitive yes or no, but when you ask why, people are like, oh no, I really need to think about this now, I actually have to go back and give a proper answer because they've asked me why. They do work, yeah. Thank you.

[00:32:19] Alex: All right, are we ready? Okay, thank you so much everyone, it's been so much fun to chat with you today. If you want to find me and have a chat afterwards, just come and say hello, or you can scan my badge and ping me on LinkedIn.

Closing question from the host

[00:32:33] Host: Right, don't go anywhere please, because I have a question for you. Okay, actually let's move one. So before I ask Alex her question, I'm going to ask you for your feedback on her session. Be honest. Feedback is a gift, also constructive feedback is a gift. So Alex, you gave plenty of different angles, if you will. If you were to rule your world, I know, a dangerous proposition.

[00:33:17] Alex: There will be a lot of unicorns in it.

[00:33:19] Host: Yes, there would be a lot of unicorns I'm sure. But what have you seen work very successfully? How would you structure things?

[00:33:31] Alex: Having a solid product vision, and having very clear collaboration patterns for all of the product teams, and I'm talking about engineering, design, research, marketing, sales, everything. Making sure that people know each other, they know how to interact with each other, they know when they need to come in and when they need to talk to their people. That makes the most difference.

[00:33:56] Alex: And then the third thing, always talk to your customers. Always, even when they're so upset and so annoyed and they don't want to talk to you. Be like, listen, I'm just going to sit and listen, you just talk to me and tell me what you hate, what you like and what we can do better. It's painful, it's annoying, it's frustrating, because you're like, but I'm working so hard and they're still not happy. And it's like, yes, because you're still doing something wrong and you need to figure out what that is, and all of the teams need to come together to figure out how to solve it.

[00:34:29] Host: And to that I can only say amen. Thank you Alex. Let's give her a round of applause. Have a great rest of the day and see you around.

[00:34:36] Alex: Also, sorry, one more thing. We're thinking about maybe doing a UXDX community meetup in Scotland. I live in Scotland, so Roshen[?] is your person if you would like that to happen, if you're from Scotland too or you want to see Scotland. And the second thing, if you're coming to the workshops, I'm running one on Friday at one. So if you want to sign up, it's around product marketing and product management. I hope to see you there.

[00:35:00] Host: Amazing.