What does your roadmap tell you about your culture? | Kenan Akbas

In episode 69 of Talking Roadmaps, Justin Woods interviews Kenan Akbas to explore how roadmaps reflect organizational culture. Kenan shares insights into linking vision, strategy, and objectives to roadmaps, identifies key elements of effective roadmaps, and highlights common pitfalls to avoid. He also discusses how roadmaps can foster alignment and communication across teams.

Kenan Akbas is a visionary entrepreneur and product innovator. As the founder of three startups, including Handcraft Health, Alignwith, and Unified Practice, he is transforming the landscape of healthcare and product management through cutting-edge solutions.

Kenan’s entrepreneurial journey began with the creation of an electronic health record system for traditional Chinese medicine, inspired by his time working in hospitals in Taiwan. His latest ventures, AlignWith and Handcraft Health, continue this trend of innovation. Alignwith is an AI-powered product management platform that automates cross-functional communication, while Handcraft Health focuses on prescription fulfillment for health and wellness practitioners and the patients they serve.

Originally from New York City, Kenan has lived in San Francisco and Taiwan and now resides in Denver, Colorado, chosen for its vibrant startup ecosystem. Passionate about solving complex problems, Kenan’s mission-driven approach continuously pushes the boundaries of innovation.

Kenan is dedicated to mentoring the next generation of entrepreneurs. He frequently speaks at industry events and podcasts, contributing to thought leadership in the product community and sharing his insights on innovation and startup culture.

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).

What does your roadmap tell you about your culture? | Kenan Akbas

Justin Woods and Kenan Akbas

In the next episode we are talking to Andy Budd, Investor, Advisor and Coach. So watch out for Season 1 - Episode 70!

• Transcript

  - It's up to us to look at the people we're talking to, know how to talk to them, and present this in a way where you can say, "Look, we're making a bad decision here." And if you did it, then you did it. And you've done that exercise and you've done it without pissing anyone off, it's a success. Whether or not they decide to come to your side or not. The exercise of caring enough about the company that you say, "Hey, this is gonna be some bad stuff."

  - Welcome everybody to the "Talking Roadmaps" channel. Today, I'm joined by special guest Kenan. Kenan, introduce yourself, my friend.

  - Yeah, I'm a product guy. I love to build stuff. Before that I was a physician, studied Chinese medicine. Before that I was an artist and at some point I took, you know, my artistic vision and applied it towards a solution in healthcare. And I got infected with the bug of building stuff, trial by fire. I had to just create a software product without knowing much about how to do that, and kind of cut my teeth along the way. Over the last, you know, 12 years, I've, you know, come a long way.

  - If you're enjoying the channel, subscribe, hit the bell icon and give us a like. Amazing, and serial entrepreneur within product, within CPO, CEO, different capacities there. So I think we're gonna have lots to talk about. Kenan, let's go straight into kind of talking about what do you think is the purpose of a roadmap?

  - To me, it's a harmonizer. It is a harmonizer because it takes alignment as a first kind of requirement. At least, how I think it should be done is that there's an alignment between what a customer needs, what the business needs, and you're putting those into a plan, getting buy-in, and then communicating that through this beautiful thing called a roadmap. There are good and bad parts, but you know, the roadmap is a harmonizer because it should show what we're doing and why. And when you have that, you have context and you have clarity and you can get people to feel more connected to the work they do, so I think they're amazing. I think they can be terrible, too. I guess it depends who's doing the roadmap.

  - It does, there's two bits that I really loved, first off, straight off the bat of what you said there, a harmonizer. I've not heard that term for a long time around roadmaps, maybe 'cause often there's not harmony, but that's the intent, right? The harmonizer, I think. Yeah, I love that. The other bit that you mentioned is around the customer and the business needs. And I think both of those are important. You know, we're here to solve a problem, yourself with Align With and the other products you've worked with and companies, they're there to solve a problem. But also we need to run a business and you need to have that balance of both. Because if we do everything that the customer wants, the business might not be successful. But if we did everything the business wants without the customers, we might not, you know, be existing for much longer, if we always focus on ourselves.

  - And I think that, you know, if you want to keep solving problems, you need to keep, you know, a healthy business so that you can continue to do that. And yeah, you're 100% right.

  - Yeah, absolutely. So if it's a harmonizer, what is the audience? Who are we harmonising?

  - It's the company, it's the village. I always see a company in my head as less of a pyramid and more like people holding hands around a bonfire. You know, we are all as important as each other. Again, if your customer support team walks out the next day, I mean, you're pretty screwed for a while. You know, and those people often aren't valued. So roadmaps have to speak to everybody. The problem is, I think where people get caught up is they check the box and they're like, "I did the roadmap. Here it is, here it is in Slack. Now it's your problem." And you know, I think that happens when the culture's fucked. You know, I don't know if you have to beep that out.

  - No, we'd probably be happy to keep that in. But yeah, I think when, you know, the culture is just completely messed up, right? Is just, we've got problems there. We've got bigger problems than even a roadmap, the culture and the people.

  - And I think that the roadmap can serve as a way to improve culture, because it's not the roadmap itself, it's the process of creating that roadmap that creates that harmony, 'cause you're spending the time to get understanding and buy-in from different stakeholders. And the process of doing that and communicating that and taking the time to talk to these different parts of your go-to market team or C-suite is what creates that harmony. The outcome is the roadmap. It's like, "Here it is. Here's of all those activities we just did." The thing is that a roadmap shouldn't look one way. And I think that is where things get a little dicey because, you know, if you break it into two camps, you've got, let's just call it like technical and non-technical. And even in non-technical, you have high detail and high level. And so if I show a roadmap to your average CEO, the way that I show it to a go to market team or a marketer, I'm gonna lose their attention relatively fast. You have to look at who you're presenting to and you're saying, "Okay, well I need to speak their language." And if I'm presenting to C-suite, I'm gonna be focused primarily on something that looks more like high level bullet points with, you know, very concise and clear reasons for the things we have, why we have them, the data to support them, and talk about the risks and rewards of all the things that we have up on the roadmap. And now if I show that to a customer support person, it's not that valuable, right? Because their job is to figure out "How am I going to support these products that you're putting out," you know, "and I don't understand much about them. So I think that showing it another way that has more detail, more visual components, more things that convey a message with enough information to be valuable, but not enough to create cognitive overload.

  - Right, or even oversharing, right? Sharing too much.

  - Exactly. And I think that we're not taking our designers and saying, "Hey, here's this presentation," you know. "Can you create one for, you know, C-suite?" They're busy, right? They're like, "Well, should I do that or continue working on this project that we have to get out the door," right? So, you know, it lands on product a lot of the times and to do that and product is often stretched thin and looking for a moment just to do some R&D you know, just some research and development- Talking to customers, discovery.

  - Communication materials, right? So often what happens is like, "Here's the thing, I did it, and that's it." And that's where you start to lose buy-in, because not everyone understands what you're doing and why you're doing it. And different personas, different stakeholders have different ways of seeing the world. And so your roadmaps have to be presented in a way that's going to reach them, if it's a communication tool, right? If you believe that it is.

  - It's a communication tool, it's an alignment tool. And that's a nice segue, actually, into your company at the moment. So Align With, this is a big problem because I think people will do the checkbox, think they've done the roadmap, it's about them, not about the audiences, but alignment is a big issue. And you've spotted a niche in that area there where it's kind of like, "Look, we can no longer show different audiences the same thing."

  - We can't expect people to always come to our side. And if we want people to have affinity for us, we need to come to their side and show them that we're willing to do that. And that is by taking the time to create those communications. The thing is they take a lot of time. And so yeah, I mean, what we're doing at Align With tackles, you know, that problem. You know, where a product management tool that takes that technical information and product, your PRDs and all that stuff and creates instantly shareable content that you can give to your go-to market teams, right? So that they understand what you're doing and why with full context, but you don't have to spend the time sitting there, designing it, creating it, even content. You know, we have AI generated text fields to help them write the content and write prompts and fill all that stuff out. So transforming PRDs into instantly shareable presentations or roadmaps or release notes or anything related to communication.

  - Yeah, and in fact, you know, I had the pleasure of you sharing some of this with me in a previous talk that we've had. And I was really impressed with the kind of the newsletter type, friendly type, polished web type experience that I got from the tool where it was actually showing me things that in a way that I wanted to read was simple, it was targeted for me. It shared with me what I wanted to see. And that took me quite by surprise, 'cause I've never really seen another tool do that. And that's one of the things that kind of had Align With stick out in my mind was I felt like it was generated for me, because it was.

  - You know, a lot of times we're taking this technical information, we're like, "Okay, this is how I've spoke to the developers, now I have to speak to other people." And really, you're just taking that and you're oftentimes re-presenting it in another technical form. For us, design matters. It's what allows people to feel that something is better. You know, there's lots of studies where people, you know, you'll have the same exact, you know, software with the same capabilities that one looks better than the other, and everyone thinks the one that looks better is better, right? So, you know, we're taking this, you know, laws of UX kind of very seriously in what we do. And you know, we're taking, you know, that technical information and we're bringing it into a format that is beautiful and familiar. You know, it's designed or, you know, after a landing page of a website. So like, not just another slideshow.

  - Yeah, that was definitely the vibe that I got.

  - Webpage, and that feels familiar. And a lot of what we do is, is not showing everything all at once. We show things in ways that as that curiosity strikes, you can expand and collapse information, that way when you're looking at it, you don't feel like, "Oh my God, I can't read this right now." You'll click on those things and they expand and yeah, so that's, you know, another few examples of like, you know, how we take the laws of UX, and, you know, apply them to roadmaps and release notes and everything else.

  - And in fact, let's talk a little bit about everything else. So what do you feel is the relationship of a roadmap to say vision strategy objectives? Do those things coexist? Should they coexist?

  - Absolutely. I mean, for me personally, you don't really, I mean, you could say you have a roadmap if there's no strategy in there, but most likely there are much bigger problems, if that is the case, that you've got to fix, you know, at the company level, which might be in especially early stage companies being reactive, they have a new product and they don't wanna lose a customer and they're zigzagging, they know where they need to get, but they're, you know, working on the latest fire. And so that whole roadmap is basically just putting out fires.

  - Yeah. One big piece of fire.

  - But make that a strategy, put out fires, okay. Like, that way you can attach it to something. But I think that making sure that you have a strategic direction and that the things you're building are helping you get there so that you're moving true north is part of the exercise of road mapping to me, because that informs kind of the foundation of what we need to put in there, right? It's like the base stock of the soup. It's the dashi in, you know, miso soup, right? Like yeah, miso, we're talking about miso, but actually, you know, the base is dashi. And what we need to do is that has to be the company strategy. And that company strategy should be a mix of, like we said earlier, what things have we chosen that helps move the company forward and delights customers? So you have to find this medium and go, "Okay, that is going to do both things. This is what we're gonna do and it's gonna help us," you know, and connect that item to something strategic, one or multiple parts of your company strategy. But like, 'cause when we talk about strategy, we're creating this bucket, but there are two strategies, right? There's the company strategy and there's the product strategy. All you have to really do is connect to the product strategy because the product strategy, if you know, written correctly is already connecting to the company. So you don't need to like worry about that. You need to just say, "Okay, how do these items connect to the product strategy?" And if you can't connect it, let it go and explain. And if there are people who attach to it, depending what the company looks like, this is where you need to go to them and start communicating in a way where you can bring them to your side. And to bring them to your side usually requires that you have some data to back up the reason. Because that's also another harmonizer. I don't know, you've been in this situation as well, but it's like there are these times where, you know, people feel very passionately about something and they really care about it. And you know, and when you start to show them the metrics behind it, they begin to make their own choice. That you're, you know, that the direction that you're trying to take things makes sense without creating an argument. Like the data kind of ends the arguments because it makes people kind of second, "Oh, you know what? Yeah, that other thing you're doing, that is gonna have a bigger impact and you have the data to support it." Or, you know, I've often asked people who feel passionately about stuff to, you know, help us, you know, build a case around this and let's pull together the data. Maybe I'm wrong. I mean, I think that's always the thing that keeps a culture around product healthy is like not assuming you're always right. And so, you know, you could be relying on data that's not that reliable if you haven't questioned it hard enough. But maybe you really want it inside, so you maybe don't want to question it too much. You know, you're like, "Okay, well, let's really, you know, prove it." Like let's work together to figure out like maybe this is a bigger idea. And I think that leads also into this idea that I've often struggled with with roadmaps, especially with engineers is a lot of my experience with engineers is like, "Show us the roadmap for the year." I'm like, "Okay, well it may not be the same." It most likely won't be. And I think that's, you know, part of culture as well, which is creating this understanding that data is gonna be the driver and the decisions we make and data may come later. And that might mean we need to swap out one thing for another, because it does more for the customer and more for the business. And I think that's often a place where things can create friction, you know, when it's like, "Well, you have to tell us that we can plan" and you know, all this stuff. I'm like, there just has to be this comfort with some uncertainty that-

  - Yeah, there does. I mean, you know, "Roadmaps Relaunched," one of my favourite books on the subject, talks about how to set direction whilst embracing uncertainty and things like that. And that's such a succinct, but great way of saying it is like, "How do we, you know, be able to say this is where we're going," but still say, "Look, these are some of the things we know, these are the things that we don't know." The one bit that you mentioned in there that I really liked was kind of not going back to stakeholders and saying no, but it's redirecting that energy of maybe the pet project or the thing, not even a pet project, but the thing that they want to build or to work on. And saying, look, being objective about, I'm a big fan of being data informed, having empirical evidence. Itamar Gilad's confidence metre was a great one for me in terms of looking at things and being able to say, "Okay, well we are doing this based on anecdotal feedback" all the way through to, you know, we've done user research and having that factor into there. But even if it comes back that stakeholders just asking for something and they don't have anything more than the hunch, not going back and saying no, I think part of that is that, you know, the Align With and being able to have that conversation with them to say, "Actually, look, it doesn't really stack up too well with what we've got on the roadmap at the moment, but help me to understand it." It's not a no, it's just help me to make this the best it can be. So it's up against everything else because as product managers, we're here to de-risk things and we're here to deliver value. That's what we're going to do. So help me to make a case for it. And I've not heard it in the way that you explained it, but I really liked it.

  - Yeah, and I think it's part of our job to bring people to a decision without having your ego get in the way. 'Cause it's easy to let that happen and be like, "Dammit, you know, this is how it is, this is the way," you know, like it just shuts the door. "I have spoken." "Mandalorian" references, but it's one of these things where like you have to, like, depending who the stakeholders often hear, like product managers go, "The CEO, you know, has all these crazy ideas," but I think there's a part of you that has to step back and go, we have a business with product market fit based on these crazy ideas. You know, it may not be in the nice neat way you want it, but that is not necessarily how the company was created. So get closer to those stakeholders, create better relationships with them. I think that people are afraid too. They don't wanna lose their job and they just wanna check the box and go, "I'm not shaking the boat. That's what they want, that's what they want." Again, it goes back to a cultural thing. You know, can you create an environment where you can question the founders and have the founders made that comfortable to do, you know, and have you hired the right people, you know, who are okay, one of the big interview questions I have is very much around like radical candour. Like can they handle, because in environments, especially with startups, there's a lot of passion, I think people need to say, instead of, 'cause it's easy to get like triggered and get upset and when someone's like fired up. But I think you have to take a step back and go, "Well, why the hell are they fired up?" They freaking care. That's the best thing you can have is someone who's fired up and like, really just angry we're not building this thing. It's like, all right, you know, that's great. That's 'cause they care about the business and they care, there's something that they really, truly believe in. I think that's often, you know, a perspective thing, you know, as a product manager you just get pissed. Like "They won't listen to me," right? Or whatever. Well, that's just how it's, you slam the door on them and that's gonna create more friction in the business, you know, so, but yeah, I think radical candour is an important thing to hire for.

  - No, it's good to hear. And that's obviously one of your techniques and it's important, right? Because like you said, we're all moving towards the same thing. We all want the same thing, which is success of the company and to solve customer's problems, so that makes sense. Let's dig a little bit into design of a roadmap. So rather than a big line of fire that we talked about earlier, it's kind of like everything's on fire and things like that. What are kind of the key elements or content of a roadmap? What do you like to see? And maybe even with Align With, what does Align With actually help clients with?

  - Yeah, I mean I think the key elements to the roadmap is if we just like stay high level, one, it has to be based in strategy. So the roadmap itself, right? Whatever it is, there needs to have some semblance of a direction. Otherwise whatever you put in it is random. And if you equate it to like a rocket ship with uncalibrated boosters, it's not gonna make it to orbit, right? Like it's gonna like be all over the place. So that's like one of the core like, you know, recipes in that is having that. Obviously the items you put in there, as we've talked about earlier, should be predetermined that they meet those requirements of moving the business forward and, you know, delighting customers. Another thing is that it's easy to understand for that stakeholder, going back to that design portion, right? Like as is this going to reach the person I'm talking to or that's supposed to understand it? And you know, I think that, you know, those are kind of like three like high level, important components. Now you have different ways of looking at it. You have initiative focus and timeline focus and all these other ones, so I think that that also just kind of plays into like who are you talking to and which type of roadmap do you want to show them. I often hear, especially in product, like this anti timeline thing. I'm not a fan of it, honestly. I don't subscribe to an anti timeline. I actually have and enjoy timeline roadmaps. Where it's like, yes, you have initiatives and you can create these buckets and these themes, but at the end of the day, if we do not deliver, the company will fail. Whether it fails quickly or whether it takes a longer time, it's not gonna meet its objectives, because the things in that roadmap are strategic drivers, if you think about it like that. And if you cannot release those strategic drivers to make the impact that you've bet on within a certain amount of time, you're in trouble. So I think that yeah, having, you know, and I think a lot especially go-to market teams, I think everyone but product wants to see a timeline roadmap because they need to prepare and they also need to understand that it is living, breathing, and is going to change, right? Even if it won't change, I tell them it's going to change, because I want them to be prepared that if we find an opportunity that is bigger and it matches something we wanna remove or one or multiple objects that remove that fit into the scope of the amount of, you know, hours we have, you know, development resources, all that stuff to build the stuff, that we will swap it.

  - I guess one of the common antipatents that people talk about is they don't like to see dates on the roadmap, but we've just talked about that and I absolutely agree with you as a product manager of a commerce basket and for handsets and support for Vodafone, dates were absolutely imperative, if I missed a legal or mandatory date, I was in hot water. So we can't use that one. Then both of you and I kind of agree that actually it can be important, but are there any other antipatents or bad practises that you see on a roadmap?

  - Definitely. I'd say like, well one is I often see that there isn't a clear strategy. And unless you have the talent on the team or someone is providing that team with a vision, it is hard to come up with a strategy. You have to have the right talent to think strategically and kind of look further out. Things are in there to appease people and aren't evidence-based. "Well, this is gonna get them off my back" and that shouldn't happen.

  - We need to be comfortable having harder conversations, I think, rather than the classic product manager, it's on the backlog or it's on the roadmap to appease. I think we need to be more comfortable having evidence-guided, data-led, honest, frank, radical candour discussions with our stakeholders, right?

  - You know, it keeps coming back in this loop to like, "That's a cultural thing." It's like, can you do that? Do you have the right environment to do that? You know, I've definitely talked to some PMs that, you know, are in a situation where they're like, "I just need to keep the lights on and keep getting paid. I'm not rocking the boat." I always feel like that's unfortunate. I'm like, your job is to kind of show them they're making the wrong decision here. And it's like, "Well, it's their decision and that's that." I think that's, you know, that does come down to a cultural thing. Like it's not an environment where they allow pushback of ideas. And I've been there, I've been there where, you know, the company has said, "Hey, you know, we like straight talk" and then you straight talk and they're like, "How dare you." And you're like, "Oh, I won't do that again."

  - "That's not the straight talking we meant."

  - I will not tell you you're making a bad decision again. So I think, you know, it's one thing to say it, it's another thing to do it. And I think, yeah, so you know, a lot of, like we talked about earlier, like a lot of checking the box. It's like, you know, I think a lack of desire or time to create roadmaps that are going to speak to your audience, I think that's a bad practise, right?

  - Yeah, I think sometimes if that's the situation that you find yourself in, the roadmap can be more harmful than good. It would be better to not have a roadmap than to create one incorrectly. And I think that's where a lot of people come up to getting these challenges with roadmaps, falling out of love with them, not feeling that they're needed. I think that's where a lot of it is. It's just a misunderstanding of what the roadmap should be. And that can even be a misunderstanding or a misalignment between the person asking for the roadmap and the person creating it. Because if they both had a common understanding of what it was that they wanted to see, then actually the alignment would be there.

  - Absolutely. And I think it's part of that also, like if you know that ahead of time and then you won't feel so hurt when, you know, spend all this time with this like very detailed, beautiful roadmap and you hand it to, you know, C-suite and they're like, "I can't look at this. Can you gimme some fricking bullet points?" And you're like, "Ow," you know? But if you know that ahead of time, you create multiple versions and say, "Okay, this is gonna be for C, just create a couple buckets and create, you know, spend the extra time to create a couple of versions that are gonna have impact," right? Where your outcomes are gonna be that people feel connected to this vision and what's in that roadmap. So yeah, I think those are, you know, some bad practises also. I think it goes back to what we just said also, which is the roadmap just serves the company's needs. I think that's probably a bad thing. And I've seen a lot of that happen where they're prioritising like internal projects that don't bring much value, although those eventually need to be done, but the prioritisation for that isn't always in line with what's best for the company. And the customer. So I think that's also a cultural thing where it's like, "Oh, they said they wanna do it, we're just gonna do it." I'm like, "Yeah, but you're not gonna launch X, Y, Z" and you're not gonna have that impact you've been planning to have. And do they understand that by doing this, oh, you know, "Well, they made the decision." So I think, again, coming back to this idea that it's up to us to look at the people we're talking to, know how to talk to them, and present this in a way where you can say, "Look, we're making a bad decision here." And if you did it, then you did it. And you've done that exercise and you've done it without pissing anyone off, it's a success. Whether or not they decide to come to your side or not. The exercise of caring enough about the company that you say, "Hey, this is gonna be some bad stuff or potentially maybe bad stuff. And are you okay with that?"

  - You've obviously got a lot of experience in the product world, the road mapping world, and what you are building with Align With. I'm curious whose advice on road mapping and product management you listen to, because obviously you're kind of building a tool for these people, so who really resonates with you out there in the world?

  - I mean, I think that the, you know, product roadmaps, the book was very influential for me, especially in the early days when I was trying to pull us out of a build trap. So Melissa Perri, wanted to bring that up, like that was very influential, "The Build Trap." It's kind of one of these things where as the company was scaling up, we had a lot of that, you know, stuff on a roadmap that was like just putting out the latest fire, right? So, and we had a strategy, we actually had one, but we weren't reaching it, 'cause we were zigzagging because we were like, "Oh, we want to go here. Oh my god, there's this thing." And then you just go off to the left and then you come back and you're like, "All right, recalibrate, we're gonna go, oh, this other thing." And you start prioritising stuff because you don't wanna lose a few customers. And so being brave enough to stick to strategy and losing a few customers along the way is something I've learned to stomach, you know, over time. But I think a lot of, you know, the experience that I've gotten was through books and at some point, you know, like reading it and and going, "Oh, we've got that problem. I'm gonna try what they suggested, or I'm gonna research another methodology to tackle this and see what our outcomes are and not be afraid to just try it. It's gonna be better than what we have. And I think that's been the experience over the years is like, as you try these new things, they sometimes expire, based on scale. Like they no longer work because the organisation got bigger, they worked before and now we have to find new frameworks that, or create our own that are going to solve the problem. A big, I dunno if you've heard of the book "Subtract," that was the more recently influential book. It is about improvement through subtraction, a product book per se, but it is a product book.

  - It's product learnings deep within.

  - Yeah. "Laws of UX." That's a big, another influential book on me, which I made each one of the PMs, designers, everyone, even if they said they read it, we had a club-

  - Read it again.

  - We read it again. You know, we take time every two weeks to talk about those books and share those ideas and you know, kind of make that, you know, a part of constantly improving, right? 'Cause I think there's-

  - Absolutely.

  - So much time like spent doing the work, but not improving your skill sets, 'cause it's like, "Where is the time?" So you have to kind of make it a part of the experience in your product team, like, "Hey, let's pick a book."

  - You know, I love that. And actually, you've got different levels of the company all learning together from the same material. 'Cause it's not just the product team, like you said, it's cultural, it's C-suite, it's different levels within that company as well. So I want to finish up, I've got two last questions for you. So the first one was, if you had to distil your philosophy of road mapping into just a couple of sentences, how would you describe it? And you've already used some killer words at the beginning here, so if you wanna reuse those then do, but what would your philosophy of roadmapping be?

  - They have to make sense to your audience. It's like the primary thing. They have to be rooted in strategy. It doesn't matter the type of roadmap, it doesn't matter if it's timeline or initiative or you know, whatever. The items you place in there need to be carefully chosen to drive the company forward and yeah, make customers happy.

  - There you go. I was gonna say the customer's in there as well. Fantastic.

  - There should be a conversation with the organisation and an agreement in the way that we operate that roadmaps can and will change because, and not just that, but roadmaps can and will change. And the additive to make that roadmap flexible is data. If someone can come to me and go, "I've got this other thing that's gonna have twice the impact of this other thing that we have." Okay. You know, the data creates enough confidence that they're right. We get buy-in from everyone else because we have data to support that. And then we all make the gamble. We make the bet and swap it out. Talk to engineering and, you know, make sure it's feasible or trim it back to where it can fit, right? It's important enough to like minimise that V1 to where okay, yeah, exactly. Exactly. Oh my god, it's always on my mind. It's like we're dealing with big complex problems and it's like, "All right, what if I take this away? Oh that works. Okay, let's do it." You know, so.. It's always trying to like, you know, figure out how to improve things by subtraction as well.

  - Yeah, definitely. So look, the last question I have for you is we've talked about roadmaps and the fact that alignment is so important. I know yourself and your co-founders are already working on this problem as well. Tell us a little bit about Align With and also let our audience know how people can find you, 'cause a lot of what you've said today has resonated with me and I'm sure it will with them as well. How can they best find you?

  - Yeah, so you can find me on LinkedIn, I'm definitely there. You can also reach out to me at Kenan, K-E-N-A-N, @alignwith.io. In terms of what we've built with Align With, it's essentially at its core product management tool. It's an AI powered product management tool that takes all that technical information and creates ready to share content for your go-to market teams, for your stakeholders. So that applies up and down the board from the story of the company, right, where things started, where you are now, where you're going, to your company and product objectives to roadmaps to ideas to internal release notes to customer facing change log, all of these things we make so much easier. Essentially on our platform you could literally grab a Google spec, we'll turn it into a presentation. That presentation can go to a release. You click one button, you get one click release notes. You push one more time and you can push it to a customer facing change log. So it saves a lot of time from having to sit there and create this content where you basically just play with our preloaded prompts or create your own prompt to refine that information and make sure it sounds the way you want it to sound and publish. So yeah, that's kind of what we do. We're taking this idea of like how do we bridge the non-technical and technical teams to bring them closer to the business and the product. And to do that, we need to speak in a way that our stakeholders can understand or different stakeholders can understand.

  - We need to communicate, we need to align and it's in your company name.

  - The key to that is making sure you're doing it while not giving a PM or the product team more work, 'cause that is the scariest part of like, "Wait, I'm gonna adopt this new tool, now I've gotta do more work to maintain stuff" and we've made sure that that's not the case.

  - Yeah, it's massively important, you know, because I think it is more impactful when you have that different alignment, those different views. It is more impactful and potentially, it's worth going to do that extra effort or have a tool do it for you for minimum efforts so that it really resonates with each of your target audiences and that's really the point here. All right, Kenan, it has been an absolute pleasure talking with you today. Thank you so much for spending time with us. Guys, thank you so much, Kenan, thanks again. I'll speak to you soon.

  - Yeah, I appreciate it. Thanks for having me.