How does a long-term roadmap fit with agile ways of working? | Vidas Vasiliauskas

In episode 56 of Talking Roadmaps, Phil Hornby interviews Vidas Vasiliauskas. They delve into the compatibility of long-term roadmaps with agile methodologies, exploring practical strategies to balance planning and adaptability. Vidas shares insights on integrating Kanban with traditional project management tools, addressing common challenges, and enhancing team collaboration and productivity.

Software Engineer by education, creator of digital products by passion. Vidas has built software from mobile apps to online computer games. Currently heading a startup – Teamhood, which aims to make collaboration and projects more successful by combining Kanban techniques with classic project management tools such as Gantt, Time tracking and resource management.

Here is an audio-only version if that’s your preferred medium - and you can access it through your favourite podcasting platform if you prefer (Apple, Spotify, Amazon).

In the next episode we are talking to Annett Eckert, she’s a Product and Transformation Coach. So watch out for Season 1 - Episode 57!

• Transcript

  - Welcome to "Talking Roadmaps", the channel where we talk about the good, the bad, the ugly, and everything about roadmapping. Today I'm joined by Vidas. Vidas, introduce yourself?

  - Hey there, everyone. I'm Vidas from Teamhood. I'm working myself as a product manager for our beloved software, both as, like, a person responsible for this area, as well as someone who needs to be as close as possible to the end users to understand what kind of pain points and sufferings they endure throughout the day, so we can make the software far more better than it is.

  - I mean, and I think you kind of play yourself down a little bit. You're also the CEO of Teamhood, so that mini CEO is a very apt description, I guess, for yourself.

  - I try to avoid it, you caught me here right away. I try to avoid that title, because I treat myself as a creator. I love creating things, I love, you know, making things work for people. And for me, this is the best title ever, to do something meaningful, valuable. CEO is a role which I take, and I also enjoy, but in general, it just tells not much as I feel, it just doesn't tell the full picture. But yeah, I'm responsible for the company, so that's a hell of a lot of scope, you know, to take care of, and yeah.

  - If you're enjoying the channel, subscribe, hit the button.

  - Wearing multiple hats,

  - And give us a like.

  - that's the life of every CEO, I believe.

  - So let's dive in, and I'm sure we're gonna hear more about Teamhood as we go along, I'm sure you'll reference it in some of your answers. What is the purpose of a roadmap?

  - Yeah, so straight to the point, right, Phil? For me personally, as well as my team, it's like a guidance and agreement alignment between everyone, so that we know what do we envision to be, like, future goals or ways to achieve our future goals. So that's a simple explanation. But in terms of tangible things, that's just, you know, a list of specific data, which represents steps, actions to take, on specific dates even, so that we fulfil what we envision during our strategy planning or vision statement, even sessions, so, yeah.

  - Okay, so maybe unpack that a little bit more for me? So you talked about specific actions, specific items, maybe with a date, can you maybe unpack that? Tell me a little bit more about what you're thinking there?

  - Well, so roadmap is like a twofold thing as I see it. So there is a structure and there's content in each roadmap. So structure is somewhat, like, how do you visualise things so that people understand it and perceive it the same way? You want to have that alignment, you want to have that simplicity, and you want to have that like single glance to learn everything approach. That's a good roadmap for me. But that's structure mainly, how you visualise, And the content itself, steps, items, initiatives, mini projects, whatever you have in there, these are things that tell you how or what exactly will you do to reach the goals, which are, like, maybe milestones in your roadmap, maybe they're like huge initiatives if you're working like an enterprise level company. But in general, that's what I would call content. What do we want and how we will get there.

  - So, okay. Yeah, what we want and how we'll get there now. So, okay, you used a few terms there, initiatives, steps, I'm sure there was another one in there.

  - Mini projects. Well, I don't differentiate too much between these terms, because it's already confusing to everyone. There are just too many terms. I'm so relaxed about calling things different names. Maybe that's my vice, right? I feel that it doesn't matter, like, how you call things you do, because if you have a clear goal or vision where you want to end up, like, eventually, and you will figure out what are the steps to get to that vision, you can call them, you know, maybe they will be tasks, those items, because they're just small things that you will do day by day, and eventually you appear in your destination. Or maybe we'll need to start these, like, groundbreaking initiatives, which will transform both your organisation, or your product, or your service, and then you get to the final destination. Or maybe there is no final destination, you keep doing stuff until you reach the ideal point of no return. But general, these things are dependent, really, on the case we're speaking. Small team, probably tasks or steps. Bigger teams or organisations, projects, initiatives, programmes, well, a lot of different names. There are users of them, of course, but I'm relaxed about it.

  - And you hinted at there using a roadmap for more than just steering a product. Maybe you could, say, unpack that thought a little more?

  - Well, already in that steering the product, it has a lot of underneath, right? What is steering? Is it like technical steering? What needs to be done or how it needs to be done? Or it's like organising people's work around the vision. So do people perceive everything the same way as I do or as my other teammates do? And it involves a lot of things. I, as a team member, I like to know what's the long term goal, because it can influence my decisions and I can spark additional ideas, sprinkle on top of everything we do. So this is like this soft value that lives underneath the roadmap. And people, of course, do expect that. Probably then what I meant by structure and alignment is also when we get into tough situations, and it's always, you know, a roller coaster, especially, I'm coming from the startup world, it's always a rollercoaster. You're just trying to solve the most important problems. There are just too many of them all the time. And in this case, it's about not forgetting or it's about like feeling the commitment, if it's always somewhere. If you even visualise and make your roadmap public, if you involve your users or customers in there, I mean, that's it, that's your commitment. You need to live up to your commitments, and that will push you to stay on track instead of delve into every, you know, shiny object that you see along the way. So this is very important. and it comes as this, also soft value of roadmap, not just as a plan of things on the calendar basis.

  - That kind of helping keep people on some sort of track, not following every rabbit hole, or rattle, or bright shiny object, I like that thought. And you kind of talked a bit about it being a kind of that alignment to the vision. Maybe you could kind of say a little bit more, give some more thoughts around kind of vision, strategy, objectives, how they all link into a roadmap?

  - Yeah, and I believe the best ways is to, like, even share some examples of my own. So if it's a bigger organisation, and I've been in my past career in very large organisations, from 5 to 10,000 people, I felt, like, how complicated it is to keep grand visions, which are great, when you think about vision, you have so much knowledge behind you that you craft this vision, not by just, you know, flipping your fingers, but just by working together with a lot of people and crafting something that will steer large organisation towards the success. But then how fast it gets lost when you move across layers, layers to other bottom layers of, I don't know if it's hierarchical structure or it's just flat, but really, you know, broad structure of organisation. It just gets lost somewhere in the trenches. And having good roadmap, I think for me it means if we agreed, for example, this year, so we agreed, okay, we need to be far better at the first session of our product. So everyone who comes to Teamhood, they need to be met with the best effort of user experience with straight and fluent, you know, use cases, or user journeys. And we need to work on that, we will measure it, and this is our, like, goal for the first quarter, then we iterate in another quarter, and we keep doing that until end of the year. So this needs to live in roadmap also as a goal. If I structure my roadmap, I won't just place items like, oh, we need to improve, like, onboarding, we need to make application load faster, we need to ensure that our application is responsive enough on majority of the devices. That's not good enough, I need to package them under something like a key result. And that key result could be, oh, let's activate 20% more of users on the first session. That's the key result that they want achieve by the end of the year. Maybe 30%, if we are like more ambitious. That's what we can write. And then items need to fall under this initiative or key result. And each item can be a standalone delivery of value. Because if item is on roadmap, I want to see how much tangible it is to the end goal. How can I look at it and understand that, yes, this is what's gonna move the needle. This is very important.

  - And I heard the word activate in there. That sounds like you're applying almost a pirate metrics style kind of funnel to kind of your customer journey.

  - It's a mix of things. I wouldn't even call it any specific method or approach, but we just do a mix of things. And it's about do what's right, because every organisation at specific point in time has specific needs. I cannot go to every startup and say, "Oh, you should do your roadmapping this way." Because, well, maybe they're solving different type of problems than we do, and they will need to structure their roadmap differently. And they will need, you know, to involve maybe stakeholders which are not inside the team, just outside, completely, driven by outside stakeholders. And that's it, that's different. Maybe they don't have data or they need to have data, and that's their drive, you know, to make roadmaps more tangible.

  - So we've talked quite a bit about what's on the roadmap. We've talked about kind of that alignment of strategy, and objectives, and kind of key results. But who's looking at this thing? Who is the audience of our roadmap?

  - Well, again, it really depends in what type of organisation and what type of business you are. I think personally, if it's a startup, the audience can be quite broad, first of all. And most importantly, it's your users. Because if you're building something, if you're in early stages, it is extremely important to put forward looking vision and build the trust that the thing people use right now will change over time, maybe change at amazing speeds. This is what, you know, startups are good at, changing rapidly, and people need to see what's happening. They're not just purchasing a service which is static. Right now, I'm buying what I need right now. Of course, I as a company also expect, maybe I'm purchasing, like Teamhood is a project management tool based on kanban, that's like unique approach to kanban, which is flow visualisation. It's also very close to the roadmapping, by the way. But in general, you can visualise many things. And people say, "Okay, so we start with team task management, but in one year we plan to triple our team size, and we will involve project managers, we will need some sort of alignment tracks to just ensure that we build the right thing." And they will need additional services or products on top. So if they see a well-crafted roadmap that fulfils that need, and the company's focused on not the static approach to what user needs, but also what will user need in one or two years, they will build that into the roadmap, so people gain trust. And then comes the rest, of course, team alignment, which we already spoke about. Everyone inside the organisation, if it's product driven, if it's product led, as it's convenient to call nowadays, everyone should be aware of roadmapping within the company. It is just your life, it's just your culture, you're product centric.

  - But who's maintaining it or who owns this artefact then? If they're talking to all these different stakeholder groups, they're helping align everyone, who's the owner?

  - Well, in my case, it's me. It's easy an answer. I am entitled to own such an awesome thing, because for me it is awesome, I love thinking about the future and crafting new brilliant or not so brilliant ideas, and helping people. In every organisation, I do hope there is a defined responsibility or even a role, call it product manager, call it product owner, call it initiative owner, programme manager, somebody who has this, you know, entitlement of decision power to influence the roadmap, because, still, somebody needs to be a single person thinking and collecting. It can be collective, but then, still, somebody needs to facilitate that community driven approach. So there needs to be at least one person. Ideally, a single person, because the responsibility lives best on one head, and if it's spread across different people, nobody's responsible, as we know. So yeah, hopefully it's a formal role or is just a hat. But it needs to be worn every day, I would say. People will have questions like, "Oh, should we do this?" And then somebody needs to get that answer. Why do we do it? Is it okay to do it? Should we do it because it's on our roadmap or is it another shiny object? What's the right, you know, decision making process.

  - And actually hinted at a really interesting question for me there. At what point do you think you'll hand that ownership over to someone else as your organisation scales?

  - Eventually I do understand that I will need to hand it. At our current scale, and probably looking up front, I don't think it will come that fast, because few things, until we make our market fulfilled or we have enough of success across the board, we will keep iterating what we already have. Meaning that it's not about spreading the product thin on various areas, it's about making product great in specific area that you focus on. This is important. And that doesn't require multiple people organising the roadmap, or product vision, or anything around, you know, stakeholders who influence the product. But once we say, "Okay, we need to address different needs, we need to address additional market use cases, or we need to even have a second product", that's when it becomes interesting and also tough, meaning we will have more people responsible inside the product engineering, inside the product management part, and we will need additional, you know, facilitator or alignment helper/person. So that that could be someone where I say, "Okay, that's enough. It's your hat, not mine anymore." But for me, it'll be hard. I love creating products, I love solving problems, and this is best job ever.

  - I mean, and if you're a product person as a leader, I can understand that. The time I usually find people think that it's the time to hand over is when they're so busy with the funding elements that they're neglecting the product elements.

  - Absolutely. For me, maybe I have at least temporary solution. I say, "Well, the best investors are end users. If we convince them, get the best deal ever." And everyone wins in that terms. So we're choosing the Bootstrap path is just, you know, more organic, more product centric, it falls under product led, you know, strategy. So it's about what you love doing, right? I do love talking about funding and finances, but product work is far, far more rewarding.

  - I hear there's a book called "Product Mindset", and one of the principles I remember in there talks about it should be self-funding from day one for a product. If it's not, then it's not really a product.

  - It can be both, I think. It can be what it's meant in that book, saying that if it's not able to self fund, that's a problem already from day zero, and you need to check your go to market, etcetera, whatever falls under that. But as we see in our nowadays, well, there are certain areas where you need to, you know, commit heavy upfront. Look at the whole, you know, artificial intelligence trend and craziness. I mean, resources committed upfront, they were insane. But the spark of payback is also insane if you track the metrics on day zero and first year of like ChatGPT or similar services. So it depends, right, as in every case.

  - Well, we've talked about the vision, the strategy, the objectives feeding kind of into it and creating that context and that shape. What else flows out of that roadmap? What other kind of artefacts or things link into it that we need to kind of consider the relationship to?

  - It depends on the structure a bit. What do you want to visualise in there? And this structure can deliver your understanding of order of things, understanding of priorities. Because again, if you make roadmap, not like single, horizontal, axis driven, where you just place a lot of coloured bars, and you say, "That's my roadmap", and things just fall in the line. Yeah, so you have calendar orders sorted, you have calendar schedule sorted. But in reality, as we know, things tend to take sometimes longer than we envisioned, deadlines come faster than we expected. And we end up doing more things than we should have done before. And this is an artefact, if you see that you already working on too many things at the same time, and me coming from kanban ideology, it's already a huge signal, because it's first of all, not efficient what you're doing. It's just too many distractions can result in shipping everything later than you would do if you ship one thing after another in a specific order, or just, you know, in specific sequence of things. A good roadmap must tell priorities, I think, because roadmap structure needs to have an axis telling you that if you get into trouble or you need another decision, just check on your priorities. They must be somewhere visualised, I don't know, stickers, extra colour coding, vertical axis to just say, something's on top more important than something's at the bottom. And yeah, that's like not a side effect even, it's a core effect a good roadmap should deliver.

  - Sure, and I love that idea of showing the prioritisation. Sometimes I show risk on there as an axis as well. Or grouping, and you talked about under a KR, that you might call that a theme or something like that, where you group things together, they're all driving towards the same group or the same outcome. What other things are we putting on our roadmap? You know, let's get really concrete, what are the boxes, lines, etcetera on here?

  - I think we tackled it a bit already. It's like, for me, it is something that moves a needle, tangible thing, which I, as a reader of roadmap, I can identify what it is and what kind of value will it bring? For me, it cannot be something like, oh, we're gonna, I don't know, upgrade our servers, or we going to use new technology somewhere. That's not an item for roadmap, because it doesn't tell the full picture why we are doing it, what value will it bring? So these items, bars, whatever we visualise them on the piece of paper, we can say these are, you know, pieces of value. And sometimes I do see examples of roadmaps where the items are clearly driven by more, I am, by the way, also a technical person, but I see also roadmaps which are driven by technical people, and these roadmaps, they resemble more of a like inside looking view. Anybody else won't get a clear picture, what the hell is going on, what we will do, why we will do it? Questions won't be answered. It is just a list of things, like a checklist. What do we need to do at what time? So this is an example of what's not a great roadmap. And it's my personal opinion, but I think if you do one, you need to involve different stakeholders and you cannot just do it that way. You need to be quite clear about why you're doing such things.

  - So it sounds like you are liking their, you didn't use the word, but you essentially you likened a roadmap, in that context, the bad ones to almost like a classic waterfall style project plan. Now, as someone coming from the kanban world, how does that kind of long term view, how does that fit with that short term adaptability of a kanban based methodology? What are your thoughts?

  - It's funny where we got with this question, I just recorded, like two hours ago, a video talking about why the discussion between kanban versus Gantt, or this more agile approach versus classical project management. Because for me, personally, I don't like this topic where people end up, because usually it's either one or the other. This is like wrong way to do things. Again, it depends. And what I was speaking in that video is, like, you should clearly see what you need at a specific lifecycle moment or time of your decision making. If you're just crafting something from bringing your idea or vision to something more tangible and that can be used for people alignment or communication, this is where you will use tools which have timelines, calendars, some sort of, you know, visualisation, what's order, what's the flow, and when should we expect certain things to be done? And Gantt is great at that. I mean, it was created for, you know, project planning. So it's still a good tool, right, for this case. But once you get into the trenches and start working, you might not use it that often, because it doesn't give you the right data visualisation. Again, it's about visualising stuff. So Gantt visualises data, which is for planning, so you can answer multiple questions. What's the order, what should be done, when it should be done, maybe who will do it, and what's the overall progress? That's good on Gantt side. In kanban, kanban is all about the flow. It visualises your workflow, it visualises your actual work. And by having things in kanban, you can discover what it is, you know, bottle-necking your process? Where you need to improve, because usually they pile up because the next step is not efficient enough. Somebody's not pulling enough work or something is wrong with the input, maybe you're producing too much input. So what's the point if your flow is not that efficient? And kanban is great at day to day, you know, operations. If I were to work on daily basis, I would go with kanban. If I need to do my, you know, monthly progress update and I want to check what's up, are we still on track? I would go to Gantt. So it depends what I'm doing, am I planning or I'm in deep intensive work and it's on the daily basis? So it's actually both need to be combined if you want to be very, you know, good at your decisions as well as at your actions. This is why I think you cannot just, you know, split this ideologies and say they are like mutually exclusive. Nope, I don't think that's right.

  - And maybe that's what Mr. Gantt was missing when he first brought it in, because from what I hear, the Gantt chart was invented when he was working on the Hoover Dam, which was delivered late. But that kind of understanding of the flow in the bottlenecks was probably not there. Interestingly, I'm also someone who's famous for saying, "Waterfall is not evil, in the right context." In the same way, it depends what I'm developing, what I'm working on. There are certain things where it works wonderfully well. Choose the right tool for the right situation.

  - You know, if you need to throw ideas on paper and it's for you, if you want to learn. If I were to do it, how would I do it? What would be the order of things? What could be the potential timeframe? But it's for learning purposes, it's not for giving it to somebody and saying, "This is my signature, it's carved in stone, we'll do it by the day X, and let's go", you know, and then you try to do it. Sometimes, you know, people move deadlines earlier just because client can pay more money for that. It's a good tool used in wrong circumstances, and you have result, which is negative, and everybody bashes the tool. Nobody bashes bad decisions, or at least at the first point, "Hmm, we used the wrong tool." Nope, not the problem.

  - Now, you talked about structure earlier and that kind of being how you visualise the roadmap. We've talked about a few examples there of a kanban and a Gantt chart, are there any other sort of styles of visualisation that you're a fan of in particular on a roadmap?

  - For me, roadmap represents vision, which is broken down into specific milestones or key results. And we say, if we do these things, usually there are not more than three of them, because having too many focuses is also bad. One is already great option to start with. And if you have a larger team or larger organisation, yeah, maybe you can do two, three, four, some number of them, but rule of thumb, less is more. And then these key results, they need to be clear, well described, maybe you need to think about how do you describe them, that's also important. People don't think about copywriting when they write stuff, but it is important, it's a skill. So you should be good at it, because everyone else will be reading it. And it's very easy when you write small, short, you want to be concise, you cannot write like A4 sized papers in your roadmap. So when you are concise, it's very easy to miscommunicate something and give, you know, mismatches with somebody's expectations. So for me, that's important. And if I know what is the vision, I see what are the clear, you know, milestones to fulfil that vision, and in each those milestones I see clearly tangible work items, which I understand why they will move the needle to the key result. That's the greatest, you know, roadmap for me, personally. And if I can share with users, that's already ideal. Because I know that my users will understand what we just thought in here. If it's only my language and vocabulary used in that roadmap, people will miscommunicate or misunderstand what's written, and they will not care about it.

  - Totally true. I mean, I tend to think of it, that visualisation as a storytelling tool, therefore those words and the copywriting angle is so important.

  - I'm totally with you on this one. There are many ways to visualise, and as I've said, each organisation needs to, you know, choose the right one. If you are a product organisation, you have cadenced to do things your way. If you are a service organisation where you deliver service, it's still projects. Maybe the end result of the project is a product. But if you do multiple projects at the same time, you will be visualising, like, projects and their milestones, because each one maybe is for a different customer. So each customer will get a dedicated roadmap where things fall in, and maybe it's a Gantt chart, maybe it's just a PowerPoint with, you know, certain listed items and deadlines. But still, you know, it depends and it works differently based on what people need.

  - So let's get a little bit more abstract now, Vidas, what do you consider to be best practise in roadmapping?

  - Wow, this one is very hard, because it's the best, right? The single, sole thing in roadmapping. And when you try to answer what's the best, so I think it's best to answer with the first thing that comes to your mind, because it's so important maybe, and it's so often used that it can be the best. I'm not saying it is the best. For me, it is about sticking to the vision, sticking to the end goal, that's really important. And the rest of the things are techniques and separate, you know, pieces of the puzzle. But if you stick to the vision, somehow you develop that approach to continue, you know, keeping it tangible from higher level things to lower level things, it can work magic.

  - Let's take the other side of that then, what are the biggest mistakes you see people making?

  - Oh, I have a really good pool of mistakes here, personal. So like, looking back, and doing too many things at the same time would be my number one. And it's the result. It's somewhat like a side effect from various bad practises. And there are many bad practises or even cognitive biases coming from, you know, psychology, that gets you in this side effect. Maybe one example would be, you know, shiny objects, when we try to, you know, add stuff. We've been working on something and you say, "Oh man, this is great, we should do it, let's just do it. We're a startup, we should go at it. We can do it fast." And then you have five things at the same time, all of them late, none of them at quality expected. So this is a really sad story. Then I think roadmaps that are too long, too forward looking. You can have that, if it's like research, maybe a good example is, yeah, we need to get to Mars by 2040, so we need to research delivery vehicle, we need to research, you know, sustainable environment for humans, we need to research how do we make fuel. So this research is so grand that you need to have a forward vision that long. But it will consist of various complicated pieces until you get there. Usually in technical world, or non-technical, it doesn't matter actually, sometimes I see roadmaps being created for multiple years ahead, and we already know that, for instance, in large organisations, there will be a change in management or there will be change in, you know, some sort of regulations, you will just throw away that roadmap. Like, the day something materialises, you will take that paper or software through the window and it's gone. So investing too upfront. And in startup world, I cannot emphasise how important is that. You should look further, you should have a grand vision and end goal, but you cannot create detailed things or two detailed things years ahead, because it's gonna change so fast and so many times that you won't be able to get enough value from it. And there are many more, there are hundreds of mistakes. But these are really costly ones.

  - We've all made so many, I'm sure. And that's fundamentally how humans learn, right? We make mistakes and hopefully learn from them.

  - We need to be fearless in this case, Making mistakes is fine. I mean, the whole art of doing business is just picking the right problems to solve and doing the right mistakes, or minimising the amount of wrong mistakes, that's the art. Everyone will do it anyway. Maybe the last thing to add about these mistakes is I don't want to be too strict on saying long vision, short vision, and keep focus, don't lose focus. Sometimes circumstances, again, it depends, can bring you to the point where you can say, "No, this vision or this key result that we expected to move our vision is not working out. It's not gonna work. We have all the evidence or we have enough of evidence that is gonna hurt us in the end." So having blind commitment is also bad. But how do you balance between, you know, sticking with this stuff and not being blindly committed? That's, again, art, and everyone needs to be, you know, looking at their own environment and context to make the right decision. For me it's hard, every day can be hard on this decision.

  - So I've heard a bunch of your advice so far. Whose advice do you listen to?

  - I couldn't name one single person who would be the solo advisor. It's a bunch of different things. I like reading about ways of working, and there there is a great book by Dominica DeGrandis, "Make Work Visual", I love that because it's about kanban. It is about maybe smaller scale stuff, but I mean, it's applicable and it's scalable to grand things like visions, and you know, project programmes even. If it's about people who I discuss with or talk, there are great communities about products, Slack, Discord, maybe even LinkedIn group, I think I saw one with the same title about products, just product people. So how did we meet is, like, this guy Martin, so I loved his approach about goals. He speaks about sprint goals. But in general that's the same. Roadmap can be one big sprint with the right goal. It's just, you know, you need to break it down into smaller pieces, and there you go, that's the same theory applied on roadmap. So it's a bunch of things. I try to do something, learn from it, get new ideas, try to apply them, learn again, and combine. So anyway we end up working in our organisation, it's a mix actually, it's a mix of different things. And that's why maybe I'm so relaxed about saying, "You cannot say it's one or the other." No, you can combine stuff as well, that's not a problem.

  - If you had to distil your philosophy on roadmapping down into one or two sentences, what would it be?

  - Well, it is a forward looking collection of things that we will do that will drive value to our goals. And by goals, it cannot be more than three. That would be my two sentences.

  - So Vidas, it's been wonderful having today. Always like to give people an opportunity towards the end of the session just to pitch themselves and their organisation, I guess, how Teamhood can help? Fire away.

  - Yeah, thank you for that opportunity. And for us in Teamhood, and if listeners have been listening towards this point, they might have already learned, we are product centric. We want to deliver a really valuable, tangible piece of software for those who are trying to work with projects at scale, or they want to organise more complicated environments, but they don't want to take complex tools. Complicated doesn't mean complex and vice versa. That's why we create Teamhood, which is like simple, visual, and flexible software. It's a lightweight solution. And you will find both kanban, Gantt insight Teamhood, because we are not like, you know, opinionated how person should work. We create a toolbox. A person needs to be, you know, comfortable with that toolbox, and they will have a choice, that's really important. Give people choice. So this is our philosophy, this is what we build in product every day, and this is what the whole team follows. Yeah, so just check out Teamhood. And I do also have a lot of videos, so you don't need to even, you know, register to try it.

  - Awesome, well, we'll make sure there's some links down below as well. Great, well, Vidas, it's been awesome having you on the show today. Thanks very much for your time.

  - Likewise, Phil, it was pleasure.