What’s the problem with product-mode? | Thomas Hartmann

In this Talking Roadmaps bonus episode, Justin Woods speaks with Thomas Hartmann about why many B2B organisations struggle to move from project mode to true product mode. They explore how roadmaps expose deeper organisational behaviour, the risks of customer-driven feature delivery, the seven core challenges behind project thinking, and why scalability—not frameworks—is the real driver of product transformation.

Thomas is a product management leader based in Munich, Germany. He is the Founder and CEO of Product Masterclass, an 8-week coaching program that helps product managers and product leaders grow their skills and impact.

Thomas is also the co-author of From Project to Product Mode, a practical guide for transforming B2B software companies into scalable product organizations.

With a background in digital product development and experience coaching teams from startups to enterprises, including Siemens, Danfoss, Zooplus, and alike. Thomas brings a real-world approach to topics like customer development, JTBD, and product strategy.

He has mentored founders through Google Launchpad, Xpreneurs, and the Founder Institute, and holds an MBA from Golden Gate University.

Through his work, Thomas helps organizations shift from reactive delivery to outcome-driven collaboration across product, sales, and engineering.

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’s the problem with product-mode? | Thomas Hartmann

Thomas Hartmann and Justin Woods

In the next episode we have Victoria Sheer, Global Product Value Management Lead @ ALDI. So watch out for episode 20!

• Transcript

  - And if you think about switching from project to product mode, the question always becomes, why do we want that? Why do you want to be a product company, right? And I'll think in the book, we don't argue that product companies are always better than project companies. Both can work. It's a strategic decision. The reason we find that most companies want to be a product company is scalability and profitability.

  - Welcome, everybody to this very special episode of "Talking Roadmaps," where unlike season one where we talked about roadmapping and season two where we're currently talking about product operations. Really excited to get in contact with our special guest today who's gonna talk more about something that's very close to my heart, project to product. A very fundamental thought process that companies need to go through. And in today's episode, we're gonna unpack that, talk about his book, talk about some of the speaking work that he's been doing, and what he's been doing to help companies to think about that mindset. So without further ado, Thomas, welcome to the show. It's great to have you here. Please introduce yourself.

  - Well, yeah, thank you very much for having me, Justin. It's a pleasure to be here. Very grateful for the invitation. I had a talk, a conversation with Phil before on your podcast, right? So I know how you think about roadmaps. And happy to talk about what we learned on the way how yeah, project and product mindset influenced the roadmap decisions.

  - If you're enjoying the channel, subscribe, hit the bell icon and give us a like. Amazing. Yeah, absolutely. So let's talk a little bit about the book first, just to set the context 'cause I think that's gonna be the real title even of this episode is from Project to Product. Tell us what inspired you to write the book and a little bit about what the book is about.

  - So we run the product masterclass since a couple of years, four years, five years and it's an education programme for product managers. And then we had one company approach us and said like, okay, you know, we need a little bit help with product management. And that company was not super huge. It was like 120 people, something like that but, you know, only like three, four, maybe five years old so quite successful, right? B2B space, B2B software and we went in and we had the chance to talk to everybody, right? So we decided to, you know, talk to everybody in the C level, right? And, you know, we just, you know, made one hour interviews with them, okay, what's bothering you? Where do you think the company is heading? What needs to be changed? And so on and so forth, right? And we became like, we got a good picture of the whole company, right? And we just compared their, you know, organisation with what we knew about good product companies, right? And there was, you know, clear differences in the operation mode, right? And we then ran a workshop and basically, you know, like the core of the book, like the seven challenges which you find today in this book was actually already back then in this workshop. And what we found are the seven key differences in the operation mode, in product mode versus project mode. And after the project, we always reference back, you know, having new customers, we're always, like, it's the same situation then with, you know, like the other client. And, you know, always referencing back to that project, we started, you know, to write down ourselves and that's how the book actually emerged. So it's pure, you know, out of real world.

  - Yeah, absolutely, and spotting those patterns and, you know, capturing what you've learned into some form of framework, and then being able to say, and then working with different clients and recognising those back in your framework and patterns is really validating. And it's really interesting, as a consultant myself that gets to come into work with these companies, often we have a better visibility on how they work than even they do. And it's a privileged position, because it allowed you to write the book and the framework in the way that you have so that then you can use that as a blueprint to help companies get out of project mode.

  - Totally true. Because, you know, like we had the luxury to talk to everybody on eyesight, right? And without judging, just asking, okay, what do you think needs to be changed, right? So we got so many perspectives and we mixed it with our view, right? And we have, like the product masterclass. We always have like four coaches from four different perspectives, right? Product, design, business, engineering. So we brought in these four perspectives and then, you know, a picture emerged, which, you know, validated over time. Because usually if you work in such an organisation, you never have the time to do that work for yourself, right, to reflect and, you know, think through, yeah? And what we've also figured out that's really interesting, many people confuse the outcome with the root cause, yeah? So it's always hard to say, okay, we have an a problem in engineering, yeah? Often or what we found, it's a systemic, you know, problem. But, you know, people always try to cure it locally and that's not working, yeah.

  - Yeah, absolutely. The amount of times I see companies say that we have a capacity problem, when really they have a prioritisation problem, when really they have a strategy problem. So I wanna steer the conversation a little bit into roadmapping, and then I want to start to unpick some of the fascinating concepts in your book, if that's okay. So why don't we start with, maybe what is the role of roadmapping from project to product mode? So I'm curious how you might see differences in roadmapping with a company that is it more in a project mode versus a product mode? what have you seen?

  - Well, first of all, like what you said is totally true, right? So we see the roadmap more as a reflection of the organisation. So it's not the problem. It's more the reflection of everything which comes first, right? And the subtitle of our book is "A Game Plan to Unlock Scalability for B2B Software Products." I think it's different in a B2B world than in the B2C world. So have that in mind in our conversation, right? So we basically focus on B2B. And what's different in B2B is that you often have very strong customer which push features into your roadmap. And that's, you know, like for everybody listening, just, you know, take your roadmap and track back where the requests actually come from, yeah, and you will see two patterns, right? In project mode, you will have the source being the customer request for something. And then sales, you know, like they sometimes promise it to get a bigger contract, the special features or you know, like it's sales, you know, communicates or puts it into product. And product is basically acting not as product management, but more as a scheduler, right? You know, like, and then you have like the situation that you have way too much feature requests for way too little capacity, right? And that's what we actually, you know, like when the request comes from the customer to sales to product and gets unfiltered into engineering, that's what I would actually, or what we call project mode. No matter what your official title is, right? We just look on, okay, how are you, how is the organisation behaving, right? Whereas if you work in a product company, the situation will be more like that, you know, like your organisation, you know, looks on the market, looks on segments, and thinks about, okay, how can we, you know, how can we create value? Yeah, what will be a good fit for many customers compared to one customer in the project mode, right? So like, yeah. And then, you know, like the communication goes actually 180 degrees the other direction because product is, or product and engineering and design, like the whole team is convinced, okay, if we do this feature or if we do like this module, or if we develop this and that, right, we will win the market, right? And then you communicate it to marketing and sales and you enable them to sell it on a market, right? You give them documentation, you give them information and then they go out and, you know, communicate it to the market, right? So really if you look on the communication flow, where the features in your roadmap originate from, it tells you a lot about, okay, what organisation you are working in.

  - Massively. Yeah, absolutely. And so instead of going after solutions a specific customer wants us to build, we move it to thinking more about what is the opportunity that a larger market might want to. In many ways it's the same and also in many ways it's so fundamentally different. And I think that's why it can be very difficult for companies to think about this because what they're doing is they're saying, well, value for us is to get a sale from a large customer whereas actually value is really solving a problem for a much larger audience and it is just a completely different way of thinking about it. And it is mindset, isn't it? It's very much mindset.

  - Yeah, often. Mindset is the biggest part of it, yeah, if you think about it. When I had the conversation with Phil about, you know, roadmapping, about product principles and you know, like how it's linked to strategy and how it's a shortcut and stuff like that, right? And I think you see all of that, but only in good product companies. You don't see that in project driven companies, yeah. So if the company has a project mindset, you know, you don't have these shortcuts because, you know, like what is also true if you are a project company, right, if you think about it, you don't need to have a strategy. You just go to your customer, to your client and say, okay, what do you want to build or what do you want to have, right? And you go internally and calculate, okay, how much does it actually cost, right? And you say like, okay, it costs me a hundred and then I make a 25% margin on top and then you propose it to customer. If he says yes, you built it, right? There is very little strategy needed, yeah? If you are a product company and you have like a million opportunities out there, right? Okay, I can help this segment, I can help that segment, I can, you know, solve this problem. You know, like in product management, there is like a lot of stuff coming to you, right? A lot of ideas what we can do, right? And that's a totally different situation.

  - Yeah, totally. I'm curious, as you spent some time with customers and your clients are kind of in that project mindset, what signs tell you that a roadmap is enabling value delivery rather than feature delivery? Have you seen that on their roadmaps? Or what other telltale signs have you seen that says that they are feature delivery rather than value delivery?

  - Well, again, like the one thing is the source, where it comes from, yeah? And the second one is, and that's maybe a good thing to dive into the seven key differentiations, right? Because for every feature on the roadmap, you can ask yourself, okay, did we do a product discovery? For every feature which is on the roadmap, you can ask yourself, okay, what's the pricing like? Do we price it based on material plus, you know, 25% margin? Or do we price it based on real value for the customer, yeah? Do we have a segment which is really raving for this feature or is it just a single customer, right? And these are all, you know, like if you just call out the seven things, right, which I have here in our book, right? Segmentation, pricing. Yeah, it's very early in the funnel. Then we have like product discovery, product organisation and prioritisation. Yeah, that's like the product management practises. And then we have push versus pull in the engineering and we have the configuration, right? And these are the seven key components where project organisations are very different from product organisations. So if you want to, like, if you have a roadmap, you can just, you know, go through and think, okay, like did we do a validation there? Or is it just, you know, funnelled in from the client towards engineering, yeah? Did we do segmentation? Like, is there really a segment or is it just a single customer who's requesting it, yeah? And pricing is a really big trap in our understanding because project mode companies, they just look at, okay, how much should it be to be built, right? Put a margin on top. But they always underprice their... Well, their estimation is always too low. And we found, you know, like features development took 50 times what they estimated because you don't see the complexity at the very beginning, right? Like a button, right? How complex can that button be, right? And then it goes into development or you know, like you into product management and they ask, okay, but what if with this client, right? And then the complexity unfolds, right? And, you know, three years down the road, you still have that bloody button and you know, like it's interfering any development with other customers, right? So what we see is, you know, project mindset companies significantly underestimate the maintenance and what the effort in the long run.

  - Incredible. Yeah, I can completely see that. It always seems to be very short term focus. This customer wants this, let's build it, let's make a bit of money on top, let's move on to the next thing. And that is, like you said, that's very related to that project mode. You mentioned those seven challenges. I would love to hear a little bit more about each one of those, just maybe a sentence or two on each one but if you could share that, that would be fantastic.

  - Sure. We start at the very beginning with the funnel, right? With segmentation, right? Project companies don't have a big demand for segmentation. You just have a client ask something, you think, okay, can I build that or not, right? And then you build it, yeah. Segmentation is needed if you want to run a product, right? Because you need to decide who do you actually want to deliver for. You might call that strategy. It's part of a strategy, right? Pricing is huge difference, right? Because you know, like in project mindset, you give out special features, you know, special requests for free to win a bigger contract. You underprice it just like we talked before, right? Product discovery, right? If you are in a project mindset company, right, your stakeholder will basically ask for a feature and expect a finishing date in return, right? You know, like that's a project. And if you have such a environment, let's say, right, then it doesn't make sense to do a product discovery. Because if I just tell you, okay, I need this feature, or I need this button, yeah, tell me when it's finished, you know, going a special circle with more product discovery feels unnatural, feels lengthening the project.

  - Yeah, totally. I see this with stakeholders a lot that they see discovery as a nice-to-have as some form of validation rather than what discovery should truly be about. It's kind of like a necessary slow down of just delivering my feature.

  - Exactly, and the sources that they think that they know a hundred percent for sure what they need, but we know in product management, if we just built what people ask us for, we're not successful, right? So then the next one is product organisation, right? And that's basically, you know, like you need to facilitate, you know, product discovery. Like you need to have an organisation which is able, you know, to judge what will be successful in the market, right? Therefore you need product discovery. And it will also, you know, like be the basis for being able to say, okay, what is really important to be built, right? Prioritisation, right? Because if you do segmentation and say, okay, you have a spreadsheet and say, okay, we just want to build for these people, if you have good pricing in place and say, okay, you know, some features, they're just too expensive and people will not order them. You have product discovery in place, yeah, and you filter out features, you will still end up with a wishlist of your organisation, which is bigger than your capacity, yeah, and that's prioritisation, like what's really important, right? And that's the next, that's fifth, yeah. And then we have like the engineering discipline with push versus pull. And push versus pull is, okay, do we just, you know, push the features into the engineering department and you know, like more or less like throttle it in or stuff it into their, you know, throw it, do it and we push, you know, and try to press out as much as we can, right? Or is it more like, okay, we think this is a good thing, right, and we are ready to develop it, right? And let's start small and test it and iterate on good outcomes. That's the other operation mode, right? And the seventh is configuration because if you are clear on which customer segment you serve and you are sure that there is enough customers, you can invest more engineering, yeah, and make it configurable for the clients. And that takes off load, yeah, takes load off your engineering department because you outsource the engineering to your clients, right? Or to some plugin developers or to somebody else, right? But it only works if you are clear on which segments to be served and are there enough customers. And that's, you know, the answer with product discovery. So it's all interconnected. All seven are interconnected, yeah? It's not only the one thing you need to change.

  - Interesting. Yeah, that makes sense. And have you seen the case where clients have come to you thinking that they've got one problem, whereas actually you've looked at all of the seven and gone actually your problems over here? What's that experience been like for you?

  - It's always like that. Yeah. And I can also, you know, tell you like where it usually starts, because usually engineering is overwhelmed with stuff, right? That's always. Like, you never had a client, you know, which said, okay, we have too much engineering, we don't have enough ideas, right? It's always, you have more ideas than capacity to build it and that's basically called product management. Because you know, like in project management, in a good project company, right, you have enough capacity to build what you ordered. Because, you know, like you get a client. And then you check, okay, can we build it? Yeah. It just gets complex if you have a product company or if you want to build a product, but it's hidden projects, yeah. And then B2B, that is actually often you know, like what happens, right? So you build first for one client a thing, and then you think, oh wow, this is like superb, you know, like, nice, what we built here. And then the second question is, your second thought is, okay, but can I sell that to another person, right? And then you go to the second client and you find a client and this client says like, wow, nice. You know, but I need it a little bit different, right? Here we need something different and there we need something but basically it's great, right? So you end up, you know, like having 80% same, right? And 20% custom. And at first it feels incredibly good because you think like, okay, second client, you have third client, fourth client. But if you have like, okay, you know, 80% same, but 20% always different, right? After 10 clients, you know, you have more custom then standard and that is the problem. A product company behaves differently. They have standard.

  - Yeah, it does. But one of the things I was thinking is that, is it quite common that companies start initially by spotting a problem, but they approach it in a project mindset initially because they snag their first customer? So are you seeing that companies tend to start as project and evolve into product? Or do you see some company... I suppose it depends on the owners and the founders and their mindsets of how they bring to this. What have you seen?

  - Yes, I think it depends on the mindset of the founders, but even more on if they're B2B or B2C. Because in B2B, the base case is that you have a strong client, a high value client, which you're built for, right? And in B2C, you need to, you know, decide early on what is my segment and who do I help, right? So that's why I think, you know, like these two worlds are different, yeah? And that's why we really said like here Project to Product Mode because we see it in B2B software products. You know, like that's most often the case, yeah. What we observed afterwards is in big corporates, yeah, in the B2C world, the internal stakeholder behave like the clients in the B2B world because they are requesting solutions which they think, yeah, are important or are the hundred percent, you know, like the solution.

  - Yeah, they've got so much conviction that this, I am the leader, this is what, I know the market, I know what's needed. I want us to build this 'cause I can see the solution.

  - We always use like the customer's king, right? The customer's king, everybody knows that, right? So you build what the customer needs, yeah? Yeah, exactly. But that's a trap. That's a trap because you know, like in B2B, if you have single customers, right, and you build exactly what they want, you end up in project mode, not in product mode, right? And the same is true if you are in a B2C company and you have like really, you know, like strong characters as a stakeholder and they come with solutions rather than with problems, right? Then you have basically the same problem. And if you read the book, right, and if you are in a B2C company and you replace all customer with stakeholder, it actually reads quite well.

  - Very cool. And I love what you're saying so passionately there but I don't know if you've seen the meme online, but it was like somebody created a pizza that everyone wanted and the pizza had a roast chicken on it and it had chocolate on it, and it just became a mess. And I love that because I think there is this need to understand the problem at a higher level and to truly build and to look at it more strategically and holistically. If you always build what these different clients want, you are going to end up having a disjointed product that eventually nobody wants. And so I really feel... Early on in my career, I always used to think that it was more requests and ideas that came in and that strategy was something that kind of formed those in a bit of a way. Whereas now in my late years, I'm very much more of the fact that a company needs to have a strategy and then think about what ideas are coming in from clients that align to that strategy and build it. Don't become a request or a request list factory. Start to become, you know, understand what your strategy is and then by all means temper that with feedback from the client. But you've absolutely got to start with where you are going as a company first of all.

  - My problem with strategy is that it's always a little bit fussy, right? And if you think about, you know, like in the B2B space with strong and high value client, most companies start quite opportunistic, which is actually good, right? It's better to have one high value client then none, right? And it's better to have two. But, you know, switching from a project mindset to a product mindset is really what many companies really, really struggle. And that's super hard because it's basically contradicting each other, right? Whereas beforehand you said like, hey, there's a high value client and we just need to build XYZ on top of that, right? Let's get it. Yeah. Later on, you have to refuse these special requests, right? So it's a different mindset and switching these mindsets from the one to the other, you need to understand the holistic system. Yeah, it's not just that you understand like just engineering locally or how sales... It's the holistic thing, right? And there is another metaphor, like the egg organisation, right, which we came up actually, and that originated from a call with a client, right? And we just mapped out their whole organisation and you know, like I talked to them, okay, where do the requests come from and how do they request it basically, right? And basically, you know, like it's... I'm not genius. All I would tell is, you know, like just from past behaviour and conversations, right? And he said like, okay, they just give us, you know, like the features and they basically request for a finishing date, right? And when we mapped that out, we just, you know, like put a circle around product and engineering, yeah, and, you know, because it was a mirror or Miro or something like that, it was yellow and then it basically looked like an egg, right? Because you have a yellow core product in engineering, right, and they're thinking how can I iterate, how can I, you know, discover. But if everybody around, you know, just thinks and projects and I know what I want, yeah, here is my feature request, can you give me a finishing date, right? Then it's just, you know, it's two worlds. You almost operate in two worlds. You know, like we call that the egg organisation and that makes it super hard. So you need, if you want to be successful, you need to change that.

  - Totally. Yeah, so it is an egg model because the yellow from your whiteboarding software was kind of around product and engineering who were thinking in a product mindset, but the rest of the organisation was thinking in a project mindset. That totally resonates with me because one of the big challenges that products have or teams might have, even if they're engineering and their product are aligned in a product way of thinking, is often when they want money from finance, finance want to see a roadmap that they are financing. They don't want to finance a problem. They want to finance assets that are going to get built. How have you seen that in your experiences and what advice would you have for companies that are struggling with that?

  - Well, I think you cannot solve the problem locally. You need to have an aligned leadership. And the bigger the company, the harder that gets. But here comes one thing which we saw is, well, what I think is the only thing which works. You need an aligned goal. And if you think about switching from project to product mode, the question always becomes why do we want that? Why do you want to be a product company, right? And I'll think, in the book, we don't argue that product companies are always better than project companies. Both can work. It's a strategic decision. The reason we find that most companies want to be a product company is scalability and profitability. That is the thing which, you know, is tempting where the organisations want to go to. And with this tools or with this knowledge, you know, you can actually open doors of new thinking, yeah? Because if you go into the organisation and in the leadership team, you find alignment and you ask the question, what do we need to be doing to become more scalable? Then you will end up with a product mode company, yeah. You need to limit the segments you're serving. You need to, you know, charge more for the one-offs or leave them out or kick them out. You will need to have a product discovery in some sort, right? You will need to have a product organisation, which knows the market, which is aware of, okay, what's going on? What are the trends? What do we need to build, right? And you need to make your product in some ways configurable because otherwise you just waste too much resources on the wrong stuff, right? So scalability. And now that's super interesting from your perspective because, you know, like you did a lot of roadmaps and you described it very nice, right? It's not a roadmap problem. It's a product problem. It's not a product problem. It's actually a strategy problem. There's that, you know, like scalability, is that the umbrella you see in your work?

  - Yeah, it's a great question. I think I've worked with small startups that have come about because they're in project mode 'cause they spotted a single customer problem through to fortune 500 companies. It's often, like you said, it's not product management or the product mindset is not just the domain of product and engineering. And the bigger the company you get, the more difficult it is to influence. You know, if one of my clients is over a hundred thousand employees now, trying to talk to their finance department to explain to them what product mode is and why it's important to fund problems rather than solutions is way above my sphere of influence. And whilst I can bring the right people in, it's a multi-month, multi-year transformation effort, which starts from, we're going back to the egg, we're just trying to make the yoke bigger, right? And so it becomes very difficult there. But yes, I've seen that. And the difficult bit to answer your question is then, you're quite right, it's about shared goals and things like that but when you get the finance department over here and the product engineering over here trying to find a shared goal that they can really both get passionate about, ends up going so far up the company that often it can be lost in those upper layers. And so I'm not really sure where to go with that sometimes. It's often an education piece, but I don't have the authority to tell the finance team to fund problems. They're still going to want to fund capital solutions.

  - Yeah, true. I mean, the bigger the organisation, the more complex and complicated it gets. That is for sure. But somehow, you know, like you need the buy-in from the top management to do the really big changes, right? And if you know, like if we think about agile, right? This idea is now 25 years old, right? And I think, you know, like after such a long time, it's time to ask yourself, okay, but why isn't any, you know, like all the companies are agile by now because, you know, like it's enough time went by?

  - Right. That they should all be using agile where appropriate.

  - Or you know, like every, every company should be, you know, agile and fast, right? And I think, you know, the egg organisation is the picture which is holding these companies back because, you know, like agile, it started off in engineering, yeah, with extreme programming but it stayed in product management and engineering. It never went to the other departments really.

  - Well, it was seen as a product management or an engineering framework. It was never seen as applicable.

  - Exactly. And you know, like for me, you know, like if you want to switch your company from a project mindset to a product mindset, you need to go out of your bubble. You need to go out of product management to really change it.

  - Yeah, no, you totally do.

  - And that is the biggest challenge to be true. That's like, because we call that level up, right? What you said, like Justin, it's just like, okay, but it's so much above my sphere, right? Maybe you cannot influence the CEO of a 100K company, right? But you can level up, right, like one or two levels, right? And you can educate them. And you know, like everybody who's listening, you know, like there might be, you know, people listening who just started off in product management, right? You can do something as well, right? It's just your sphere of influence is a little bit different. But you always can influence, you know, like one or two levels above you or you know, stakeholders left and right, right? So it's the sphere is different.

  - Yes. Yeah, totally. And I think that's one of the reasons why I'm so interested in what I do because it's way beyond tooling implementations. I'm part of transformation efforts and I really am passionate about the people, the process and the tooling side of it. And no doubt, you know, the tooling is really easy. Once you understand the people and process, configuring a tool doesn't take time. But the getting to the decisions that configure the tool is the difficult bit that actually is the domain that I enjoy working in.

  - How about like from your... Like I make a big differentiation between B2B and B2C. How is that in your perspective and your experience, you know?

  - Yeah, it's a good question. I think the way that the team's roadmap is different and the way that they approach product is different as well. I predominantly work with B2B companies, I would say by and large. I've worked with ones with different levels of maturity. It's difficult for me to pick common patterns between them in that regard. But what I have seen them do is, again, if I look at the roadmap, it tells me very much a lot of what I need to know about their product organisation and then you can start to spot the problems from there. The roadmap is a window into how they think about product management. But also not just how the product and engineering teams think about product management, it's how the entire company approaches and embraces product management. Because even then, you know, different roadmaps will just show here's the features that have been requested internally. So that's where I see it more. I've not really worked with enough clients to be able to say I've spotted strongly these certain patterns, but just product management and project management or product mode and project mode is very much a scale that companies are going on. And some of them don't even want to. They are happy with project mode but I think those are companies that maybe will fizzle out over time because they solve individual client problems, but not something that's actually the overall problem to solve.

  - Yeah, but you know, like this is totally fine to have project companies out there. If you think about, you know, like in the physical world, it's easier to imagine, yeah, but if you think about an architect, right, it's just fine to do projects, right? And in a digital world as well, right, if you look at the Accenture, 700,000 employees, they basically do projects for clients, right? So, you know, it's fair enough to have a project company. Not everybody needs to be a product company. And I think this is important to know, yeah. What are your best hacks to bring customers from project mode to product mode? Like how do you do that if you reflect on that?

  - I think for me, roadmapping is very much about communication and alignment first of all. It's also about, for me, I also differentiate between a strategic roadmap and a delivery plan. So many clients that I work with think that a delivery plan is the roadmap. And actually I like to differentiate them by saying that companies need both. I don't want them to try and make the one roadmap artefact that they have more a delivery plan or more strategic roadmap. I think they need both. And when you do that, you then start to help the company to think about, okay, what is strategic and then when are we going to work on that strategy? And so having those outcomes over time helps companies to think about the problem space, not the solution space. It also helps 'em to think further into the future. So a lot of companies that I work with are very short term. They're bottom up delivery rather than top down strategy and roadmapping. And so I help them to say, okay, that's fine. This is what you're doing in your next iteration, but I want you to be thinking about ideas and problems and hypotheses in the future. You're not gonna have that on your delivery plan, but you might have that in part of your strategic roadmap. The other things that I try and encourage them to do is have multiple views. And so because a roadmap is about communication and alignment, you need to communicate in alignment with different audiences. And I think different audiences want to see different things. And I'm also very comfortable having a discovery roadmap. Here's a roadmap of all the things that we're doing discovery on. Here's a roadmap of all the things that we're doing exploration on. Because it encourages teams and stakeholders in fact, to see that product management isn't a delivery function. We are going back and doing the discovery in things that you said earlier as well. So that's definitely been my view is I try and help companies to think more to the right and higher level rather than short term iterative.

  - Makes total sense. I think, you know, like changing a huge company is really hard, yeah. And like, I've worked together with energy, like before I did the programme masterclass in an entrepreneurship programme, and we tried to change the culture of the company. There was like two pictures which emerged in this work. First of all, if you want to change the culture, you need to define what is culture. And there was one good picture, which I picked up at a conference and it says like, basically the culture is a back mirror on all decisions the company took from day one, right? So it's a huge pile of decisions, right? And if you want to change that huge ball of decisions, right, you need to start doing things differently, right? So you need to come to different decisions, yeah. And if you think about roadmaps, it's just a process of different decisions. It's a process of different... So if you want to have a different roadmap, you need to start think differently on an individual level. And for me, changing people's behaviours is always like associated with, okay, you need to educate them, you need to give them a different reason why they should decide differently. And that is basically what we try to do with the book, to show them the trade offs. And I think the trade offs are often not fully understood, right? No problem to give my new client a custom feature, right? But on the other hand side, you know, they fight for the feature to be implemented because it's clocked, you know, like the engineering. So if you... Yeah, you need to explain what is the trade off. We can make this feature. You know, in software we can build everything. Yeah, virtually everything, right? But what is the trade off for my organisation, right? It will be the trade off that I have down the road three years, a clock backlog and you know, like 60% or 70% of my engineering capacity is tied to maintenance, right? Yeah, and that's another measure, right? If you look in your organisation, how much do you spend on maintenance, yeah? If that is a high percentage, let's say about 50%, yeah, the likelihood is very high that your organisation behaved very much like a project organisation in the past. And, you know, like to untie this and, you know, untie that's hard.

  - Yeah. There's even cultural debt. There's strategic debt, there's all of these, the debt of decisions and the debt of operating models previously that are encumbering companies of today.

  - Yeah, cultural debt. I like that. Yeah, that's the mindset. How you change the mindset and you need to start thinking differently about your organisations and about your organisation and about the future of your organisation. If I say no to that or yes to that, what's the implication for the future?

  - And I think that's where I'm going to go with this current client is one of empathy. So once the product and engineering teams or the yolk in this case understands and empathise with the other areas of the business that are just saying, look, we give you funding based on the things that you want, 'cause if they can empathise with them but then also the finance teams can empathise with the product teams, you might be able to level up a little bit more and just have a better understanding so that it can be less around project funding and more about product funding. So I think you're right. There is lot of discussions that need to be had and a lot of empathy and understanding from both sides, because it might be the case, Thomas, that no one's had that conversation in the last 25 years or a hundred years that the company's been running for.

  - Yeah, and you know, like, we really try to make the book applicable, right? In chapter three, we write like, what do we see as the plausible steps to change your organisation? First step is that you understand the trade-offs and the interconnectedness of the seven challenges, yeah, or you know, like it's not about the challenges, it's about your organisation and how they behave, right? You know, like if I miss discovery, what happens? What's the implication? Because, you know, like in a sophisticated conversation with your stakeholders or people above you in the hierarchy, right, you need to have good solid arguments and you need to be able to communicate what are the trade-offs? So you need to become yourself aware of, okay, how does this thing actually work, right? The second step is that you align with other leaders in the company, yeah, about that picture, right? And then the third thing is that you really put the question into the room, okay, if we want to achieve X, Y, Z, and mostly that is scalability, otherwise, you know, a scalability, profitability, there is little reasons for being and nobody wants to be product mode just to be, you know, in a product mode. It has a special purpose and there, you can align. Then you can can really align and say, okay, what do we need to do in order to achieve that goal? I always hated the term digital trends or transformation. Like, okay, but it doesn't say from where to where, like what's the purpose of the transformation? Where's the end?

  - It sounds like a project. And actually companies that they need digital transformation really should have been, it should be an evolution, right? And so I hate that too. This transformation is kind of like, actually, yes, it is a transformation in some ways, but it's a project and it should be a constant evolution. It should have been up to that point, but if it wasn't, it should be afterwards.

  - Yeah, so what do we actually want to achieve at the end of the day? Like what's the goal of this cultural change or what's the goal of this? I don't know, like transformation, like what's the goal? If you think it in terms of project versus product, then the goal becomes super clear. I want to be more scalable, more profitable. What do I need to do for that? It gives us so much clarity. But if you just transform for the transformation, it's like, I can transform forever, right? So it's like I go from green to red to yellow to whatever.

  - Thomas, you've shared some fantastic concepts there. I'm thrilled that you've written this book. I've had a skim through it, but I can't wait to dig into it in more detail in the coming weeks and months. I'm wondering where you get your inspiration from. Who do you follow? What materials have you found valuable in your career so far?

  - Well, the book comes a lot out of the work with clients, right? You just, you know, struggle through, right? So you work with them, you get better and then at some point you might, you know, hit something. Of course, you know, like I read a lot of books about product management. Of course, you know Marty Cagan and Teresa Torres of these world. I originate actually from lean startup and I have a lot of lean startup background and I love the concept of jobs to be done. I really like all the stuff Bob Moesta is doing. He was last year at our conference and he had a wonderful talk, yeah, which I can send you the link to put it in the show notes. I really like, love his mindset, love his work and jobs to be done. I think, you know, like if you are starting off as a product manager and you want to become better fast, I think jobs to be done is the most important thing to understand in your career because it changes the trajectory where you want the product to go super fast and efficient.

  - I'm gonna ask you a challenging question now, and feel free to answer this in a couple of words or a couple of paragraphs, but I'm curious about your philosophy of project to product mode. How would you distil your philosophy of project to product mode in just a couple of sentences?

  - I think we have a big picture view on product management and a company. And you know, like we started off with writing this book and we often ask ourselves, okay, but you know, like, is there really something unique and something special on one end? And it turned out after a while, there is a lot of content which tells you how you can do product management better. But you know, like we have a different view on product management because we just say like, okay, it's not the org, you know, like it's not product management, which you need to do better. You need to fix the environment you are embedded in. And I think, you know, like this is a new perspective, or at least I haven't heard so much about it and I think this hopefully helps a lot of product leaders think differently about their environment and what they need to do.

  - Yeah, I totally agree because you are going to have people on that line of the yellow and the white where they are coming up against the frictions of either side of that. And I think that's why you'll often see a lot of product leaders come into project mindset companies and get burnt out because they are trying to help both sides to understand. So I've definitely seen that before.

  - There is so much friction, yeah. And really like, when we also speak a little bit about, okay, what's the default mode to switching from project to product? I would describe it as struggle through or burn through, right? So you bring somebody in and product from a product company, right, and then, you know, like there is a lot of arguments, there is a lot of tensions. If you feel the tensions in your organisation, sit down and reflect, you know, like if that is the case that you have like two thinking modes, right, because that gives a lot of friction and tension in your organisation, a lot of arguments about, you know, like different things and most likely one of the key things is the roadmap. Organisation struggles through, right? Somebody gets, you know, fired, somebody changes a little bit, you know, like you get a little bit more input, you hire new people and you know, like, it evolves over time, yeah? I think we have more... You know, like if you think and understand more the organisation, you can be much faster with way less stress and more efficient and, you know, like faster in a scaling mode. And that's at the end of the day, what you want.

  - Yeah, totally agree. Thomas, there's so much that you've said that has resonated with me. The concepts in the book, the things that we've talked about now. I'm sure many of our audience are going to have found that useful as well. How can you help those people in our audience and how can they get in touch with you?

  - Well, it's actually quite easy. You know, like the first thing is really read the book and think of your organisation, like, you know, reflect. Yeah, we also have like a self-assessment in there, which is totally free, which you just can fill out, which gives you a reference, right? And I think this is a very good first step and if you then have question, you can reach out, and we also give guidance how, you know, you can introduce it into your organisation at the end of the book. Like, you know, let other peoples do the self-assessment as well, right? And then, you know, compare your results, discuss the results and stuff like that. It's just like awareness for individuals and for the leadership teams. These are the first steps and I think it's an easy, well, the easiest way is just, you know, go through the book and see if it resonates with you too.

  - Yeah, it makes absolute sense. And we'll put that in the show notes below. We'll put a link out to your book. We'll put a link out to your LinkedIn profile and maybe your website so folks can get in contact 'cause a lot of what you've said, you know, I could have benefited from in my previous years and just gone, yeah, that's where the problems we've had. But more importantly, there's a lot of learnings there that are applicable for my future clients and my future work. So I wanted to say thank you for creating that book and the concepts within it because I think once I've read them, they made absolute sense to me.

  - Thank you, Justin, for having me here and yeah, for having this conversation and being so open. Thanks.

  - Thomas, thank you so much for joining me. And that just leaves me to say to the audience, I hope you've enjoyed today's session looking at project to product mode, especially for B2B companies. If you've liked what we've said, then please give us a like. Drop some comments down below to let us know what you liked and join us on the next episode. Otherwise, all that leaves me to say is Thomas, thank you so much.

  - Bye-bye. Thank you.