Do User Stories Have a Place in Product Management (With Tara Wellington, Bill ex-GoDaddy)

One of the great processes actually learned from the CEO of Go Daddy, Aman, he brought this concept of an inception, and now I'm obsessed with them. Because what it does is it takes an idea and it breaks it down into work that you can execute. So that everybody understands fully and they kind of do that breakdown process. But you do write ethics and you write stories through that process. The thing I love about it so much is that everybody can have a different interpretation of an idea. You can all be like nodding, yes, we're on the same page, yes, we're on the same page, but everybody has a different thing in their head. So when they go do all the sudden you're perfectly online team is running in four different directions. I think that the writing down is so critical. because it actually puts pressure on the like, are we saying the same thing? Did we actually mean that? Like, are we aligned? Because we may think we're aligned, but until you put it on paper, I knew actually go through it. Together, you don't really know. Welcome to the Product Adility Podcast, the missing link between Agile and Product. The purpose of this podcast is to share practical tips, strategies and stories for more class, thought leaders and practitioners. Why, I hear you ask, well, I want to increase your knowledge and your motivation to experiment so that together we can create ever more successful products. My name is Ben Maynard and I'm your host, what does driven me for the last decade to bridge the gap between agility and Product is a deep rooted belief that people and products evolving together can achieve mutual excellence. Hello, welcome back to the Product Agility Podcast. We are joined for the second and final time. Not ever, maybe. And again, episode two takes a dark turn immediately. We are joined. Once again, by the one only story teller supreme Tara Wellington. Who was in episode one, joined us and spoke about storytelling as a product manager and shared a story from who a time ago daddy. And since go daddy you've been at Panda Dockin now you're at bill .com as well doing some senior product person awesomeness and we are joined again because we are going to be talking about At least at the beginning of this episode, use the stories. Use the stories I think are one of the most misused, abused, misunderstood techniques that I think I've ever come across in my 20 or the years of working with products and tech. So I am a super keen to talk to Tara because she released an article towards beginning of this year, which was let me see just get the actual proper title before I make something up. Where do you use the stories fit in the product development process and as part of that you shared. Some common pitfalls and this really peaked my interest because user stories are the most common or yeah, not those common technique that you find like Product professionals talking about agile people, talking about them a lot, but when you talk about how to get a product, people, it never really bubbles to the surface. Yeah, I was intrigued, Tara, and I want to know, what was it that made you write this article? for a forge. Yeah, so one of the great things that Reforged does is that they really listen to their audience as all great product people do and they can pulse them on what they care about and what they're interested in and what problems they have and things that come up that are concerning or they see questions that are repeated all the time. So this was a topic that was coming up a lot with the Reforge audience. So the reason Bruno, Givia and I spent time talking about this is because it was something that the audience cared about. And that was why we wanted to talk to it. So it wasn't us going off and talking about, oh, we know our teams and the product folks that report to us are Miss using user stories and they're not doing things well. It was more around folks having some deep questions in the Reforged community about it. Are they wider spread? Do you think that I perhaps gave them credit for the introduction? Well, I think user stories are... I mean, everybody knows them, right? If you're in the product world, you've come across them whether you use them all of the time or you use them sparingly or you use them never. You've seen them, you've heard about them. They've been part of your life. Somebody you've worked with cared an awful lot about them. So I think it is important to talk about them because everybody has an opinion on it, but there's no... One great way to think about it, right? Do you know what I hate them? Right. Bear with me. There's method to my... a piece against these stories. I hate user stories as a thing when it's like, oh, this is a user story. Because I think that as soon as it becomes a thing that like a tangible thing you can see, I think the power that is lost. Because at that point it's just like a small written requirement. And what's they hate when they become the thing? I love it when I think about it as a process. I'm not going to be able to do that. As a technique. And I quite enjoy things that use story mapping. Because you're saying it, what's the story of this user when they're going to be interacting? What's the problem of looking to solve? And I think that. Here in the story of the user, I think is really, really valuable. I think user story is a neat technique which is quite easy to pick up. as well documented and like I said, he's a huge amount of value in that but I hate these stories when they become just distilled down to a thing and that's it because I think then you've lost the power of... What was I believe initially? It's a technique, isn't it? Artifact. Yeah, when we were talking about writing this story, I was actually... shocked at the absolute vitro people had about these are stories. I couldn't believe how passionately people disliked them. And I think that that really comes from the fact that they are misused a lot. And I think if you... If you look at it in real world practice, it is probably really frustrating because people are using it, they're just going through the motions, right? Here, my user story is to toss them over the wall. Here are my user stories. Go work on them, right? And so they're misused so much that I think this is where this side. intense reaction people have about them as a concept comes from. I think I didn't have that reaction. Because I like the spirit behind them, right? Even though they're misused and even though they can have this. really dogmatic approach and feeling like they're very process oriented. I think the idea of making sure that the work that you're doing has a customer perspective and I should be able to as a customer as a whoever is in their part of the story. They should be able to do something so that, right? So there's a customer intent in it, and there's an outcome in it. And that I think is really noble, right? We should every time we're writing a line of code. Every time we're thinking about a feature and value we're delivering, it should be attached to who we're building it for and the purpose. of that work for them, right? And so I love that, I love that spirit. Now, the problem you have with that is that people are like, oh, I have a format, let me just fill in the blank, right? I'll put it in the spreadsheet. I'll put it in the spreadsheet. I'll do a full -me -down. I'll put in my gearticket. And then it just becomes this thing you have to do. Or people are like, oh, let me just go right up 100 of these. And they use it as a replacement for things like really great. research and really in -depth talks with their engineering team around why this matters to the customer and why this is something that's important. or they use it to push an narrative that they care about versus something else. And so there's I think it's the misuse of them that is more of a problem than the actual story itself. Who cares, right? Who cares if you're ready in this format? It's really about getting across why this... Work matters in a written format. Reminds us of our previous conversation. You know, it allows people to build empathy. We have the subject whoever the subject might be and I think that's what it was written down. It doesn't really matter. And I think this is where sometimes When there's, I'll make a confession. That's the beginning of this little session with a big confession. When I first started working, in a product role. Oh my god. 15, 16 years ago maybe. Yeah, I shouldn't have been in the role. I shouldn't have been. I shouldn't have been, but I was like the least shit person we could find. to do for job. And I was working with the Scrum teams and we were building, we were effectively going to be putting this need, need products into this organisation and long story short, I thought what I needed to do was write a big backlog full of user stories and hand it over to the team. And I toiled, you know, I toiled for a week if not longer in Jera's, trying story after story after story using epics and relics relates to and it depended on and did all this crap. And then I start having a team get a sense of what you're doing. I'm working on your backlog. And remember I handed it over to the team. They're like, this is absolutely useless. We've got no idea what any of this is about. So we've deleted it all. This archived all the backlog. My week of work just put it all chucked it all away because it was at that point I realised that actually the most effective way for us to build this backlog of work. given that we know what we have to do is to let the team talk to the users and let me help them have the conversations and they still chose to use the user story technique and the template every us, but I might rather became one of building a relationship and helping to facilitate. and steering when needed rather than being in the middle of it all. I will say I don't think your confession is unique. And I think that everybody, everybody their first time they're in a product role is one of my supposed to be there. How would I get this job? Because you could. go to school for product. I mean maybe now, at least when I was getting into product, you can't like graduate with a product degree. So I love talking about people's background into product because everybody takes these super funky ways into it. But I did the same thing, right? When I first got into product, I was like, all right, I should be able to sew that. I'm like, do the format and because... You have to fall back on structure when you're learning because you don't know the nuances, right? Like, product is this kind of like art and science coming together and The art is something that's really hard to teach somebody and you have to do it to like learn it. And go through the motions and understand how all of these different pieces work together. But I think the user story, the story itself isn't the problem, right? Like in that, in the... piece that you just communicated, right? The fact that it was only the story is the problem. Like, user stories alone don't get the job done, right? They're not an effective communication tool. They're a documentation tool. They're a process tool so that you can say that I did we do this did we cover this did we cover this but they're not a why they're not a supporting evidence they're not, a here's the bigger picture, right? And those things have to be communicated. You have to have conversations with your engineers and your designers and all of the folks that are working collectively on a product. So everybody has context, everybody understands the why, everybody under, they've heard the story, they've had the storytelling piece, right? And then it's like, okay, we all agree and we're all aligned. And then what are the details, what we have to do? Okay, put those in this user story, but they don't get the job done alone. And I think that's one of the biggest problems. Now you do say in your article and I'm going to discuss it here while I read it. And I anxious product lead was spent too much time trying to create the perfect user story. At the average stream, the overzealous product lead was spent too little time articulating their thinking. I mean, I'm pretty, I'm pretty quote there. I think that really brings it home. So what is the thinking about the article, thinking about the three pitfalls that were mentioned in the article as well? What's the middle ground then? Can we move? Somebody just with little experience, understandably leaning heavily on the structure and then just trying to create the perfect user story. And then the other extreme, which is the sea overzealous, maybe the slightly inflated self -worth product lead, you know, it doesn't take that thinking just so you can just bash some stuff down the hand over. Now, what's the middle ground? And how do you, how do these pitfalls you mentioned in the article? How does it all come together into some success? Yeah, I mean, like everything else in life, right? This moderation. So I think it's about where in the process these are stories fall, right? There is something to be said about being thorough and your requirements, right? And if you choose to use user stories, you have to make sure that they are accurately reflecting what needs to get built, right? So there absolutely is a time and a place for us to have a written record. of what needs to get done in a way where we can be like, check, check, check, yes, this is all there. But again, that's one piece of the product development puzzle, right? There's what comes before the user stories. which is the research, the understanding, the purpose, the why, what are we trying to accomplish, what are the goals that we have? How do we make sure that we're taking that, breaking it down into something we can actually build and deliver? That all comes before these are stories. And then there's after these are stories, right? Okay, we wrote them. We've handed them over. Check your trick. They're all done. Well, do they work together? Are they accomplishing those goals? Are they flowing together in a way that's solving the original thing we tried to solve? Are we testing them? Are we experimenting? Is this working? Right? So it's a piece of a puzzle. And if you spend too much time there and deep, deep focus on the user stories and you don't do the pre -work, That's not great. If you skip it over all together, that the postparts gonna be hard. How do you know exactly? Like how powers your team going to know how to get to those outcomes, how to build that experience, how to make something that reflects the need. There's a balance of, okay, there's not over index on them, but there has to be some written record of what we're going to go build, right? And user stories is one format. It's a very popular one, but if you have another way to do that, they find this effective. Sure. But don't skip that stuff, right? Use a story as part of the puzzle. I got to figure out what puzzle we're talking about here, because I think use a story as you are ticketing it then as part of the... Overall, product journey in a product organization or organization which has good product mindset, product sensibilities, I think using user stories when you've got a great research happening at the front and you've got some effort. at the effort afterwards, which is trying to in some way include your confidence for the hypotheses. that your work was based upon is actually returning the value you expected or but there's some learning of something you can do with that. And I think that kind of prep work, that the research, the validation of the hypotheses, sticking new stories in that puzzle. Yeah, I can see that time together. Because it got me to thinking that perhaps part of the issue is it's when traditional tech mindset organizations where it's supplying demand between products and or tech or kind of subservient and they're given user stories as a replacement for some other kind of specification or requirements document the people that write and view the stories as much as they would love to do things differently they're just told to go and do the work and hand it over. And so I wonder is this user's droids in the product environment can be pretty sweet and can be a nice part of the picture. But when you move into a more tech focused organisation where there are side -ows which aren't working well together to create that holistic product and see how things come together. That's where some of the challenge of user stories comes from. Yeah, absolutely. I think it's interesting in the companies that I've worked for, you know, every company has great things about it and has challenges, right? And I've been in some environments which were very heavily documentation -based because it was like, write it down and give it to me and I'll go do it, right? But they're missing the communication and the talking, right? And I've been in other places that are like talked all the time. They're always chatting and this and that, but they never wrote anything down. And so it was really hard. But it was like, what did we agree on? What did we say? How do we have a weekend to do this? And so, What you really need is you need both right you need to be able to have the conversation you need to be able to make sure everybody's on the page have the alignment. Give people a chance to discuss and ask questions and understand more deeply and then you have to write it down. And you have to think this is what we're going to go do. Everybody read this, make sure we're alive. Are we all agreed? These are the things, right? And user stories are one way of documentation of writing it down saying this is what we're going to go build, right? It's not the only way. But it's one way and if people like using it and it's effective, I don't see any harm in it, as long as It's your communicating and it's you're doing it within an overall private development life cycle that has Discovery research and then also iteration. To two things pop into my head and one short anecdote I was working for a very large UK bank called, well back then it was with the Royal Bank of Scotland. And I was a kind of touring kind of product, agility coach, I suppose is the best way of putting it. And I was just kind of like people would phone me up or send me an email and my boss would like, ping me out somewhere. And it's brilliant. I've got to see all kinds of different pieces of organisation. And I got a message from someone saying, oh, can you come and spend time with our agile team? They're having problems with their user stories. Sure, so I won't set down with them. I said, Craig, okay, so Tim, talk if you're doing. But we've got this spreadsheet and we've locked writing and all views and stories and then we need to get this complete and get all views and stories written. Okay, okay, fantastic. Maybe I have to attempt to look through your roles like who's developer, there was testers like I was told to be through this team and I was like, I know we're all just analysts. What do you mean? I was like, no, we're just analysts. Equip Amar .�� sapgars I canolaeth fel tekir. Mae 'n gallwstị fel bnod nhw. Mae sgigolabhydd mewn gwneud i bleu. Mae 'n gallwst CPAY And when you hand over a very developed it's going to get to like elixit with the users and well we haven't even set with the users. Okay. I'm going to get to sit with you to understand it. I'll know we'll be working on the next backlog then. I said, okay. I said, do you think? Yeah, I said, I said, I said, I said, I said, I said, but it's a great respect. But what's the probability of this working out, do you think? And they're like, First to zero. And I was like, wow, okay, okay. So you're not even you believe this is a good idea. So. Yeah, the nice thing is I spoke to the program sponsor and just said, look, I just replayed that conversation and they cancelled the project and I thought that's the best decision you've made. I think you've played. But it was just crazy that, yeah, but people do just see it as a replacement for a requirements document. And what we're saying is that that is not the case at all. Now, and I think we also have to remember that every time we're putting something out there, it's a hypothesis. Yes. We don't know if it's going to work. We haven't educated guests. We've done research. We've done some things to inform ourselves. But we don't know if it's going to have the intended effect, right? And so the story. is at the story level. Okay, here's what we're going to go build to test this hypothesis. But it doesn't, it should never be like, this is the end. Yeah. Right? Like this set of stories is the requirements. We go build it and we're Oh, done. because then we met the requirements. Yeah, because then I started interrupt and I started talking to him. It's good to say all of a sudden, yes, because then you never need stupid conversations where people say, well, The backlog needs to make you need to make sure that the use story is up to date. Why? Because we're not delivered with your 7 -0 -0 -0 -0 -0 -0 -0 -0 -0 -0 for a back -to. I'm right. Well, that makes no sense. But why? Well, because what if I did have something in this story and then actually by the time we get down to this one, we're changing the family to have a done because incremental like something might change? I've asked no good is it? Well, no, like this is that old school thinking is it's not a requirements document. It's not a specification. It's not something that you write and then you hold people to and then you use that as your documentation for what's gone out. They're not designed to work in that way. Yeah, so your backlog should be a living thing, right? It's living, breathing, changing based on your learning, based on the strategy, based on your goals, right? It's always going to be adjusting. That's good. That's what it should be. I think there are things around tracking that can be helpful for understanding like throughput or understanding how often are we changing scope or Are we estimating well? And that's where it's like, okay, here's a story, here's the story of points, right? Let's understand those things, but let's not hold ourselves to it in a way where it's like, when you said it felt this, Even if it's wrong, I don't care I'm building this, right? It's that that goes against everything that we're trying to do. and delivering value to the customer. Because we're not delivering work to the customer. Our goal is to deliver value to the customer. And that takes learning and adjusting and iterating and trying and changing, right? And my one thing I always say is our product should be its worst the first time it goes out. I know that drives people nuts because they're like, why would we put out something bad? And I'm like, we're not trying to put out something bad, but it should get better. It should start getting better the day it gets in customer's hands, right? You always wanted to be getting better and not worse, and that's because you now have customer learnings that you can constantly be getting. Yeah, pulling back in. and weaving it through, which is why the whole, yeah, your product work is always evolving, it's always changing, what you did now isn't, yeah, you'll go back and change at some point because you'll find out that actually, Your hypotheses was incorrect and this then goes back to that arrogance -driven kind of approach is to think that it's going to be you can document this down and then deliver it and it's done and that's exactly what it was. It's just very naive. The only thing Kavi had to open on that, actually, so great talk at. I think there's a women in tech conference, and they were talking about. the high the stakes of your product development. And they're like, look, if you're working on postmates, it's probably different than if you're working on. self -driving car. Yeah. Right. Like capacity for not getting it exactly right like you have to think about your state. So there's a copy. Yeah. That you're right. You're right. And you want to like medical equipment or something. Yeah, it's really interesting and you're right there is a risk based approach to it. If this goes wrong then what is the worst going to happen there? Can we afford to rework this? Do you want to rework it? I think that if you start up. There was a small company, not a lot of funding or people. You know, you want to be doing stuff that you have the highest confidence you can get away with. It's going to be okay. You're going to learn from that and change it. I suppose if it's things aren't so tight you can afford to be a little bit more frivolous because you can't afford to rework it and go back but there's also situations where the We're a level of alignment on the problem you're solving and what it is you're going to do to solve that problem is so high that you can just write a spec or you don't have to use a user's story because the alignment is there, you don't need there's no learning to be done. Yeah, I mean, there's sometimes things where it's like, well, yeah, let's not overanalyze it. This is just a go do people hate this. I know about what I do think there is I've worked in some organizations where There's this feeling that there's a lot of pressure to deliver more and more and more and that once you finish one thing you have to be on to the next and there's no time for that. If there's some time for that learning and improving and that I think does get people on this fear state of like. It has to be right before it goes out, so I'm never going to get a chance to work on this again. Alright, and that's a scary mentality. because it actually does slow you down. It prevents learning and experimentation and testing and that's, is you know, where you get people going crazy over every little story. So, like, it has to be perfect. And it's never going to be, right? Like it's an S. It's always a hypothesis. And if you're spending that much time going into it, and maybe this is my experience and my bias, and I'm not saying this is a universal truth, but if you're spending that much time trying to get it perfect, then I don't see how that's going to be based on the right actually talking to the user because your research that you've got will go so far and you'll do it, you'll have a good punt at it. And then you want to go deeper and deeper and deeper, it gets to put, but you're just fabricating stuff to try and fit into it, surely. And then you're getting further away from the probability that it's going to pay off. Now, there's one that the pitfalls mentioned in the article, which is fabricating user story to force fit into a product hypothesis. What was meant by that? I think this one is that people are holding too tightly on to what they think is right. And so again, they're using the user story to force something to work when maybe it's not the best decision, right? But I think it comes back to the conversation we had earlier of a static backlog and not listening to the feedback and not being able to adjust when you have learnings and we have other pieces coming in. Yeah, I mean could that be when there is there's work which someone feels needs to be done but doesn't perhaps align to the goal you're currently working on somebody. They're writing, they're trying to shoehorn it into that current objective. Yeah, absolutely. You mentioned earlier that user stories are more more to do this and wondering if you could never use these droid technique again. What are some other techniques or some other ways of kind of capturing this information that you would find useful? Yeah, so we've been doing a lot of written form, like long form written documents that my last two companies that give a lot more context in the documentation. So we had talked about the user stories in the middle, the context for it and like that. the iteration I'm working after. If all of that context is written down and documented in a way that it can travel, it's not always in the storytelling format, but it's It's fully embedded in all the pieces. Then you can have like a much more narrative structure, rather than just like the hit bullets. But I think it depends on your organization. and how I think they want to work and their time and capacity to read and absorb that way. versus having like time carved out to have the discussion and then have us. more succinct way to hit through the work that we want to get done. So that's one way, another way, and like a very creative setting. All right, you could pose instead of as the PM coming up with the requirements, right, and writing the user stories and even with all the context. still canning over some documentation of it or writing the jurisprudence of you could have more of a live session where you're saying okay we want to do this and we think of this I mean you're kind of talking through your stories but you just sort of do it that way. as more collaborative versus the documentation of user stories. I'm writing it all up. You still have to document it somewhere. Yeah. I think that's one of the important thread that I'm noticing what you're saying and this aligns to. How I think it's correct as well is that we're not talking about with anything to use a story or collaboration is just talking. And we're not saying it's just. writing stuff down, there is a balance to be struck between talking and writing. And if it's important to write down, because you're going to forget it, I've absolutely documented it, but it shouldn't be then in place of the conversation. Yeah, absolutely. And I think writing it down is really critical. One of the great processes I actually learned from the CEO, GoDaddy, Aman, when he came to GoDaddy. He brought some team members with him and they brought this concept of an inception, which I had never done before, and now I'm obsessed with them. Because what it does is it takes an idea and it breaks it down into work that you can execute. So it's really good at Taking a strategy or a concept or a process and breaking it down so that everybody understands fully and they do that breakdown process. But you do write ethics and you write stories through that process. And the thing I love about it so much is that everybody can have a different interpretation of an idea. And so you can all be like nodding yes on the same page, yes on the same page, but everybody has a different thing in their head. So when they go do all of a sudden, you're perfectly in line team is running in four different directions, right? And so I think that the writing down is so critical. because it actually puts pressure on them. Are we saying the same thing? Did we actually mean that? Are we aligned? Because we may think we're aligned, but until you put it on paper, and you actually go through it together, you don't really know. Right? Because people interpret things in very different ways. Even the term user stories, probably got five people thinking of different things in their head. Maybe is that not then just the crux of it is that we've all got different mental models, values, beliefs, biases, like them things that make it up how we see the world and actually some of this is how do we, what tools can we use to help articulate our perception of some information which we're supposed to be processing? Because we're all going to be processing it differently... Sometimes we get it absolutely bang on and we all agree without it being any extra effort required. Often turns out that we're actually on different sizes of the globe and our understanding of a particular word or phrase. And it's what can we do to get something down in front of people? Whether it's a picture, whether it's telling a story, picture, written story, something written down, there's something to base that on. Yeah. And it's really critical because, parking back to the conversation we had about storytelling, everybody has a different thing they care about. And they're all going to see what you're talking about from the lens of this is what I care about. And if somebody's I care about speed. I care about quality, I care about the design consistency, I care about the user value, right? They're all going to be like, how can I get what I care about out of this thing? And if you don't all agree on paper, all exactly what that thing is, it can get kinda messy, right? And I've been in so many situations where, That happened. That exact thing happened. And then I get a note, I'm like, we, a week ago, we were all aligned. What happened? Like, how are we in this position? Didn't we all agree on this? And everyone's, yes. But you didn't tell me this thing. You didn't say you were going to do this, right? And that's where the articulation of the details and some sort of format like users for help's for pressure on. Yeah, it's that journey. That journey to ensure alignment and to flush out the inconsistencies, right? I mean, we're only human. There's There's a game and take the game and exercise that I play in some of my courses and I did it this week with a really large UK broadcastable channel for working with their social media teams like not not tech And you think that if their product would be never releasing, I would say their product is almost every short clip they've released across all the different platforms. You know, and this team have been incredibly successful. There's more. They've had more hours, I think more hours and more minutes of their content watched on Facebook than there are people in the world. You know, they are phenomenally productive. They're getting like 9 .0 billion and billions of minutes of their shorts they've created been watched. From that, there's pumping on the session media networks. It's fascinating. Like a really high -paced, responsive environment. And, I did this exercise with them where they had to, I gave them a really simple picture of edge of right out of specification for the picture. And then, without a specification out, give it to someone else and they had to basically care out the specification and draw the picture. And people are more successful than they thought. And the second time around, they get to sit next to each other. And the person who is drawing is taking verbal instructions and feedback. And the whole idea of it isn't that writing stuff down is wrong, but everything has to have a verbal conversation. It's actually, they realize it's a huge amount of benefit in having a little bit of something written down. So at least it's frame, and people understand it. But they're actually working with someone to have the conversation and get some feedback to make sure that you are aligned because what I did this in the course and a very good friend of mine called Ben, not me and then another Ben took the picture and on the picture there's six different shapes. And he wrote, I believe it's what he wrote, draw a rectangle and inside the rectangle, there'll be six figures. And he meant like there's the six objects. And the rest of his handwriting, I'm not sure how legible it was because what the person drew was effectively like a little American football team Because they took it as figures meaning people And just really is people and I thought it's just amazing how the single word gets interpretive is so wildly different. And if we're going to wait a month to see that, then who knows what position we'll be in, actually getting that quick feedback. is important. I think that's the, what I'm different taking anything away from this Tara is that it's documentation and it's conversation and it's making sure that mental models are aligned so that we're not in that with unpleasant surprises. Yeah, absolutely. Now we are almost at time. And I would love to know Tara, what has been your favourite moment of the last two episodes? Oh, can we now talk about the Segways? You can talk about the Segways, because then they have to, they can't leave you at it, can they? Well, obviously the Segways. No, I liked how the user story discussion really became a conversation of communication and documentation and the balance of that. Because I think it's really critical and companies have a culture. that often time leaves one way or the other. And I think it's product leaders and product folks, like one of our key roles is to make sure that that's balanced. Like how can we do that in an effective way? Beautiful. Thank you, Tara. It's been such a treat to have you on. Even though this is our second attempt, because we did try and record an episode way back when months and months ago, and it was all set up. It was a July hour. I was in a fancy location. I'd hired a special podcast in recording studio, and my laptop wouldn't work, wouldn't let me record it. So we had a lovely warm up conversation, and then didn't record a second of actual content. So it's just so great to have you here. And there's such an interesting career. And these episodes... Could have absolutely been about a number of other things, right, because you are a font of knowledge and the end experience. Now, you know, personally, I would have loved to have dealt into some of the panda docks times, but I think maybe that's a conversation for when I come over and to New Hampshire and avoid bears one day. Yeah, there you go. You're welcome. Anytime. Can drink pumpkin beer. Yeah pumpkin beer and bears. That's a great way. Yeah I'll bring it. That's a great introduction to your hands. Okay so thank you so much Tara. That's fun. It was fun. It was fun. And I did a one day I'd love to do this in person. Yeah, I can learn a lot from you. So thank you so much for your time and your patience because I'm sure that the bloopers won't make it into this episode. But a few things happened along the way. That was great. And never with anyone else, and I mean that. So Tara, thank you so much. I'm a fantastic rest of your day. Everybody, thank you very much for listening. And we will work me back again next week. Thank you Tara. See ya, bye. See ya. Stop listening yet. Tara had a lot of great things to say, but I've got a few things to add. First of all, Tara is a legend. I'd recommend checking her out wherever you can do. Maybe in the previous episode, but we were talking about storytelling. Maybe you want to read us a divest episode because of what the golden nuggets that were exhumed from the earth when it came to looking at documentation versus verbal communication. But the thing I really wanted you to hang around for is to share this little tip. We have got a gentleman named Nigel Baker coming on for two episodes. A Nigel is someone that has been around in the product and agile world for many, many years. He's an extraordinarily funny and engaging chap. He has a huge love for all things, 1980s and retro. So if you ever want a conversation about the 18, huge amount, he joined me for two episodes. And I have to apologize to Nigel, because it's taking us a little while to get these episodes out. So I'm really really excited because Nigel, he precedes himself. I think that was a compliment. He is funny, he is engaging, he has got so much character and some strong opinions and it was a joy to have him on. So you're going to really love listening to him next week. So without any further ado, I'll let you get on with your day, finish off your walk, your run, whatever it is you happen to be doing by saying, I am Ben Reynault and this is a product agility podcast. I'm Ben Reynault.