Bootstrapping a startup with user story mapping - Interview with Avion.io

Welcome everyone to our fourth episode of the Product Bakery. Today actually a very special episode as it's like the first time where we have real guests sitting here with us. It's some metaphorical sitting because they are far away outside of Europe in the UK. And yeah, hi James, hi Tim, welcome to this episode. Hey, lovely, lovely to be here. Awesome. I will pass it over to Christian so he can introduce you guys. It's also a topic that he is really interested in. Yeah, hi everyone and hi Tim, hi James, nice to have you. You both are the founders of Avignon.io, a story mapping tool that helps product teams to build great products. I remember when I talked to you first half a year ago, you told me your interesting story how you got started with user story mapping. Back then when you both were working at an agency, you needed to build many story maps for your customers and clients and you were obviously faced with the problem of not having a good tool in place, which you transformed now into your mission and helping product teams. Tim, my first question is actually what did you tell James when you come back from your product owner course and the first time learned about user story mapping? To be honest, I didn't actually tell James anything to start off with. So just to give some context with how that all came about, I was kicking off a new project with an e-commerce website selling frozen ready meals online nationwide to the UK and yeah, I was looking for a way to manage our backlog in a fashion that made it like, you know, more sense really than a flat long list of user stories. And as a result of the product owner course that I was on, there was a mention of story mapping, which I then took away with me and then further researched that in my own time. So I took that and then applied that to the project that I was working on. And I guess really the methodology just spoke for itself. The fact user story mapping just made sense. And as a result, spoke for itself and spread naturally throughout the rest of the agency. And obviously there were things along the way that was helped out, pushed by other people in the senior management teams. But ultimately that's how it spun off from there, I guess. And it spoke for itself across the company and it became a bit more of a cornerstone of our delivery processes because it's such an amazing way of trying to figure out what's the scope of the project that we're working on and how can we get everyone on board. And I'm sure we'll talk about all the benefits later on. But yeah, that's kind of how it spread. And I didn't actually thought it's worth telling James specifically, oh my God, you need to start user story mapping. This is how it works. It just kind of spread naturally, really. James, what was your first reaction or how did you actually realize that you can do more out of this methodology than just using it in your day to day business? When I first got introduced to story mapping, again, a very similar background to Tim working at an agency. And I don't think I fully used it to its potential. I just saw it as a way to organize things, which is really nice. And we all need ways to organize things in our own head and to be able to present them to others. But it was when I really, I read Jeff's book and I really began to understand what story mapping was about. And it was at that point that I used it on a project and used it not just as a planning tool, but as a way, not just as an upfront planning tool, but as a way to drive the backlog consistently. So it actually became part of the process, the development process. Whereas before when I'd used it, it had just been an upfront planning tool that would be done at maybe a kind of a UX or user research stage where we would define some kind of some flows roughly, and then just push, put some stickies under them, like post-its on a wall. But it was when I realized that there was the power here to be able to have this sitting in the middle of our workflow, where everything passes through the story map as a filter to say, is this something we should be building? How can we build less? How can we deliver more? And that then goes on to feed the backlog. So I think it was that moment. It was that sort of magic kind of moment where I realized that it's not just about upfront planning. It's not just about sticking post-its on a wall. There is a methodology behind it that can really work, work well in the delivery process. So James, one question from me here, you mentioned UX processes and flows on the wall with a couple of sticky notes. So what I'm curious about is like, how would you describe the key differences between user story mapping and for example, the methodology that UX designers would use that are more around user journey maps, customer journey maps and mapping out like all these different steps in between? We see a lot of this actually is people bridging customer journey mapping and user story mapping, and sometimes actually using the story map to input more of a customer journey map. The way I see customer journey mapping is that you could define touch points across the whole business, across the whole process that are so high level that they wouldn't really make sense in a story map. And the whole point of a story map is you end up with stories and stories have to be deliverable pieces of software that you're developing. And with a customer journey map, you don't really get that. It could be a customer journey map could be talking about the customer buys, the phone gets shipped to the customer, the warehouse releases that it kind of, you've got all these touch points that can happen in a full customer journey. I know that's perhaps not UX focused, but I don't know. I just feel like that's where it is. Yeah. I had a heated discussion recently also with the product lead about differentiation between those two tools. And I fully agree with you. Customer journey mapping is to me more the touch points that you have with the brand and as a result, buying or using the services and products while user story mapping really focuses on how people are using the actual product. Yeah. So it sits at a much higher level, which covers a bigger spectrum of things that a company might do. And then the user story map is almost if you pick one of those products that sits in that ecosystem of a customer journey map, you can think, okay, let's build a story map around that and go from there. But yeah, totally agree with James that it kind of, it's a, it's a level above story mapping for sure. So it's like zooming in into a specific part of the user journey and then like really mapping all the different stories, having them deliverable and using them also more like also for as a format for planning and laying everything out, having the backlog ready. Yeah. Yeah. So I was just going to say as well, if you look at the structure of a customer journey map as well, it's not necessarily just a sort of 2D kind of user story map view where it's your most important releases are at the top. And then as you go down, the priority is less and less customer journey map. I've seen some hugely intricate customer journey maps where it's, you follow this path and you start over on the left and you go down and you go down a little bit and then across and then before you know it, you follow this kind of maze of a journey to explain all of the touch points that a customer might go through when they're interacting with your service, your product, your company, whatever it might be. Where do you see story mapping coming in place, looking at the whole product development process? Yeah. As I mentioned earlier, that was the magic moment for me was when I realized that it should be part of the product delivery cycle as opposed to just an exercise that should be tackled upfront. I see it as the perfect place to first of all, scope out your product or your project. So yes, you are going to be story mapping upfront to a certain degree before you've created a backlog or planned a sprint or whatever. But moving forward, it's the perfect place to take stakeholder feedback, take customer feedback and actually place it in context within the product that you've already defined. You know, it's so easy for a customer to just say, I want X or I want Y or can you build this feature? But the difficult bit really for the product manager or the product owner is to take that piece of feedback, put it through all the filters that you need to put it through, decide whether it's worth building or even worth tracking. And if it is, find a place to track that within the context of your product. And that's where the story map is really useful because you can place it in there and you can work out where it sits within those journeys and so on. And then you can prioritize it. And once you've prioritized it, you can push it towards your backlog, whether that's a kind of a manual transfer thing, going from a physical. map on the wall, which I think probably less people are doing now, or going from a digital map and pushing it over to your backlog and then it can be planned into sprints and you go into full kind of execution mode. So to me it feels, I know we've talked a little bit in the past about there being like a bit of a horizontal line of the flow of things as they're coming in. I know it's a loop ultimately. Stuff is coming in and it needs to find its way all the way through the system, be planned, be thought about, and then put into the backlog, executed by developers, and then released and then tested and whatnot. So it's that planning stage before the backlog that makes your backlog much more digestible basically. Tim, I don't know if you've got any other thoughts on that. Yeah, it is more than just a workshop, you know, that you do to figure out, okay, what's the scope of what we're building here? Let's get everyone in a room and let's build a user story map and kind of come up with that initial plan to figure out what it is we're building, get everyone on the same page. But then beyond that, it also drives your backlog continually. So there's those two parts of it, which I often like to think of as there's the workshop bit, but then there's also actually the continual kind of driving of your backlog, making sure that you're getting the most value out of that story map that you spent those many hours or potentially days building right at the start. You've put all of that time invested into building this amazing artifact that explains things in a really elegant way, really user centered, user focused sort of perspective. And then often we just see people leave that by the wayside once they've figured out, okay, cool, this is the kind of work that we're going to do. Let's push that and never go back to the story map again. Actually, there's that continual kind of iterative kind of process that you can get from that story map beyond just that initial scope. So totally, yeah, the sort of taking that and feeding a backlog beyond once you've launched your MVP, it goes much more beyond that. It's a more persistent sort of thing in the tool chain. But coming from this initial workshop, what's the cadence or how do you keep iterating on the story map? Do you rerun workshops to go in there and revisit it? Or do you try to really incorporate it in your daily work? I think it's probably both ultimately. The story map is a great place to just drop ideas as and when you're thinking about them, right? So you have this huge kind of, I like to think of it as an iceberg on your story map, right? And you have this huge kind of collection of potentially just placeholder cards, which are just all your ideas. You might be on a train, traveling into work, going out wherever you are and you think, okay, great, that would be an awesome idea. We should build that. I'm just going to drop it on the bottom of the story map and kind of forget about it and maybe come back to it in a month's time when you're ready to pull that up higher up the map and think, okay, great, let's flesh this story out. But you can also go the other route and say, hey guys, let's get everyone in a room together and spend an hour mapping out this whole new journey that we're going to build, that we're going to bolt onto our app. And let's figure out what's the MVP for this journey and what are all the additional stories that we could release two, three, four months from now and flesh out a bit more of a release strategy for how this kind of goes to market. And so I think ultimately, and that's the beauty of it, you know, there's so many different ways that you can feed data into your story map and then plan how you're going to execute on that. Yeah, ultimately there's a few different ways you can do that. Talking about the data to be fed in, I'm actually interested, we're talking now at the end of the part of the whole cycle, soft delivery process where story mapping is obviously a great way to get clarity and scope and priority into the whole project. So how do you see user story mapping as the initial part of the product discovery process? So if you talk about feature evaluation and things like that. Are you saying that, for example, we haven't done a workshop up front or are you saying that you've already done a workshop and you have a user story map in place, but how does that feed into discussions? The question I'm pointing to is how useful can user story mapping be to, first of all, do a workshop and understand whether it makes even sense to build this product and rather try to understand what kind of more research I need to do. Yeah, so yeah, I guess that comes under the bracket of spotting gaps and dependencies that you just didn't know were there. And I think that's, once again, another one of the kind of benefits that comes along with story mapping is that it forces you to lay out journeys, user journeys, that once you actually think about what needs to be built as part of those user journeys and people are, you actually put yourself in the position of the user walking through the journey, a bit like in Jeff Patton's book, when he says, map out your morning routine, you actually have to go through the routine in your head to be able to map it out because otherwise it's just a blur. It just happens, it's there, the idea is there, but you don't actually have a way of telling anyone that flow. So story mapping takes that and obviously building software and systems and products is more complicated than our morning routine. And that's where the story mapping is really valuable. And sometimes you can lay out user journeys and actually realize that there's no way to get from A to Z in a particular flow and you're just naturally missing something, or there's just too much to build in between that you've got to simplify your idea. You have to think of a different way to provide this user experience to your end users. So I think it's really great for spotting gaps in that manner as an upfront planning tool, but I also think it's great for spotting gaps further down the line when you do have a product mapped out and you do have releases and stuff, but you, as you create more releases or as you prioritize more releases from the stories that you've already defined, you realize that you're missing potentially key pieces or key, or key, just key user stories sometimes, but sometimes it can be a bit more complicated than that. Like, oh, we're actually, there's no API to do that yet. So how are we going to release this? That's, it's just not possible. We're reliant on another team and you identify those holes earlier because you're planning your releases in the story map. So then you can, as a product manager, you can go out, you can contact the other team and you can say, we need to find a way to work our timelines together or whatever. So, so yeah, I think it's great for spotting gaps, not only upfront. I do really like the idea, like you just said, of actually deciding not to build something because of creating a story. I mean, what a great use of time. I know it's like almost a bit like someone might say, that was, we spent three hours on that. That's brilliant. Three hours is better than three months. So I think that's a really nice way of putting it. Yeah. I mean, it's almost. Sorry, go ahead. Sorry, go, go ahead. You know, the dependencies and all that kind of stuff that James was talking about, spotting those gaps is a big thing to say, okay, there's an area of domain of the domain that we don't understand right now. And is that because we just can't build it or just because we don't know enough yet and we should go away and then come back once we do know. But I think also you can use a story map as a great way to visualize how much there is to build. If you could do it properly and you do, you figure out, okay, what are all the kind of high level stories that we do need in place to be able to deliver this? You can accurately, to an extent, say, okay, cool. There looks like there's going to be at least 70, 80, 90, hundreds of user stories to deliver this thing actually based on our sort of bureaucracy, our team's release cycle, speed and all that kind of stuff. Can we actually deliver this in time, on time, on budget? So I guess from that perspective as well, it helps you to figure out what is the, what's the scope of the project that we're trying to build and can we feasibly deliver that within budget? Yeah. I think this ties a little bit in what I wanted to say, which is it does feel like I could use user story mapping as some sort of prototyping tool to early validate even an idea, just internally. And I think the feasibility part plays a big role. I can try and see, okay, where are really the gaps? Does this product make sense? And I think one thing that I generally like about prototyping in all kinds of sorts is that it helps you going beyond really looking at this whole flow. I do feel like it's a rapid way, as you say, Tim, three hours, just sit down, try and look at it. And then maybe even at the end decide, okay, we can't actually build it. It's like we are missing some APIs or there is maybe something in the flow broken. Totally. I mean, that's exactly how I explain it. It helps you break down big ideas into working software. And if you're trying to build a prototype, visualizing what you're going to build within the context of your user journeys helps you figure out what are the absolute minimum amount of stories we need to be able to deliver on the goal that the user is trying to do. And in that way, you know, you actually build less, but deliver more value for your users because you're constantly evaluating, hang on, is this going to give any value back to the user? And does it need to be there for us to be able to achieve this goal? And if the answer is yes to both of those questions, go ahead and build the damn thing. But, you know, it certainly helps you figure out what's the minimum we should build to deliver some value back. And if we're prototyping and trying to build some small scale sort of proof of concept, then absolutely, even a user story map does kind of work in that perspective, just to help you figure out what's, you know, what's a really light version here. If I'm now a product manager or product owner, what are the different ways for me to actively use the StoryMap or to transfer the StoryMap into my backlog? So can we maybe talk, can you maybe share a little bit with the product audience, how you can really make a good use of a user StoryMap? I think the first thing, we haven't really talked about this too much, but there's the whole kind of digital versus physical question that probably needs to be answered. I mean, just to sign of the times, COVID, obviously everything's turned on its head, you know, this year. And even though there were plenty of teams StoryMapping digitally before, and sometimes doing both actually as well, it's worth mentioning that you don't have to pick either or. Sometimes a really nice way to get the most out of a StoryMap is to start physically with Post-its because there's something about that exercise being done in the same room that you can't get when you're, and that's coming from someone that built a tool to do it online. You can't get that same feeling as all sitting in the room and having the energy there whilst everyone's there. But having said that, obviously times are different at the moment at the very least, and some companies are fully remote and distributed, so you do need ways to manage it digitally. And the other thing is, even if you are going to start physically, often the best thing to do is to scribe that straight into a digital tool once you're done. You know, yes, it looks great on the wall. It was fun. It was scribbly. It was messy. But that data is really important. And when someone opened the outside door and the Post-its fly off the wall, that's a problem. And another thing is the whole sort of privacy side of it. Sometimes you're working companies and they're very open and that's great, but sometimes you don't. You're working companies where there's actually, there's NDAs that people are signing not to talk about the next upcoming products to even their closest colleagues and stuff. So sometimes you need the privacy side of it as well. So assuming that you can use a digital tool, and there are obviously other tools out there, you know, there's Avion, but there are other tools and some really great ones. But the key thing is the integrations between the story mapping tool and the backlog tool is what really allows you to create all of the stuff that we talked about earlier and create that scope of your product and do all of that kind of upfront work to get the planning in order. But then to plan your releases and to push those items onto your backlog tool. So I think really the takeaway for product managers is if you want to get started, use a story mapping. I would probably look at the digital landscape for story mapping and try a few tools out, see what feels right. And once you've decided on a tool that really feels right, you can then hook that up to your backlog tool and you can start going through some of the processes that are going to work for you and your team. And not every process is exactly the same. We see people using the processes, you know, quite differently between different tools just because they have different ways of working. But I think the key thing is just to explore those integrations because a lot of them are integrations. For example, I'll create a story in Avion and I'll prioritize it into a release and I will then push that release to a tool like Jira, for instance. And in Jira, all of the tickets show up. So I get a load of issues within Jira that all have the same hierarchy with epics that you created in Avion for your story map. So you're gaining the context in Jira that you didn't necessarily have in the first place. But the great thing is those tickets are like in sync perfectly. So you can make a change in Avion, you can come into your Avion story map on Monday, make a change to a story, and then you could be working in Jira for the rest of the week and make other changes to those stories mid-sprint or whatever, and everything's going to be reflected either side. So I think the key thing for product managers is just to check out those integrations if you really want to get a good workflow going. I guess also, just to add to that, the integrations are a huge advantage for being able to push your backlog from a story mapping tool into a backlog management tool like Jira or Azure DevOps or whatever. But because it's two-way, you get that rolled up view back in the story map as well, provided that whatever tool you're using has built a decent integration with that service. And that's hugely important when it comes to communicating back progress to key stakeholders. You don't want to be pulling up Jira and then trying to figure out, okay, how many stories are in progress? How many have been done? What's the status of this release? Where are we? Why can't we just... Why can't you just tell me where we are? And that's what a really good... Sorry, that's how... That's why story mapping is such a great way of communicating those plans and progress and current project status back up, higher up that chain. Maybe your CTO wants to know where we are in our release cycle. What's the status of this release? Actually, in Avion, for example, you can go in there and you can see, okay, cool, we've got three stories left out of 20 for this release. We've got four points left. And by the way, the past two releases are now all complete and they're shipped as well. And you get that rolled up view of your release roadmap, which is a really easy way to communicate progress back. So, yeah. And then also, left on the digital physical side of things, we might have forgotten the eco-friendly side as well. So, a lot less the postage means a lot more trees saved. That was the argument I was waiting for, Tim. But I agree with you. I think the two-way synchronization is not only important to report back on progress. On the other hand, what's also very important that I see in startups I'm working with, especially with past growing companies, is the documentation aspect. So, user story map really helps you, first of all, understanding how our users, speaking from a startup perspective, using the product. If you are a new product manager or an engineer joining a team, the story map can really help you seeing, hey, how is the user interacting with the product and what kind of stuff have we built around it? Talking about this, I would be also interested to hear from your experience for our product audience, how you can use story mapping for release planning. Sure. Just to touch on that last point, it's something people don't talk about a lot, is story mapping for onboarding. It's such a powerful way to be able to bring an engineer, bring a designer, bring a product manager into a business or into a project or a product, and to be able to have a conversation about the product almost in real time. You can walk through the journeys, you can look at the releases that have been delivered in the past six months and say, this is what we shipped, this is what we shipped, this is what we shipped. It's a great way of them really being able to see that the scope and the width of the product and also, I guess, the height of the product in terms of all the stuff that you've already delivered. Release planning then, yeah, I mean, there's quite a few slightly more advanced techniques that you can do in terms of release planning. Just to clear up the word release, I think people get a bit scared of the word release. We've mentioned it before and people think of sort of big enterprise business release cycles that take six months or nine months or whatever. That is not really the definition of a modern software release. We all know that the aim of the game is to release whenever you can. So whenever you've got something ready or value to deliver, you deliver it. The way me and Tim view it is that a release is ultimately just a collection of stories that when you deliver them together, they produce working software that a user can actually carry out the outcome that you intended. So a release really should have an outcome and it should have some metrics to be measuring for, some KPIs, and that is what you're delivering. That is your release. A release could be, ultimately, it could be one story or it could be 20 stories. If it's 50 stories, maybe that's too big. That might not be the right thing to do. So that's what we're talking about when we say releases. And in a story map, a release is basically a horizontal line across the map. You incorporate stories above the horizontal line or below, depending on how you lay it out, but that becomes your release. And the nice thing about releases in the story map is because they're horizontally cutting across the map, they cut through all of the different user journeys so you can deliver stuff across your app at the same time that all has a relationship to itself. Think of like a release that says, you know, I want users to be able to pick dates better throughout the application. And you might build an awesome like date picker thing, but that has to be implemented in four different places. There's a UI component, there's like something on a different search page, and so on. So a story map is a really nice way to track all of those different touch points of how you're going to deliver that particular release. Now, one thing we do always try and say to people, and I'm not sure if everyone ever gets to this like nice utopia, but is that your releases are not necessarily, they don't have to be tied to your sprints. It's not a, you're not saying here's two weeks work, here's two weeks work, here's four weeks work. We're saying, here's some work that needs to be done. And however that fits around our sprint is absolutely fine. We're just going to keep delivering at the velocity that we're expecting to each sprint. And then we can predict, you know, when this release may drop. So try and think of it like that when you're slicing up in a story map. app is these are not tied to sprints. These are just releases that we want to deliver, and this is the order that we're going to deliver them in. And then you can do your sprint planning in, in, in another place like Jira or something. And then just one final tip, which Tim came up with, and I think this is a really nice thing to do is when you're working in a digital tool, one thing you can do is create a story map and create like a mini release plan. So say you create four or five releases for the next three months or something like that, and then duplicate that story map and just tear it up and do a different release plan. So you can literally compare side by side. You can talk to your, your CEO, or you can talk to your stakeholders and say, here's two different versions of what we can do in the next three months, what is going to be more valuable from a, this one's more valuable from a business perspective. Whereas this one's more valuable from a brand perspective. And you can actually have those conversations whilst having the data in front of you to say, this is actually what would be delivered. This is what it might look like at the end. So I think release planning can, you can take you quite far, but you've got to have the basics of story mapping down before you can get to that sort of level, I think. I think that's a very nice point. Agreed. The, the other benefit as well, just to add to that, just bringing it back to what James was saying about a release cutting through your entire product. I guess looking at it from more of an agile sort of purist point of view, it really helps you make sure that you're building across all areas of your product iteratively, and you're not just focusing on one section and then a month later, you've put all your time and budget into that one area, and then you've left the other three or four sort of main sort of epics if you want, or, you know, journeys or whatever it is that you're describing as a big chunk of your product, and you've left those by the wayside and you've not iterated on them. Whereas a release encourages that sort of end kind of iteration that we're continually improving, you know, the whole slice of that product in one go. So it encourages that potentially that sort of lean mindset of working on every part of your app and continually improving bit by bit. Nice. So I took some notes during this whole call and I think there might also be a little bit of bias on this call because obviously like Christian is a huge advocate for user story maps, you guys have your own product, and I mean, currently it sounds like it's a great tool for communication, it helps you planning, it helps you visualize like what you have, you can even use it like to document everything, onboarding, you can get like people started fast. So the thing that I'm curious on, and you obviously spent a lot of time like really working on user story maps and using the framework, what would you say is the downside of using them and what can't they do or where do user story maps? It's a really good question. And I think one of the most common things, even I struggle with sometimes, but some of our customers have this question as well, and I guess it's more with the sort of API driven products that don't really have a front facing UI or an interactive kind of piece with a customer or a user. And it's a very, it's just a backend sort of service that you're building. It's quite hard to sometimes visualize those kind of end goals or those sort of, you know, those overall, this is the journey of your API, but that doesn't really work in that kind of way. You have to think what's the end goal of what they're going to do with the API. And a lot of the time that's very bespoke to whatever it is that is consuming that API. And so I think that's definitely a use case that I definitely haven't seen a really great implementation of a story map for, you know, a code sort of first API driven sort of service. So that's one area I would say that is quite difficult to model with a story map. But it can be done. Don't get me wrong. I just think you have to break out that API in a different way than a traditional code, but here's the user's goals from left and there's not necessarily a narrative flow and maybe it's more about this is what this part of the API does. And let's just kind of hold that on the top as the backbone and that's it. Yeah. I don't know if James has any other insights into that. I think visualizing technical stuff is easier once you have built it rather than trying to plan it right. On the other hand, what user story mapping can do, Alex, it can cure cancer. I would say definitely. Other than that, I have no idea. I thought we found the cure. Has anyone tried to cure cancer with story mapping? That's what I would say. It's true though. It's difficult to just say, I think from my side, once I started story mapping, I think you just don't go back as long as you're building something where there is a focus on providing value back to a user, you just, I can't see it a different way anymore, gone are the days for me where you're planning a backlog and it's just a flat long list of user stories. And if you're working with user stories, I would say it's more than likely that's going to work well, better, sorry, in a story map sort of structure. So, yeah. Nice. Makes a lot of sense. Cool. Then maybe like just to, to slowly wrap it up, I think like one, one thing that is like super important to me also to get across is like how different companies work and I think like how the companies that we invite or the guests that we invite to our podcast work together. And I think in your case, specifically what I'm curious about is when you decided to start Evian, how did you, or did you apply user story mapping and your own processes to like actually get started at the company or what was like really the process you both run and you have a bit of a design background, engineering background, how did you mix all these things together to build your company? Yeah. When we first started, one of, one of the goals to get to for us was to be able to use our own products to plan our own products, which is anyone that's building software always wants to get to that stage where you can start using your own software, so we knew that would, that would have been our beta, I guess, like our sort of MVP, we'd be willing to let the public use it if we could vaguely use it, so to, to be honest with you, because we started, we were a startup and doing it on the side of, of full-time jobs. It wasn't a traditional, we weren't doing sprint cycles. We didn't have like initial planning sessions and stuff. A two-man team allows you to share and collaborate so closely that often your brains are just in sync and, and you don't need complex process there to do any of that stuff. We had a goal in mind and we just worked towards that without any real deadlines or anything like that. So I think commercially speaking, it's a very different application to, to when you go and work for a company and they say, Hey, we've got some budget, we want to build X and we want to deliver it in the next three months or whatever. However, obviously our process has grown a lot since, since we went full-time and now we use this, the story map to drive our backlog, it's, we don't work in strict kind of sprint cycles still. We're pretty much like Kanban methodology, pull to the right, just deliver stuff in very small chunks. And we really do, you know, we will push out a release that is tiny to the app and do it multiple times a day. So we've always had a nice sort of technical DevOps background that allows us to have that kind of really nice release sort of process to get technical releases there in terms of planning and kind of actually knowing what we want to build, we have no shortage of users just firing us feature requests and stuff. So for us, it's about actually taking those feature requests and trying to detach ourselves a little bit from the product because obviously we love it. And it's, it's our baby, we built it. You need to be able to detach yourself from that and put your kind of product management filter on and say, what of these features, how are these features actually going to deliver value? And are we building features for the right target market here ultimately? So I think all of this applies quite ironically to everyone that, that might use a user story mapping tool. It's just the fact that we happen to build one. But yeah, I think we've come a long way with our processes and I'm sure as our team grows, that's going to change again. But I think story mapping will always be at the center of kind of planning stuff for us. Speaking of, you are two people right now. What are your growth plans? Silence. Nothing, no growth. Tim was winding up like he was going to blow the message out. Yeah, no, let me, let me take that one. Great. I mean, we're currently raising a seed round right now and that's going really well. So if everything does come off and go smoothly, we are planning on bumping up our dev team by one. Also, I think as well, there's this space given our kind of, you know, customer base size right now to bring on a sort of marketing and support kind of role, I guess, as well. We're not looking at just trying to scale up hugely and our burn rate is just going to go like that kind of thing. We want to do it properly and start off small and make sure it's controlled growth. That's the plan really is just to hire a couple more people. And keep doing what we're doing now, and hopefully that's, that's going to play to our favor in the long run. So just worth noting as well, that the direction of the product for us, the goal is actually to expand and offer more product management tooling as a whole. It's not just story mapping is great. It's the center of it for us. You know, it's the heart of, of planning products, but there's other stuff that I think we could offer and provide a bit more of a tool set for product managers that hopefully is really lovely to use, but has really powerful integrations as well, and still has story mapping as a massive part of it. And that's our thing. We focus on story mapping and all the stuff around it just makes the product a little bit nicer. So yeah, lots of stuff for the future. I guess just thinking of the, James was talking about DevOps a couple of minutes ago, and that's, if you look at that, the DevOps kind of world has matured so much over the last sort of decade. I'd guess the tooling around there for CICD, Azure DevOps pipelines, automated deployments and builds and testing integration to all of that kind of stuff over the last 10 years has just blown up. And that's great. It's amazing. But we haven't seen that in the product management space where we're still, I don't feel like we're there and we're seeing a bit of a, of a groundswell with different types of apps and services and products that kind of help product managers in some form of what their job role is, but there's not like a really brilliant suite of tools. As far as I can see, it covers that whole life cycle and provides a way to really elegantly plan and build software from the product planning perspective. You know, that's the dream right there is to come up with a really elegant suite of tools that are all interoperable, all work together for product managers, you know, and then you can push that on through your DevOps and delivery team and all that kind of stuff over to Jira, whatever tools you're using, but it's that planning stage, which we have a passion for that we're trying to, you know, take away. Do you know why the product tooling hasn't evolved that much? I feel like you're going to tell me why. Yeah, it's very easy because product managers can't build it by themselves. Yeah, well, some, some can. Some have to. Some can. You're right. You're right. I can, I can tell you. Yeah. Well, you know what, there's plenty of devs out there that they want problems to solve. Like they, they can't, they can build stuff, but they can't necessarily, they don't necessarily have kind of the problems there. If you're a product manager and you've got ideas for software, we'll get paired up with a developer and start, you know, let's break open this space a little bit more and see if we can expand it. Cause I think there's lots of opportunity there for new tooling. Oh yeah. Nice. Maybe just because we are actually talking about Avion and their growth plans, just like for everyone who wants to use, sign up, try out the tool, like where can they find you and how do they access it? Yep. So it's avion.io and you can sign up for a, we've got a free trial for 14 days and you can story map to your heart's content and obviously please reach out. We've got a chat widget in the corner. It's not a robot. It's you get straight through to us. So if you want to chat about story mapping and how, not only how to use our software, but how story mapping is applicable at your business, depending on it's very different if you're a startup compared to if you're an enterprise business, so just reach out and we'd love to, to have a chat and, and go from there. Yeah. Nice. Awesome. Then that's that. Maybe like to wrap it up, what are like the key messages that you guys would still want to share or, or how would you summarize the key messages? I think one, one key takeaway, if you're new to story mapping, it's suddenly to just start off simple, you know, take one sort of user flow, take one journey of your product and try and map out that to start off with before you take this huge product. That's maybe got 15, 20 journeys in there, loads of different complicated flows. I don't think you're going to necessarily get the most out of story mapping if that's your kind of first attempt there. So definitely I would say, you know, try off, start off simple and then progressively work your way up from there. And also you get out of story mapping what you put into it. So if you spend time crafting an amazing release plan and release strategy that has maybe five, 10, 15 releases, and it's got really nice, intricate, detailed kind of backbone, you're going to get a lot out of that. But conversely, if you don't put the time in, you're still going to get value from it, don't get me wrong, but you won't necessarily get everything out of story mapping that you, you could do. So start simple and then go from there is my, it's my advice. And for me, I would say, spend a bit of time upfront learning the anatomy of a story map, you don't necessarily need to read Jeff's book, but when you first start using something like Kanban, it's so intuitive that you don't need to learn anything, whereas with story mapping, I think just do yourself a favor and read a few guides and understand all of the different axes on the map because they mean something and once you get your head around that, you'll have that magic moment like I did and realize that there's a lot to this. And once you can get your products into a story map, it will unlock a lot of other stuff for you moving forward. Great. Talking about reading, you have also a nice blog that people can find on your website, talking about user story mapping. So I recommend you having a look at it. And other than that, it was a pleasure talking to you guys. Thank you very much for sharing your experiences and your insights around user story mapping. Thanks guys. Awesome. Thanks for having us. Thanks a lot. And guys, fingers crossed for the seed round and the growth. I'm really looking forward to have some good product tools out there. Yeah. All right. So the podcast won't end yet. Alex and I will jump now into a short debrief. All right. So Christian, finally alone again, really have to say lovely guys. You already met them before. Right. So a little bit, a little bit. Yes. Yeah. Definitely some good stories to tell obviously after being professional story mappers. No. What do you feel about the conversation? I have to say, I learned a couple of new things, which I, I don't want to say did not expect it, but surprising, surprising things that were kind of enlightening for me, first of all, I really like how much they're focused on taking care of teams in terms of making sure, providing a tool that allows people to work as smoothly as possible. On the other hand, when it comes to the whole methodology, I'm doing a story mapping since many years now. And I never thought about the idea of duplicating my story maps and creating different kinds of release versions. That was a brilliant idea. I haven't heard of, I have to say tomorrow morning at work, I will directly start using this. That was really nice and really insightful from my side. I think it's, that's a really nice way to, to actually have quick iterations on the planning itself and, and to really like spin ideas also around that one. I think it's so easy that when you plan something that you just like, after the first version, you stick to it or you just try to slightly adjust it. But I really like the fact that when you duplicate it, you really reshuffle it and force yourself in that mindset of having multiple versions and I always like also to, to try and find the connections and in the design world, I would usually force myself to come up with different solutions and different designs, different screens for everything I have to work on simply because forcing me to do so forces me also to make sure that I'm not just like sticking to the first idea and applying this to two different formats is a really nice thing. Also very interesting to me was the working style they are approaching for themselves. I really can understand that you don't need to over-process things when you are just two people. I think that's straightforward. On the other hand, yeah, I'm pretty curious to see how they will change their way of planning and working when they start stocking up the team. Yeah. They definitely have a good starting setup, especially having a lot of experience on the DevOps side and being able to like have a very flexible release schedule. And I mean, I left with the feeling that even by adding more people and having more developers on the team, their release setup or DevOps setup would allow them to still stay flexible. So I think that definitely gives them a good advantage. And I think also as a team, they are definitely an interesting mix because they are both able to ship their own stuff, both have like engineering backgrounds. James being even like having an initial designer background or being a designer at heart and working on something so product focused, right? Amazing. Yeah. Yeah. And what I also really liked or what was to me one of the... smartest decisions they want to make for the future is the healthy growth, rather growing slow and steady than too fast is sometimes way better than trying to explode. Yeah, which luckily, it's also hard to explode when you're in such a narrow kind of field. I do wish them explosive growth nevertheless, because I think when you experience it and you work there, obviously healthy growth is nice. Yeah, I'm really looking forward to seeing what they will come up with in the next couple of months and years. So with that being said, Alex, I think it was a good interview. Very insightful. Any last words from your side? I can only agree. Looking forward to meet both James and Tim again, maybe in person one day if travel allows. And therefore, I would say we can wrap it up here. And what's important for the guests? For the guests, like last time, hello at product-bakery.com for feedback and further questions, as well as tips for topics to talk about. Other than that, our next guest will be an engineering manager with the mission to build a product and engineering organization in a fast growing company. More will be released soon. Perfect. Looking forward to that. Final question, and we can cut this out depending on your answer, Christian. I'm wondering for the audience, especially as Avion has this chat on the bottom right of their website, I remember James is married. Is Tim single? So maybe someone wants to drop him a line there? We will check with Tim and let you guys know. Yeah. I hope you won't try to send any weird pics to him. I'm not sure if these support chats allow. I think it's time to close the podcast. Thanks, everyone, for listening and bye. Bye, guys. Have a beautiful night. Bye.