How long should it take to make your roadmap each month? | Malte Hans Scholtz
In episode 44 of Talking Roadmaps, Justin Woods interviews Malte Hans Scholz, the co-founder, CEO, and CPO of airfocus. They discuss the optimal time needed to create a product roadmap each month, emphasizing efficiency and flexibility. Malte shares insights on balancing detail with agility, using airfocus to streamline the process, and common pitfalls to avoid. This episode is a must-watch for product managers seeking to enhance their roadmap planning.
Malte is not only the co-founder, CEO and CPO of airfocus, but also a product manager and entrepreneur with deep product management knowledge and a strong track record of developing SaaS and mobile tech. Malte brings his high energy and enthusiasm wherever he goes.
Have a watch and if you enjoy the video don’t forget to subscribe to the channel, like it and maybe sign up to our mailing list!
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 Elliot Golden, B2B Product Leader. So watch out for Season 1 - Episode 45!
-
- Welcome everybody to the Talking Roadmaps channel. I'm absolutely thrilled to have another episode with you here today. Today I'm joined by Malte. Malte, please introduce yourself.
- Hi, Justin. Thanks so much for the invite. Yeah, my name is Malte. I'm one of the founders and I'm also the CEO and CPO of airfocus. We are an end-to-end product management platform, and we are the only hyper flexible platform in the market. So the whole architecture of airfocus is built in a very modular way because we learned that, especially large organisations, they're quite unique in how they work and they need, like, flexible tooling to do product management right and to also get a single source of product through it.
- [Host] If you're enjoying the channel, subscribe, hit the bell icon, and give us a like. Yeah, I think I got some of that from some demos that you guys have been doing around the different things that you can plug in and the way that your architecture around airfocus is created. So yeah, I'm really excited to jump into that. Fantastic. Well, let me introduce the show. So welcome, if you're new here, this is a Talking Roadmaps channel. We'd love to talk everything roadmaps with roadmapping experts, tooling owners such as Malte, and some practitioners as well. So, Malte, let's talk roadmaps a little bit and maybe back to the fundamentals of, from your perspective, what is the purpose of a roadmap?
- Great, love that question. So first of all, before we start, like, I'm not a roadmapping expert. I'm a founder of a company that provides product management software and I have an opinion and I have a take on roadmapping, but it's from the kind of mind of a startup founder and a product guy, and it's just another opinion.
- Excellent. Yeah, makes sense.
- So yeah, what is a roadmap? A roadmap is a guiding document that explains to people how to achieve your vision and how to implement your strategy. It's very related to the product goals, which themselves are related to the company goals and a lot of, like, things around how to do them, what format, whether to put dates on that. I'm sure we will dive into that. I'm a bit torn between these two worlds of the startup roadmap, which I kind of own. And then, like, the roadmapping problems of our larger customers where there's, like, a very different problem space and very different, yeah, a very different situation. So in my case, we have a small team of 50 people. We are all pretty aligned on the mission. We have one product, not 10, and it's very clear the direction and for us, it's fine to also put features on them that are very concrete, solution-oriented that maybe have a quarter on it, whatever. But I completely get why, like, maybe a large organisation with silos and cross team, cross product collaboration independencies where you need to have, like, a very different approach to roadmap.
- Yeah, massively important. Two takeaways I'm getting there from what you're saying is that in classic product management, it depends, but I think it does. It depends on where your product and your company are in terms of their maturity and what we're trying to do. But also something that you picked up on there, which I think is important as well is the difference between company goals and kind of strategy and the product goals and the strategy. So I'm seeing a kind of a tiered approach here and I think that's really important because some of the clients I work with don't necessarily have that visibility. And yet that's something you're seeing and is really important.
- I think it's a must-have and if you don't have it, try find a way to make that happen. But you need to have some visibility into the company objectives, especially in these times where the macro dictates so much of what is possible and the resources we have and what is expected. Yeah, so for that reason, we also very recently launched a big product update to airfocus around OKRs. So we have the option now to manage the OKRs and airfocus and our customers, what they do is they, on the highest level typically create an OKR workspace in airfocus where they manage company objectives and then they create, like, these sub workspaces for either department OKRs or like, OKRs per product division, right? But you wanna see that breakdown from the very top company objectives that are maybe for the next 12 months. And that don't change so often, but then down to quarterly or bi-annually, a team or product OKRs that then also link to your roadmap and the work that's happening in all of the teams epic spaces and opportunity discovery pipelines, et cetera.
- Fantastic. I think that's really important. I'm thrilled to see that kind of what we just discussed, that cascade from your company strategy...
- Yeah.
- Down to your products and departments. And it's also about setting the direction but not necessarily being specific around how we're going to cover those. So these are...
- Yeah.
- The kind of the outcomes we want to achieve.
- Yes.
- But empowering your product teams to work out how they're gonna do that.
- Absolutely. And for example, what we've, or how we've built it is that you can create key results where you can link your product work to them, yeah? So even if these, like, the status of your roadmap items, even if they don't directly impact the key result, you still wanna make that connection so you can see, okay, this is the stuff that we do in order to achieve this key result and then the upperline objective.
- Absolutely, totally makes sense with me. And some of the people I work with in service related departments or functions, they don't necessarily roll up into a product-level OKR. So having this kind of this different tier and also allowing your OKRs at the lower level, not to necessarily be always product related. They could be for...
- Yeah.
- Different services or departments. You are really being inclusive there because you can now bring in OKRs for service or support or for sales that don't necessarily tie into the product.
- Yeah.
- But they're absolutely key at delivering your company OKRs. So I love that wholistic approach you've taken to that implementation. Superb. So let's go into a little bit more then. So we've talked about the purpose of a roadmap. Who's the audience of a roadmap from your perspective?
- I mean, there are many audiences and that's why I also think it's important to kind of a branch of different roadmaps for each of the audiences. In our case, we have, like, two audiences. We have, like, the internal company that needs to know, okay, what's our roadmap? And then we have a public roadmap that we also share on our website and that we link to from within our product to kind of communicate with our audience and engage them around our plans. And also to collect feedback on these roadmap topics.
- Right.
- So we structure our roadmap in the now/next/later format, which we really like. The later is called later slash problems to be looked at. Yeah, and we get, like, a lot of feedback from our customers. I think this is the main reason why we do it, to get feedback and kind of cobuild our product with our audience.
- Absolutely. I mean, you're building it for them. You want them to get the maximum use of it. And it's interesting that you talked about kind of the later being more of the problem space. And that really resonates with me. You know, one of the things that led me to be passionate about roadmaps is that I created them really in, not in a very good way. In a way that kind of just tripped me up and caused problems 'cause it was more of a 12 month delivery plan. So the fact that you're trying to educate the audience and show them that, look, these are the things we're not sure about the solution yet, but this is the problem we want to solve for you. And the fact that you've got a public facing roadmap within their focus, I think, is really commendable. So, you know, you're leading by example.
- Yes. But we also have to because who else should do it if not us?
- So Malte, you've got a couple of different roadmaps. You've got an internal roadmap and an external roadmap, not necessarily from an airfocus perspective, but from your mind, who really should maintain the roadmap? Is there a role specifically for that?
- Yeah, it depends again on what type of roadmap we're talking about, right? Very high level, strategic company roadmaps that can also, like, branch out or have these, like, child roadmaps. But yeah, whoever defines what's been put on the roadmap and what advances in the roadmap like the owner of the roadmap, yeah, should be the person managing it and also deciding who sees it and how people engage with it. Of course, with, like, product marketing, in our case, like, when it's more customer facing, I think product marketing is the right person or department to help with that, everything depends. I'm really sorry if I have to say this like a gazillion times today, I can only speak for myself. Like, here at airfocus, like, it's not that I, as the CPO, like, dictate our roadmap. It's very, like, community driven or discussion driven, right? Like, we have to discussion and then there's usually also, not so much debate because it's quite obvious what the logical, rational next thing to do is because you look at the data, you look at the insights, you look at the market, and then it's not so much opinion anymore.
- 100%. I totally agree. One of our friends of the channel, Itamar Gilad released his...
- Oh, yes.
- Evidence guided...
- I met him.
- And that really makes a lot of sense to me. It's kind of like looking at the different things or evidence led, sorry. And it's looking at all of the different things and making an informed decision on those, not just being data led or product led, you know? In many ways, we should be customer focused and obsessed about them and we're just solving their problems. So love that response there. And you know what, it wouldn't be a product management related channel if we didn't say it depends because it absolutely does. Everything is so nuanced. So you've mentioned, and I really like the fact that we've got OKRs now within airfocus. So what's the relationship do you feel between a roadmap and maybe the vision, strategy, objectives, OKRs? They do need to be distinct, is that right, in your view?
- Interconnected. And I also think it really helps to force yourself to maintain these documents on a regular base. Obviously, you don't wanna, like, spend too much time on it and don't get to do the actual work. We always recommend formalise these processes. Have a place where the roadmap and the vision and the strategy document sits. And then when people ask you, "Hey, what what's the strategy?" Here's the document. Book mark it. Yeah, and just be open about feedback on these topics. So that's also how I've always treated company building. I don't know. I don't know anything, right? And I have opinions and ideas and let's put them out there and involve the people and invite them to discuss these things. And the more you do that, the more it gets clear what to do. What I want to say around these these topics is if you're new to doing them, if you're new to, like, writing down a vision statement or a strategy document or OKRs or even a roadmap, try to find an early MVP of each of these documents. Because if you always want to get to the 100% solution and you read all the books and you always wanna get it perfect, you will not get anywhere. Time box a thing, put up a meeting where you say, by the end of this meeting, we make a decision on the MVP that we're gonna roll with for the next quarter. And in our case, with regards to product OKRs, this meant that we literally just started with objectives and we left out the key results for the first quarter. Yeah?
- Right.
- Just to get something working that didn't keep us busy because you can discuss about key results forever, right? Who knows if...
- Yes.
- When you launch a new product, who knows if the number of users that you want to have on your newly launched feature is 10 or 100? Nobody knows. And it's not worth discussing about it all the time. Sometimes it's as simple as, yeah, let's just launch it and do all our best, we all do our best and then we're gonna take it from there.
- Superb. Yeah, that really resonates with me. You know, I've been reading some articles around, you know, I'm a fan of roadmaps, but actually more than that, I'm more of a fan of roadmapping and the process that you need to go through. But absolutely to your point, you know, do we want to spend 50% of our time planning and 50% executing? We need to time box this so we don't get into paralysis. And a roadmap is for life, not just for this quarter. It's kind of, like, let's not just do it quarterly.
- Yeah.
- Let's do it as just, let's time box it a little bit, go through the motions, but then actually just go and learn from what we're doing. Malte, that's an absolute value bomb there for our audience. So thank you for sharing that insight with us 'cause I think a lot of people get very caught up in am I doing these things right? Go and iterate on them. Go and product manage your product management processes and take the bits that work for you and just learn and be curious. I think that's really good advice. Thank you. So let's talk about, we'll go into a little bit more of roadmapping as well. But what are some of the key elements of a roadmap? You've mentioned OKRs, you mentioned the now, the next, and kind of the later with some problems in it. Is that what would look like a good roadmap for you?
- Yeah, I would say on the highest level, we like to recommend and also follow this practise our own. Like, you have the pro-OKRs. So we're talking about pro-roadmap right now. So the highest level.
- Right.
- I like to have the pro-OKRs that you maybe use as, like, swim lanes or filters that you show on your roadmap items. I think the vision is a bit too generic. I mean, you can put it on top. It's not taking so much space. But yeah, and then I really like the now/next/later format. Put these things into the buckets and then very short, precise descriptions around, like, what are the problems, the whole product management spiel, right, like, hypothesis. How do you wanna measure things? What are the related, and this probably the most important part if you do product roadmapping right, you have, like, roadmapping on this initiative level, very high level now/next/later, not so much actual solutions or features maybe...
- Right.
- When stuff is in the now, they more morph off into becoming solutions. But the most important part is that they link down to your opportunities or your epics. So it's something that sits one level higher than where you spend most of your days on, like, the epic or opportunity level. And you wanna link these opportunities or epics to these high level opportunities so that you can also track progress...
- Right.
- And see where you're going. But yeah, we are not talking about opportunities or epics right now. But yeah, that's pretty much it.
- Yeah.
- I like to keep it very simple. Get an understanding about, like, what this is about, what are the kind of connected opportunities, and then if necessary, some indication around when you think to ship this. But usually, we only put that information on these initiatives when stuff is actually in the now. Like, what do I know...
- Yes. Yes.
- What happens in the next?
- Totally. Yeah, it's about setting direction, but having confidence and you know, I think you're quite right. Too many times, the roadmaps gets conflated and we create a very long-term delivery plan. I love the fact that you're talking about defining OKRs at the top level, but then sometimes the key results for future OKR buckets, we don't know. And we're not gonna worry about that just yet. I'm very much seeing this cascade in terms of your mind of how this works. And then as we come down into the now, that's really where we are looking at delivery, not discovery and experimentation. So only then in the now are we going to talk about delivery and maybe some specific dates of high integrity commitments. But other than that, nothing and nothing else. Your process and how roadmapping works in your mind really resonates with me and hopefully with our audience 'cause I think that from experience that's the right way for us to do this. Here's a good question for you, Malte. What tools do you prefer to use for managing and visualising a roadmap?
- So airfocus has literally started as a prioritisation and roadmapping tool. But as I said earlier, we've now become really an end-to-end product management platform going all the way from, like, your customer feedback and the insights to OKRs, roadmapping prioritisation, product portfolio management, and then handing everything over in a very integrated way into Jira or Azure DevOps...
- Right.
- Wherever you get stuff done. Yeah, but roadmapping is the core use case in our focus. And we've spent, like, a lot of time around roadmapping functionality. Most importantly as everything in airfocus, there is not this one way of doing it. And that's why we are quite flexible and we allow for, like, as we call it dynamic roadmapping. So you can create, ideally, like, you use airfocus as a single source of record for all your product work, including your high level roadmap initiatives. And then how you visualise them and how you share them with different audiences. You can all configure based on the same single source of truth, right? You have one roadmap item that is I want to improve our signup process in order to increase the conversion rate. Something like that, yeah?
- Yep.
- And that thing exists once. Not five times in different spreadsheets and 15 different PowerPoint presentations and then, like, some version in Jira. But you have it once and that then is maybe visualised in different ways. Maybe some people really like to put it on a timeline and then we are not the people to say like, "Timeline roadmaps are bad."
- Right.
- If you wanna do that and you have, like, a good reason to do that, like, do it, it's not what we recommend, but it's sometimes maybe a useful thing to do because you should also keep in mind it's not always that simple as, like, building a SaaS company, like I do, right? Like, for me, it's simple.
- Right.
- We ship software, we ship every day. It is easy, yeah? But if you, I don't know, build a car and the car is, like, 80% software these days, you have deadlines, you have manufacturing that's very dependent on what you're doing here and you better have a plan. And I think it is a bit arrogant of some product people to say like, "Oh, timelines are bad." Because sometimes it's just the reality of stuff. And our customers, they're not all software companies. They are very often, like, traditional companies that are around for 100 years and that are now becoming tech companies and they need to kind of bridge this new software world with the old world of manufacturing, or whatever, or even services. There are very good reasons sometimes to put stuff on a timeline.
- Absolutely, yeah.
- And we give them the tools. But I also think, like, if you're not there yet, if you don't have a single source of record in a tool like airfocus around all your product work, the tool for the very specific task of roadmapping doesn't matter so much. You can also put it on a slide or Trello board or whatever. I wouldn't recommend that. I would recommend you use airfocus, but it's important that it's accessible to people. That it's not outdated. It's sort of real time. But there are other tools where you can do it. I hope my marketing department doesn't hear this where I'm, like, recommending to put roadmaps on a Trello board. Like, what's this guy doing?
- Well, in some cases, it's inevitable 'cause I suspect within airfocus, when you've got a customer facing roadmap as you do on your website, that might be the data is managed in airfocus, but it might not be airfocus surfacing it. It might be that sometimes that you have a presentation layer that comes out of the tool sometimes. I mean, even though my background's in Aha, Malte, my favourite roadmapping tool tends to be PowerPoint because, or Miro or Mural. Because it allows you to take the data that you need and surface it in a way that resonates with your customer. But I think what's important is that there is a management system behind that, which absolutely, airfocus can be part of. You also mentioned some really good points in there as well, I think, are gonna be meaningful to our audience. So thank you for sharing that with us. That's great.
- Yeah, I think that the time of product managers and product teams is super, super important, yeah? And to manage the time and to also work efficiently. Whenever I hear someone saying, "I spend, like, five hours per month putting roadmaps together in PowerPoint", I just think sure, I'm sure it gets the job done, but it's, like, five wasted hours. Ideally, it's a button, it's a click of a button and you put it to another front end...
- Yep.
- That your audience wants to see. But like, don't do that. Don't do that to yourself.
- Absolutely. Yeah, oh, that's a great, I think that's a quote. I think we're there. Don't do it to yourself. It's not needed. Malte, I think that answers one of my questions here, which I think is one of the biggest mistakes people do in roadmapping. It sounds like just that. You know, it's like, just do what is necessary. Don't overindex on creating roadmaps where it's not really necessary. What are some of the anti-patterns or bad practises that you regularly encounter? So I suspect you are working with, you know, speaking to customers on a regular basis. What are some of the antipatterns or bad practises you see them do?
- Aside from the technical aspects of not setting the process up for transparency and time efficiency and all that, I think it comes down to all the stuff that the product management gurus talk about all the time, right? How to make the right product decisions, how to empower yourself and your teams to have the data at hand to make the right decisions. And then, like, usually the really difficult conversations around these expectations from sales and go to market teams around, "Yeah, I need this for my customer. Otherwise, how should I reach our, like, sales goals?" And it's just, like, the hard conversation that a proud leader has to make. And I think this is not where you find, like, these clear antipatterns, but it's just, like, hard. Yeah?
- Yeah.
- But I think if you have a good process where you kind of follow, like, these three rules, so we call it modern product management. It's number one, you wanna have a product strategy kind of concludes in good OKRs and a good roadmap. We discussed all of that. So you wanna have a strategy, you wanna be customer centric, and that requires that you centralise feedback, that you have the feedback, that you make it easy for people to give you feedback. And then you then also make the feedback actionable by creating...
- Right.
- The insights out of the feedback and kind of linking the feedback to the epics, to the opportunities, to the roadmap items. So you have that clear chain from the high level OKRs down to the actual user story. And when you have all of that. The third point is you wanna have, like, empowered product teams that can move fast and all of these three things kind of need to come together. And if you establish a process in your product organisation that does all of that, then usually you have all the information at hand for the product teams to make these tough decisions. So you just have to constantly find the balance between, okay, this brings in revenue, but it's not so much in line with our, like, midterm, long term strategy, but it's maybe something that we can do really quickly because we have the resources right now in this little empower team that I'm working in. So...
- Right.
- You look at these three areas or you look at the problem from the perspective of these three areas, strategy, customer centricity, and a team that can move fast and solve problems autonomously. Then you have everything to have these conversations, I would say.
- Incredible guidance, Malte. Thank you. Yeah, so the product strategy, customer centricity, actionable feedback. I think there'd be a lot of very happy product managers if they were enabled to do some of those things. I know I've been in roles where I haven't, but having worked with teams and been in the space for a long time, as have you, you know, those sort of things that you listed out there makes me really happy. Which is, you know, we understand where we're going, we care about the customer and we're able to act quickly on what we learn. I think that's phenomenal advice. Thank you so much for sharing that with us. So as we start to approach the end of our session, so you mentioned a couple of the kind of the experts out there, the people that we can learn from. Whose advice on roadmapping do you typically listen to? And I think your customers is gonna be a big part of that as well. So I'm gonna seed that response for you, but I think customers is a big one for you guys there, but also are there any other experts that you listen to?
- Yeah, our customers, for sure. One of my favourite customers is Craig from Paperfly. A little shout out. They have a beautiful public roadmap also and a very nice process around product management in general. So I actually learned a lot from them and other customers. But yeah, then I would say I really like the stuff from John Cutler, Marty Cagan, very obvious, evergreen stuff. And very lately, I've really enjoyed reading more, like, on the marketing side, like April Dunford with like "Obviously Awesome" and "The Sales Pitch". I'm reading them right now on my desk every day. They're, like, obviously not so much product management books, but you can get a lot of wisdom more from the business side, which is very important for product management. I really believe in the end-to-end product manager. I'm not a fan of, like, splitting the role up. I'd rather argue that you should take away scope, but then let the product manager do it end to end in another way. And if you think about product management as an end-to-end function or role, then this necessarily means you also have to be good or have an understanding about, like, these strategy positioning questions. And April Dunford, in very elegant words, gives you this process around all these elements of positioning, right? Like, who's your customer? What's the unique capability? What's a benefit? What's the value that that customer gets out of it? And when you do this exercise for your company or your product or your division, however you're structured, you will see that this informs your roadmapping and how you approach the whole topic. And this is, obviously, a lot to ask from product managers because you're now literally asking them to be entrepreneurs. But I think that should be the ambition here.
- I absolutely agree that, I mean, it's again, just nodding violently at what you've shared there, Malte. You know, that I think traditionally, certainly in the last 10 years, there's been too much of a focus on delivery over strategy and solving problems. So I think seeing that change with Brian Chesky, Airbnb, and things like that, I think is absolutely the right thing. And you said it yourself, cut scope, right? Maybe we do less, but we do more of the right things and we own that end to end, which I think is so important. I think that's phenomenal insight. Absolutely.
- I would disagree with how Brian Chesky actually thinks he can do it.
- Me too.
- I'm not so sure it's a scalable framework, but I agree with trying. I agree with the problem and I agree with trying. I disagree with the solution.
- Yeah, I actually mentioned something, I think it might have been Lenny's podcast actually on when he's commenting on that that's not necessarily scalable. It might be okay in the short term to support product management moving back into more of a product strategy, product marketing role. But I agree, you know, it's not sustainable to have the CEO to get involved in the detail of everything. But I like the sentiment.
- Me too, me too.
- Superb, so I'm gonna ask you one of the hardest questions which I can ask. Now, it's not hard in terms of being challenging, it's how would you distil your philosophy of roadmapping into just a couple of sentences? How would you describe the philosophy of roadmapping?
- Good question. I should have come prepared. So I think it's all about problems, problem solving, right? So, like, you wanna visualise the various problems that you have and create, like, a problem hierarchy and based on that, you kind of approach these topics. So what problems are you actually trying to solve here for the overall product portfolio, for the product, for the various products? And then one level below that, like, for the actual capabilities or features that you have, right? You always want to come from the first principle problem thinking. And then yeah, just follow the best practises and kind of start lean, stay lean, stay dynamic. Yeah, in order to kind of fulfil the ultimate goal here, which is to communicate what problems you're planning to solve and why and how and potentially a bit when, yeah, I think think that's pretty much it. It's no rocket science. I think it's all the same.
- Yeah, I think, like you said earlier, you know, just stop doing it sometimes. Don't make it too, don't stop roadmapping. But I think the process of roadmapping is useful and just take it for what it is. Be curious, it goes into your three previous rules, Malte, I think it's about having product strategy, customer centricity, and feedback and actionable. And your roadmap should be facilitating each of those discussions. I think I really bought into what you've shared there. Fantastic. Well, look, thank you so much for spending some time with us today. I'd love to give you now the opportunity just to tell us again a little bit about airfocus and how it helps product teams out there.
- Absolutely. Thank you for providing me with this opportunity. So the big thing, the key insight that we gained over the last years is that every company is a tech company these days. Yeah, and this trend will not stop. The whole world is getting digitised and companies of all shapes and sizes now have product managers and engineers and they will continue to educate people to become product managers. And at some point, you need to have product management tooling because like the Jiras and Notions of the world, they're good for the micro level, but they are not really scalable. And what we learned about the last years is that large organisations have so many products and so many teams and so much complexity that the core problems that they have are not so much like what prioritisation framework do I use in my little team that's important and true, but how to break up these silos, how to create alignment across teams, across the product portfolio and how to make sure there's, like, this shared understanding of the strategy, the goals, the roadmaps and this stuff is complicated, right? And if you really wanna solve it, you need a single source of product truth, a single source of record where you always have one entry in the database, one high level roadmap initiative, and then you wanna link stuff in a logical manner across different hierarchy levels. So you can have these true conversations around, okay, this is the one problem, let's describe it once and for all in a structured way. Let's make sure the insights are linked to that one thing. Let's make sure that this one thing is maybe shared in five different ways, but it's still the same thing. And this will save you so much time. And if you now think a bit into the future, like any other functional role, AI is tremendously gonna change how we are all gonna work. And in five years, we will look back and laugh about what type of stuff we were doing manually, right? Like, even a year ago...
- Yeah.
- I was doing stuff manually that I'm now laughing about. Every day, I use ChatGPT for, like, 30 minutes and yeah, and if you, like, fast forward five years, you will have a product management system that you can talk to like it's the smartest person on earth, right? It will access the single source of record, it will have all the data. You can ask questions and you will spend way less time doing all this manual stuff. But instead you will kind of orchestral innovation by going in there, using these, like, dedicated product management functionality. And you're gonna follow or guide the suggestions made by the AI based on all the product data that's in one place. And that's super exciting and what we're working on here every day. And yeah, if you're interested and would like to learn more, happy to connect with you on LinkedIn or have a product consultant reach out for a day. We always love that.
- Fantastic. Yeah, and in fact, that leads me to the last question, which is a lot of what you've said today, Malte, has resonated with me. I know it's gonna resonate with our audience. How can people find you? If you are hiring, what's the best route for them to be able to contact you as well? What does that look like? How can people get in contact with you or put some links down below as well, but where's the best places for you?
- Yeah, amazing. So I'm quite active on LinkedIn, so just sent me a connection request and then follow airfocus. We put out a lot of content around modern product management and we also have a careers page, airfocus.com/careers. And kind of one content recommendation that I would give is our latest ebook around OKRs for product teams. It's, I would say, one of our best pieces ever. It has a lot of actionable examples also, which I personally always like. I'm not, like, a big reading guy. I like examples and it has nice examples of how company utilise OKRs and how they approach certain problems around the handling and the management of OKRs.
- Malte, it is been absolutely incredible speaking to you today. It's like learning from one of the experts that's been there and seen it.
- No.
- You've done so too far.
- Not an expert.
- So thank you so much. But it's a lot of the transparency. You know, you are learning in the open. You know, we wouldn't be so bold as an entrepreneur or a CPO or founder to say that we have all the answers. We're just curious. We're good at understanding the problems and then bringing solutions and that's what it's all about. So I know that's what you stand for. So thank you so much for your time. A reminder to our audience, if you've loved what we've talked about today, please do give us a like, and a subscribe. Share it out with the others. If you aren't listening on the podcast, give us a follow there as well. It really helps for other people to find the platform, to listen to these discussions, and to learn from great people like Malte. Malte, thank you so much. I look forward to seeing you in LinkedIn and following you further.
- Amazing.
- Where can I buy your shirt, Justin?
- Well, we need to make some of these available. So this is the...
- Yeah.
- A roadmap is for life, not just for this quarter. And then we've got talking roadmaps on the background. So maybe we need to get a line of merchandise sorted for you as well.
- Congrats on everything, Justin. Thanks for the advice.
