Let's talk about product roadmaps - Mind the Product

Episode Transcript

• 0:00 What is the purpose of a roadmap?
• 5:00 Why roadmaps are important for a bunch of different reasons.
• 8:32 How many products do you have? How many stakeholders? How often do you update your roadmap?
• 11:59 How many roadmaps do you need to have?
• 14:28 What is the difference between a product roadmap and a release plan?
• 19:06 What’s the purpose of the roadmap?
• 21:06 What is a roadmap? How do you use it?
• 25:46 Randy’s top tips for making your roadmap accessible.
• 30:21 The importance of using the right language for your roadmap.

---

Randy Silver: 0:00

Hey Lily. We had a lot of fun a few weeks ago talking about OKRs and doing a deep dive and playing some best ups from our guests how they we do that type of thing again,

Lily Smith: 0:10

I would love to do that. And what have we got that we can talk about?

Randy Silver: 0:15

Well, we’ve talked about roadmaps a few times on the podcast we’ve had, let’s see, we did Bruce McCarthy. Chris Adams came on to talk about carbon neutral roadmaps. You talked to Jeremy levy a few months back, and of course, we had Janet Bastow on. So

Lily Smith: 0:30

it’s such a hot topic. Let’s do it again.

Randy Silver: 0:36

Yes, let’s do it again. Let’s hit the music and then we’ll get right into it. Okay, let’s start off with the most basic question about this because we kind of know what roadmaps are we I don’t think we need to describe what it is. But what is the purpose of a roadmap? I think people get confused about this.

Lily Smith: 1:08

Yeah, okay. So for me, like, I use roadmaps to bring the team together and discuss what is the stuff that we’re going to be working on next. And what’s the most important thing to be working on next. So it’s like, it’s alignment. It’s having some tricky conversations, doing some like high level prioritisation about what metrics we want to move where we want to concentrate. And I’ve generally work in quite small teams. So you know, we use we have I have like two roadmaps that sheet Well, now I have one roadmap, which is a kind of something that I review together with most of the company on a quarterly basis, which has like high level objectives. And then I have my kind of tactical delivery board, which is reviewed much more frequently than that, which is not really a roadmap.

Randy Silver: 2:12

And we that’s great, because we get into that a little bit later. In this episode. There’s some people who talk about having different roadmaps for different purposes. Let’s get to that in a bit. But I think the person who gave us a really great answer recently about this was storm, Fagan, Chief Product Officer at the BBC. So let’s listen to what she has to say, Phil, thanks.

Storm Fagan: 2:36

We use roadmaps really as a storytelling device. And that’s because I think in large organisations, stakeholders and feel a bit uncomfortable about product talk. So when you’re talking about a backlog, and you’re not putting timeframes on things, I think, people who are in different roles that have less ambiguity in their jobs, and feel quite uncomfortable with that level of ambiguity, so they like a roadmap. But I think a roadmap should be as simple as possible, preferably focused on outcomes rather than outputs. And if it can’t fit on one slide, then and, and that I mean, one slide for the whole product organisation. So for 1000s of people, then it’s too complicated.

Lily Smith: 3:17

Oh, that’s brave. So that makes loads of sense. And she’s a genius. So everybody should listen to the storm. But dates or themes, like what goes on the roadmap?

Randy Silver: 3:31

Oh, that’s a good one. I think it’s a horses for courses thing. Actually, I shouldn’t say horses for courses is such a British expression. And no one outside this country understands it. And I’ve lived here for too long. So I think it’s one of those. It depends types things, because there are times when dates do matter. You know, if you’ve got a big compliance thing and legislation coming in and you have to do it, then data actually do matter. But yeah, I mean, I do lean towards themes. But we do have a few guests who talked about this, should we listen to them?

Lily Smith: 4:07

Let’s listen to Arushi proven who told us all about what she loves and hates about roadmaps.

Roisi Proven: 4:18

So I hate timelines. Time based roadmaps are a no no, I love team based roadmaps. So each quarter, we have a theme, a goal that we want to improve the product within. And then there is a lot of freedom for the team to decide what the best solution for that team is. And yeah, seeing based roadmaps, one per quarter. Timelines are mean.

Randy Silver: 4:46

And Russia is not the only one who had a good thought about this. Maggie Crowley is also got some really strong feelings here. And I like what she had to say

Maggie Crowley: 5:00

I think I think roadmaps are super important for a bunch of different reasons, mostly because I think it’s incredibly important for the team that you’re on, internally. So engineering product and design to understand and be on the same page about what we’re doing, why, in what order. And it’s also equally as important for the external teams that you have to understand, you know, what you’re going to deliver, why, what problems you’re going to solve for them. So the roadmaps that I use are now next leader, to get on the same page with the internal team about what are the problems you want to solve roughly in what order. And then that brings up the discussion about trade offs and, and why we want to do that. And then the I think it’s also important to have delivery timelines, once you start building to help hold yourselves accountable and to help your cross functional teams plan around you. Because no product team is in a vacuum. And so you need to give your your whether it’s customer success, for me, it’s clinical ops, you need to do them, the respective allowing them to work alongside you. So I think it’s important to have those as well.

Lily Smith: 6:05

Yeah. So what she says about trade offs is exactly the kind of conversations that I was talking about earlier, like you want to be having those conversations, as you’re developing your roadmap. And when you present it to people, it’s really, really important, I think, to be able to bring about the conversation and in a way that’s productive, and allows you to work better with other teams,

Randy Silver: 6:31

there was one of our guests who had a really interesting idea about how to use now next later, with dates, potentially, in a novel way. So that was Alexander HIPAA, let’s hear what he has to say about this.

Alexander Hipp: 6:49

Pretty basic in that sense, they consist mostly on now, next later. And that’s it, like I am quite against putting fixed dates to a roadmap. Sometimes you have to, because stakeholders want to, but it doesn’t really make sense, in my opinion, what’s more important is that you put there how much time you want to spend on a specific item, rather than when it needs to be done. Because that’s really what matters. Like, you can build a different solution in two weeks, then you could do in four weeks. So this is really the the thing you need to talk about with your team.

Randy Silver: 7:30

Okay, so you see what I’m talking about. He’s using roadmaps to enforce constraints, you know, using as a way to communicate to his team that we only have two weeks to do this. So give me the two week version of the solution, not the four week or the three month version of this, you know, it’s talking about how much time you want to invest in it.

Lily Smith: 7:50

Yeah, I really like this. And I like there’s that that whole kind of concept of rocks, pebbles, and sand, and that you decide on your rocks first, which are your bigger initiatives, and then your pebbles and then your sand. And I think being able to even if you’re identifying that kind of level of is it like, a large or a medium or a small item, and this is how much time you want to invest in it. It gives the team and and the whole business an idea of, of how important it is. And and also, yeah, how much time is available to work on that piece. And that initiative.

Randy Silver: 8:32

If you haven’t seen it before, the there’s some really great articles and illustrations about that whole rocks, pebbles and sand metaphor. So we’ll link to one of those in the show notes because we’re not going to go over it in great detail here. But if you haven’t come across it before, it’s really worth checking it out.

Lily Smith: 8:48

Okay, so Randy, how many roadmaps should you have?

Randy Silver: 8:51

Depends how many products do I have? Stakeholders do I have? How many situations am I? Okay? You don’t want to listen to me on this. I have real thoughts on this. And we can go into them a bit later on, to be honest. But we have some of our guests tell us some really great advice on this. So let’s go straight to Kosambi mijita.

Kausambi Manjita: 9:17

So we of course use roadmaps and everything from growth to design to product. But I think the primary again, it goes back to what we were talking about as one of the fundamental qualitative, you know, anchoring of all your signals. And so we use roadmaps in our product in our growth strategy in everything. And we also tie it back into a company roadmap. We’re trying to tie it back to a company roadmap and how we use it as anchor again, it back to qualitative customer insights.

Randy Silver: 9:50

Okay, so casambi talks about having two roadmaps, one that’s aimed at the company level that’s similar to what you were saying before, and then one that’s specifically for the team. And that makes a lot of sense. I mean, it sounds like a lot of work. Doing both of those, it depends on how often you update them. But I want to go to one of our other guests as well. Ha fan had a really interesting thing. She does two versions of the team level roadmap.

Lily Smith: 10:17

Yeah, this is really sort of interesting and strange, but let’s get hard to talk about it. Half.

Ha Phan: 10:27

We have two roadmaps. We have roadmaps that are in the terminal to our team. And we have a roadmap that we communicate to the rest of the org. So I see roadmap as a way to communicate to the rest of the org, so that the rest of the org knows what’s coming. And so we can align on some of the key goals, our roadmap internally so that it’s much more detail, so that the team knows, you know, can aspire to something beyond what we communicate out. But the roadmap is basically a way to align strategically with the rest of the org. And our internal one is to align strategically, with within our smaller organisation. We’re platform team, so much of our roadmap is foundational building.

Lily Smith: 11:17

And someone else who had another take on two roadmaps is antimatter. And

Anthony Marter: 11:27

I have tend to have two roadmaps. One is the problem space roadmap. So what is the sequence of problems that we’re trying to solve over time get in and as we go out further, those are getting to sort of higher our sorry, lower and lower sort of fidelity, but you know, broader space problems, where and what is the general direction that we’re taking our organisation and and actually find those are actually the most effective ones from a communication perspective. And then we maintain our shorter term delivery roadmap. Okay, these are the problems that we’re actually addressing right now. And that tends to have about a, like a quarterly kind of Horizon. Okay,

Randy Silver: 11:59

so after all that, really, what do you think, how many roadmaps? Should you have? Um,

Lily Smith: 12:05

I did this? Well, the thing is, it depends. I do think that there’s, you know, there’s a different type of roadmap for a different type of situation. And you can have as many as you need to handle and manage the different situations that you find yourself in.

Randy Silver: 12:27

Yeah, I mean, I’ve seen people who have one that’s external facing, and other ones that are internal facing. And once for different purposes. There’s some products out there some of the platforms, product management platforms like prod plan, or Aha, and things like that sometimes help you generate different versions of the roadmap, different views of it for different people. There’s one thing that I think we get confused about Sometimes though, some of the things that we’re talking about as a roadmap. I don’t think they’re actually a roadmap, I have a different term for it. I called them a release plan. So you know, a roadmap is that more general storytelling things thing, where you can do now next later and not have dates. But there are people in your organisation who need certainty who do need dates who do need you to make promises on things, or at least significant commitments. And I don’t feel that bad about doing that for the next few weeks, maybe even a few months, depending on the organisation, the maturity, how we’ve been doing on releasing things. But I think that’s a release plan. And that’s something that Christian criminalists talked about a bit.

Christian Crumlish: 13:38

Well, I think, first of all, I share a peeve with a lot of product managers that we get asked for roadmaps all the time. And what people are really often asking for is a release plan or a launch plan. And we like to try to clarify that and we like to do thematic outcome based roadmaps. So certainly, I tried to create a now next later type of outcome based roadmap in collaboration with my team. Having said that, I also think that sometimes product managers are getting a little bit on their high horse and lecturing everybody else about using the term roadmap and correctly just because we want to do it a certain way. And it’s sometimes better to recognise that your stakeholder, whether they’re calling it a roadmap or not want to know what are you building and when, when were we going to sit? When are we going to get to see it. And so I also try to be prepared to to share that information in a format that they can read. So I

Lily Smith: 14:28

love this, and I think I’ve had done a master talking about this as well. That our roadmap it has your your kind of themes and your objectives and your goals. And then if you need to have a plan with dates on it, it’s not a roadmap, it’s a release plan, and having the different language for those two different types of document or, or artefacts, I think really, really helps the whole business kind of understand And the difference between the two and what each different artefact is trying to convey. So, yeah, I’m all done with release plans for dates and like timelines and deliverables that need to be scheduled with dependencies. I mean, I have a project management background. So there’s nothing like a good Gantt Chart sometimes.

Randy Silver: 15:25

Just wanted one of the key things if you want to get all religious and kind of racy about it are a CI racy, not not. But if you want to get that way about it, in terms of who owns what, in an ideal world, the product management team should own the roadmap. But a delivery management team or a project manager, if you’ve got that kind of person should own the release plan. And it’s great to be able to have both and have them work in tandem.

Lily Smith: 15:54

Yeah, exactly. So Philips in the true crew also talked about having features on the roadmap, but he does it in a way, which I actually find quite interesting because it’s tied into the product roadmap. So it felt like that’s probably fine. If it is centred back on objectives, and what the product team are focused on, then maybe it’s okay to talk about the things that you’re going to be delivering in order to achieve that objective. Yeah, I

Randy Silver: 16:25

think a lot of us use more than one artefact, but we have different naming conventions for it. And I love the spirit of what Philips talks about, Philips.

Philips Nwachukwu: 16:37

All right. roadmaps are very important to everything I do as a product manager, because essentially, you’re using the roadmap to communicate strategy, you’re also using it to communicate product delivery, right in terms of features, the strategic partnerships and the wins, right. That’s essentially how I use them. It is very high level for me, in as much as sometimes I can cascade it down into a Pro feature. So you have the child, you know, the very macro size, product roadmap, and then I’ll have something smaller, much more technical, like a feature roadmap for future roadmaps, it’s usually shared between products engineering and design strictly. And then when you have the larger product roadmap, very, very high level, very, not not not centred around the technical things that is, you know, shared with the high level stakeholders to understand the strategic thrust of the product, usually over a period of six months to one year or even six months, one year. Ideally, you know, what feature maps I usually I break that feature map sometimes into Sprint’s or into quartiles, you know, so that’s essentially how I use product roadmaps.

Lily Smith: 17:55

The other thing I think about what Phillips was talking about is often when you’re working in an organisation that’s really used to focusing on feature delivery, as opposed to delivering against objectives and outcomes, it can be really, really helpful to include features in a plan. Stay with me, I know this is controversial. But then have your objectives and your outcomes aligned with each of those features, so that you’re beginning to train the organisation to understand, okay, we’re working on these features, but these are the outcomes that we expect. And then you can start to have the conversations which go, Okay, well, we were doing this to achieve this outcome, did it achieve that outcome? Yes or no? And should we actually have been doing something else which was more likely to achieve that outcome? So keeping outcomes and objectives on your roadmap, even if you’re being forced, in which some people are to include features is a really, really good way to begin to train the organisation to have the right conversations.

Randy Silver: 19:06

It sounds almost like like an opportunity solutions tree or some of the other things that we use to diagram all this stuff out. I think, you know, we come back to the same basic ideas over and over because they’re really good ideas. And we just express them in different ways. So there’s another piece to this. And that’s what the going back to what we talked about the beginning, what is the purpose of the roadmap and that’s really about strategy on a grander level and communication and alignment. So you can take things from the executive planning level, all the way down to the what are we doing next week or this afternoon level? And Mahir Shah had some really great advice on how to approach that on your show?

Maahir Shah: 19:52

Sure. So Brandon, interesting situation where we really like roadmap for for the next like two to three years before we roadmap for the Next, like six months, we decide what like objective we’re trying to like drive in the next like three years. And that typically means like just investing in one like area and not investing in five or six, like different areas. And then within that one area, we figure out, like, what is it that we should be doing in the next six months. And that’s our roadmap for the next six months.

Randy Silver: 20:21

So I love that I love what Mia here had to say there. I mean, it comes back to something that John Kohler talks about a lot about the idea of zooming in and out of being able to do tactical and strategic communication and thinking. And one of the things John has talked about is that a product manager has to be able to explain to themselves to the team to stakeholders, you know how the small tactical decision that you’re making this afternoon, relates all the way up to the five year roadmap, and then all the way back down at any point. And that’s that’s an amazing challenge.

Lily Smith: 20:56

And here’s what Cassidy fine had to say when we asked her what her roadmaps look like Cassidy’s?

Cassidy Fein: 21:06

Great, great question. So ultimately, you know, we teach this by the product as well. You know, roadmap is a communication and alignment tool. So, you know, I would say it’s less about kind of what it what it looks like, and what we use, and just kind of more about how we are compiling it as a team as an organisation as a business, and then using it as a artefact to kind of communicating that out to what we are doing today, which, you know, how we’ve shifted since I’ve been at Vimeo, and we will probably continue to shift as we see the need to is effectively kind of compiling those after we have a broader idea of product goals, of course, business goals, first product goals and objectives and key results that are going to set at each zone and each team. And then effectively, we have those teams and outline initiatives. We do a big kind of, you know, group therapy come together session where we figure out okay, what are cross dependencies? What can these look like? How do we sort of figure this out, given our current resources, and then that kind of all gets put together into one sort of magical document that we kind of call our roadmap, which is living, I think, in air table for now. But that’s really what we’re doing for now, you know, talk to me in six months.

Randy Silver: 22:22

So okay, that’s really interesting. We talk to Jeffrey Frederick and Douglas squirrel a long time ago, about about a few things. And one of the conversations that came up with them was about the idea of briefing and back briefing. And I think that has a lot to do with this group therapy and the cross dependencies and everything, it’s using this as a as a tool to generate an amazing discussion and find out where the problems are going to be before you start building them.

Lily Smith: 22:49

And I also love the fact that she references it as a living document. So it’s not a fixed thing. It’s something that’s constantly changing. And, and also that she’s like, this is what we’re doing for now. Talk to me again, in six months, you know, the way that you approach your roadmap, how you put it together, like it should be a kind of constantly reflective and evolving process that, you know, you’re talking to your team and the rest of their business to work out what information they need, how they need it, and make sure that it’s serving the purpose that it set out to serve.

Randy Silver: 23:27

So there’s something about roadmaps that inspires really interesting metaphors. And I think we should play these next two back to back because Janice Fraser and Petra really had some really good metaphors that they use to describe their approach to roadmaps.

Janice Fraser: 23:48

I love this question. Yes, I use roadmaps. I use roadmaps a lot. I advocate for them. And for me, it’s outcome oriented roadmaps all the way. I don’t like feature based roadmaps. I look, usually a couple years out, which sounds ridiculous, but I do detailed outcomes, detailed actions, metrics for like one month, sometimes two or three months, but usually it’s like one month ago, detailed, then mid level outcomes with some high level metrics for the next three quarters. And then very high level vision, directional outcomes, you know, for two years after that, and we maintain that kind of all the way through. So that’s, that’s how I like to do my roadmaps. It’s, I think of it like an accordion. So you open it up in the present, you know, month or present quarter, and then you go more summary level for the quarters and the years that follow and that allows you to really look forward constantly toward your future.

Petra Wille: 24:55

Oh, gosh, so the roadmaps that I’m using, I call them the onion roadmaps don’t go bullets. It’s nothing out there. I know I need to write a blog post about them. I actually, it’s something I use in my coaching. So the onion roadmap start with a small circle, and then they are growing in circles like trees or an onion. And it is like how you adding value over time. So they’re not so timely bound. It’s a bit like now next later roadmap but adding this kind of idea of how much value are we adding to the product? Every time we have a bigger chunk of work done or bigger release or however you will be calling it. So that is the idea. And you can really complex products could have various circles, kind of blurbs attached to it each other. So you’re combining several onions.

Randy Silver: 25:46

Okay, so Petra has not actually blogged about the her onion roadmap, but it is in her book, strong product people. And she’s got a couple of images. And she’s given us the link. So we’ll have them in our show notes. If you want to see what she’s talking about. They’re

Lily Smith: 26:03

amazing. And we’ve had so much topical and fantastical advice from our super duper podcast guests over the last year about roadmaps. But Randy, come on, hit me with it. What else are we missing out on? What are your top tips?

Randy Silver: 26:23

Okay, should I do one and then you do one? Is that sound good? Okay, go for it. Okay, my first one is, I’m going to make a defence of product operations, whether it’s an individual or a discipline doing it or just an approach. I’ve worked in way too many teams where everyone has their own roadmap format. And that’s absolutely fine at the team level, if that’s the tool you need to communicate to your team, that’s fine. But you need to get together come on product managers, we all need to get together, there are people who needed an abstracted view. And they can’t digest 20 Different roadmap formats, we have to be able to do one common one, to communicate amongst ourselves and to the people who aren’t in the minutiae of everything we’re doing every day. Okay, Billy, hit me with one of yours.

Lily Smith: 27:07

So mine is my first one is very aligned with what you’re saying, which is to keep the roadmaps accessible to as many people as possible. So don’t squirrel it away in a folder structure somewhere, or in a tool that some people don’t have access to, like, make sure that everyone who is interested can and does find your roadmap and like, keep bringing it to the surface, they keep directing people to it. Yeah, it really frustrates me when there’s not a way you know, if you’ve got it in like an Excel document, I didn’t know or Excel who uses Excel. I mean, you can use Google Docs or whatever. If it’s like buried somewhere, and no one knows where it is like, that’s not, that’s not good. It needs to be accessible. Okay, I’m gonna give you my number two. Okay, this is kind of similar to number one. I also think that you should definitely invite questions and feedback. And you want people to understand what you’re doing and why you’re doing that, like that’s the whole point of your document. And it can be hard to communicate that in one visual. So allow time for discussion. Keep a channel open, that allows people to ask questions, what about you, Randy?

Randy Silver: 28:24

But I want to build on that one. Because I think there’s the view sometimes that the product manager is like a monk who goes away and receives a vision and comes back with a roadmap and communicates it to everybody else. And that’s a terrible, terrible idea. It’s a group exercise. This is a team sport, I mean, you may be as the product manager, you may own the document. But that doesn’t mean you’re doing it by yourself. It’s a group exercise, you know, your business owner needs to look at that strategy and work with you and agree with you on it. But you have to, at a very early stage, talk to your dev team into your delivery team about it. First off, they’re the key driver for the immediate future, you know, you’re essentially writing a check that they need to be able to cash, otherwise, they’re going to hang you out to dry, you’re just going to look silly, on that. And they also really need to be involved in the future and looking at it because they’re going to be making architectural and structural choices that involve how they’re going to build for the future. And if you are you looking to grow a lot or change something key, they might need to replatform they might need to make a big strategic change that you need to invest in in the underpinnings of your product. And you better put in the time for that. Okay, so you did two in a row. I’ll add one more, which is so against something that goes with now next later really well. But one thing to keep in mind is as you go further into the future, increase the level of vagueness, you can talk about some thing as a definitive commandment for the things you are in the process of building right now, if you’ve got OKRs, for the current quarter, or whatever you’re doing, you can talk with a certain level of specificity. But for anything further out, it’s we have an intention of doing this, it’s going to be in this range. Don’t commit to a specific date, don’t commit to a specific number. What about you, Lily?

Lily Smith: 30:21

Yeah, I love that that’s really, really useful. So I also thinking about the kind of the usability of your roadmap, like to ensure that you use language that is familiar or understood by everyone. So no acronyms, although if you’re, you know, space constrained, you might need to use acronyms, but at least have some, like, what are they called legends, or I don’t know, something that just explains what those things mean, you’d might have new people who start in the business who aren’t familiar with acronyms or you know, just need a bit more sort of a bit more of a walkthrough. So just make sure you’re using the right language. And then similarly to what we were saying earlier, I’m now going to like go into my number four, which was, we talked earlier about how the difference between a roadmap and a release plan. So using the right kind of language to describe, not just like the stuff that’s going on, within the document, but also what the document is for, I think will really, really help you circulate and communicate your roadmap to people in a way that helps them understand the purpose of it. So I hope that makes sense. That feels a bit Wofully. But yeah, that’s my kind of just reiterating. Keep now next later for your roadmap. And if you need dates, and you need to put together a project plan, God forbid, you’re a product manager, and you need to do a project plan, which occasionally happens. Call it a project plan, or a release plan. Don’t call it a roadmap.

Randy Silver: 32:03

Yeah, I think that’s great. Okay, so let’s come back on language. And one of the key things is, as you just said, this is a draft. Everything that you put out, there is always a draft, no plan ever survives. contact with the enemy, as they say. And so things will change, they may change by hours, they may change by days, they may change my months, you may scrap things entirely. So the one of the key things in the way you talk about your roadmap, is that this is an intention. It’s not a promise. And maybe we’ve even made a mistake, calling it a roadmap, because it’s not necessarily how we’re going to get there. Sometimes it’s about where we’re trying to go. The description of the journey itself may change. You know, if we’re talking about a roadmap, you take that you’re trying to get from A to B, but there may be a flood, a tree got knocked down on the street, that leaves my house the other day, and we do turn up the different way. That’s fine. We still got home, we got home to a little bit later. But we still got home. And that’s one of the key things. It says an intention. It’s where we’re trying to go. It’s not necessarily how we’re going to get there. And then finally, let’s go all the way back to the beginning of this conversation. This is a tool. The artefact itself, the piece of paper or the document is not the point. It’s the conversation in the understanding that everyone has, ultimately you may need to document a common reference point for people to come back to. But that’s not what it’s about. It’s a tool for generating understanding and good discussions. And as long as you can do that, and come back and make sure that everyone agrees on what you’re trying to achieve, and what you’re doing about it right now. Then you’ve got a great thing. That’s all I’ve got.

Lily Smith: 33:55

Randy, thank you so much for joining me on the podcast this evening. It’s been a pleasure.

Randy Silver: 34:01

It’s so weird hearing you say that to me. Billy, it’s been a pleasure. Thank you for having

Lily Smith: 34:13

me. The product experience is the first and the best podcast from mine the product. Our hosts are me, Lily Smith, and me Randy silver. Louron Pratt is our producer and Luke Smith is our editor.

Randy Silver: 34:34

Our theme music is from Hamburg baseband pow. That’s P AU. Thanks to Arnie killer who curates both product tank and MTP engage in Hamburg and who also plays bass in the band for letting us use their music. You can connect with your local product community via product tank, regular free meetups in over 200 cities worldwide.

Lily Smith: 34:55

If there’s not one near you, maybe you should think about starting one to find out More go to mind the product.com forward slash product tank