214. Daniel Thulfaut, Head of Product at saas.group - Why AI Is Killing Traditional Product Management

Speaker A: You are listening to the Sassiest podcast in the world. Born in the Nordics, democratizing B2B SaaS knowledge everywhere.

Speaker B: Hi, I'm Daniel.

Speaker C: And I'm Thomas. And we are experienced SaaS professionals that are curious about how other successful SaaS companies go to market scale, build winning teams and great products.

Speaker B: Join us on our journey as we speak to SaaS leaders trying to get hold of their secret sauce.

Speaker C: And today's guest is Daniel Tullfout, the head of product at SaaS Group.

Speaker A: If you figure out that you can solve your customer's problem without AI, better than with AI, and for the love of God, please do it without AI.

Speaker B: Hey, sassy listeners, do you want to launch a drag and drop email or page builder inside your platform without building it from scratch? The Be Free SDK gives you the power to embed a powerful customizable AI ready editor in days, not months. It's fast, flexible and built to scale with you. Skip the dev headache, focus on what matters and deliver an experience your users will love. Learn more at Developers Befree IO. That's befree with two E's.

Speaker C: Hello there and welcome back to another episode of the Celsius podcast. The summer is closing by Daniel. How are you feeling? Hot.

Speaker B: I am feeling great. I'm feeling great, awesome in all kinds of ways. But I'm also, I must admit, I'm also looking forward to a little bit of a summer break. So, yeah, uh, on the 20th of June, me, uh, and my family, we are flying to Mallorca, uh, and we're going to one of these, uh, family retreats. We have small children, so it's going to be one week of all inclusive, lots, uh, of fun for the kids, lots of ice cream. We're really looking forward to that. And then after that, in my mind, the real vacation starts. Then we're back, back home and we can relax a little bit and unwind and so on. We're really, really looking forward to that. How about you, Tomas?

Speaker C: So here in Sweden, this is the last, uh, week in school, which is great. And then the week after that we have our last conference of the year. So we are heading to Munich, SAS East Munich on June 18th. And we are looking forward not only meeting the SaaS community down there, but also hopefully meeting the Bavarian summer. Yes, we can spend some great time together after the conference is done. Doing a barbecue outside in the park there. So looking forward to that. What else can we say about the upcoming event, Daniel?

Speaker B: It is our first one in Munich and we are very fortunate Here to have a, uh, really, really nice group of people, very senior group of people to join us. So this one is designed to focus on more intimate conversations. So we are a little bit north of 100 people. Uh, we have CEOs, CPOs, CROs, CMOs, CFOs, and some customer success leaders. And the idea is, yes, there's gonna be some sessions from some really great, uh, leaders that share how they did certain things, you know, where we can learn from their, uh, mistakes as well. But there's also going to be quite some time focused on you guys interacting with each other, sitting around roundtables discussing how did you do this? Or how did you crack this? And so on. So that's going to be lots of fun. And for us, of course, you know, we're here to learn as well. Um, there's so many great companies in Germany alone and I'm really excited to meet many of you. So see you here in a week's time or so.

Speaker C: Absolutely. And this event is for B2B SAS operators only. And if you want to read more about it, you find it at, uh, sassiest munich dot com. And we're also happy to say that we have a German guest today.

Speaker B: Yeah.

Speaker C: And, uh, we go down and talk about the product, uh, management and AI and uh, how that affects both roles and companies moving forward too. Let's go ahead and talk to another Daniel. Today. We are super excited to have no other than Daniel Tulfout here as a guest in the Sassyest podcast. Welcome, Daniel. How are you?

Speaker A: Thanks. Thanks for having me. Um, I'm doing great and looking forward to our conversation.

Speaker B: So are we. So are we. And tell us, like, I know it's been cooking over there in Germany the last few weeks. Like, uh, how are you staying cool this time of the year?

Speaker A: It is, it is, um, very unusually warm. Um, but I'm the lucky one to have a very outsized AC unit in my very little home office. M. So, uh, I'm sitting here chilly in a sweater, uh, while it might be 30 degrees outside, but that is a bit of luxury, uh, I have to admit.

Speaker B: Luxury, hey, but it's a nice luxury to have, right? And tell, uh, us a little bit who is Daniel? If there's somebody listening in here and they've never interacted with you before, how would you describe yourself?

Speaker A: Well, basically, I've spent the last 20 years in and around product work. I started as a full stack developer when I was 15. Um, and then from there on kind of went through project and product Management. Um, the last couple of years I've been heading the central product Unit@ Ah, SaaS Group. So if you don't know SaaS Group, it's a serial acquirer of software as a service companies, mostly B2B. Um, and I'm there being kind of an in house consultant on all things product development practices, product strategy, pricing projects and things like that. Um, prior to joining SaaS group I uh, ran an innovation lab, so mostly for VC backed startups and um, Fortune 500 companies doing design sprints basically for a living. And I've written a book on bridging the gap between product vision and um, the product roadmap called From Vision to Version. Um, and yeah that's largely me.

Speaker C: All right, now what do you do outside of work?

Speaker A: Um, I am a bit of uh, a home automation nerd I have to say.

Speaker B: Um, tell us what have you automated that people wouldn't expect could be automated or maybe it's not the first thing they go and automate.

Speaker A: Uh, well for example we have um, an electronic uh, um, ah, door and I have a party mode. So if I set up the party mode I still get a notification if someone rings the doorbell, but the door swings open automatically so I don't have to go to the front do every time someone comes. My second nerd topic is that I'm an avid baker. I come from a bakery, uh, family. And um, so I have automated my dough handling um, to a point where um, I have ultrasonic sensors and camera that does AI recognition and tells me when my dough has risen for 80, 90, 100% and needs to be taken care of.

Speaker C: That's taking it to another level for sure.

Speaker A: That might be a little specific but um, yes, some of this.

Speaker B: So what are you bake, like is it bread, is it pastries, is it everything?

Speaker A: Everything. Like if it's bakeable, I do it. Um, but I bake like five, six, seven breads a week, something like that.

Speaker C: Wow. Do you have special ovens also at home or.

Speaker A: No, I make do with what my wife allows me to have as a kitchen appliance.

Speaker C: Okay.

Speaker B: So if we would, I don't know if you've seen this show. Like you know it exists in the US and in some European countries. Like there's uh, four random normal people and they compete, they invite each other to each other's homes and then they have to impress them with their cooking. So if Thomas and I would come home to you and you would like bake to impress, what would you serve?

Speaker A: Um, well the Most uh, impressive stuff uh, people uh, find is not, not impressive because it's tasty. But people just love the look. I do. Very, very nice turtles. Um, um, so baked bread turtles where the shell is kind of a Dutch, Dutch opening. Um, like crust in um, like I do this in turquoise as a color and then um, you have the, a bit of dough around for the head and the legs. Um, the kids love it. Um, people love it. It's kind of an easy way to impress I guess.

Speaker B: Sounds cool.

Speaker C: Maybe we should start a uh, baking show instead. Daniel, this is much more interesting than this stuff.

Speaker A: Yeah, it's going downhill from now, but

Speaker C: I think uh, let's find our way back. Uh, you mentioned SaaS Group. You are acquiring SaaS companies. What kind of um, SaaS companies are you looking at? When you're looking at companies to buy,

Speaker B: who is your icp?

Speaker A: Yeah, that's an interesting question and uh, it's an ongoing debate for years. Um, but essentially I would say we are acquiring all the hidden champions. Um, so when people think about the SaaS market, they think about the VC backed hyper growth, uh, companies, they think about the um, I don't know, lovables and versus and ramp of this world. Um, but I would say 90% of the actual SaaS market is um, uh, founder led bootstrapped SaaS company with like 5 to 20 employees, somewhere around a million to 10 million ARR. Um, profitable businesses, um, most with a kind of a legacy code base or um, running a bit, I wouldn't say running out of steam but uh, um, missing some of the more specialized um, skill sets to bring it to the next level. Um, which is exactly what we do at SaaS Group. Um, we buy these companies and help them run on that next level and give them the central expertise around marketing, finance, hr product, uh, to actually move that one level up.

Speaker B: So are you looking for them to be in a particular domain or industry or you're agnostic, you can be building a CRM or you could be building something completely different and that will still be interesting for you as long as you can check some boxes.

Speaker A: Yeah, we're pretty much agnostic with that. Um, so we don't buy to form synergies and we keep the brand as we call them, the company alive and keep it as it is. Um, so we're not trying to sell the parts or restructure it or just force it into our portfolio. Um, the only thing is we're doing mostly B2B or exclusively B2B I would say.

Speaker B: Right, but when you buy something, you buy 100%.

Speaker A: Yeah.

Speaker B: Yeah. Okay. How many companies do you have to date?

Speaker A: Uh, we currently have, um, I believe 24 companies.

Speaker B: 24 companies, right. And what is the total ARR of that port go, so to say.

Speaker A: Yeah, we recently hit a nice milestone of, um, over 100 million, ah, in ARR.

Speaker B: Nice.

Speaker C: Oh, nice.

Speaker B: Congratulations.

Speaker A: Thanks.

Speaker B: So is the end goal at some point to you know, build several hundreds or a billion in ARR and then list this on whatever the stock exchange Dax in Frankfurt, is that the goal?

Speaker A: Well, it might very well be in our future. I think it's too early to tell. Um, but we're not done growing it, that's for sure.

Speaker B: Yeah.

Speaker C: Okay.

Speaker B: I've always been curious. Just, you know, this is just me being, ah, nosy here, but how do you fund all these acquisitions? Like, you know, I guess initially you had a bunch of money, but do you. Is, is the machinery working well enough that the current portfolio companies, they generate enough cash flow that you can buy new companies or is it also based on external capital infusion so you can buy more companies?

Speaker A: Yeah, we have different levers there. So there's of course the, the organic growth and cash flow that, that funds quite a lot of it. But we, um, also have a debt facility and investors behind.

Speaker B: Yeah. So I think people now probably thinking like Daniel Thomas, ask this question. So I'm going to ask this question. What do you pay for the companies? What's the standard, um, multiple right now that people can expect for the companies that you guys buy?

Speaker A: Uh, that's an interesting one. Um, and there, as you know, probably better than I do, there are so many different parameters and things that go into that calculation. Um, I'd say quite often the opportunities that, um, we get in touch with and that we buy might land somewhere between a 4 and an 8 in a multiple. Um, but we've kind of seen it.

Speaker B: All right.

Speaker C: All right.

Speaker A: Okay.

Speaker C: Okay. And your role at, um, SaaS Group is, um, head of product and you go in and help these portfolio companies in that area. So, I mean, in these days, how do you see the product management role changing with everything that happens within AI? I thought we should try to stay within that topic a bit.

Speaker A: Yeah, I mean it is probably the elephant in the room. M. Right now, in every room, AI is the elephant. Um, so it's um, giving us a lot of sleepless nights as well, to some degree. Um, ah, just because everything is changing so fast. Right. So if you would have asked me for a prediction two years ago, I would have Never guessed where we are right now. Um, so we are constantly redefining how we work and what our expectation towards developer teams, uh, product teams, designers are. Um, and we discover basically every week a new way to create value and a different way how to shift value in these, in these roles. So that said very broadly, um, I do think that the product role won't go away with AI. Um, I think it will become a little bit more challenging. Um, and we need more highly skilled product managers than we did before. But those will really, really count and they will make a massive difference.

Speaker B: And what does that mean when you say highly skilled? What is that skill that values them or that elevates them?

Speaker A: Yeah, so the skill set itself and also a lot of the first principles around product building, um, they were true 10 years ago and they likely will be true in 10 years. Um, but AI magnifies different aspects of it. Um, so I think a lot of product managers simply got away in the last decade by being um, a manager of a backlog, kind of a concierge to a developer team, handholding them, writing all the requirements and then uh, doing QA on the release and writing release notes and all of that. They kept themselves busy with this work and I think most of that will be gone in a few years. But the work that has always been the value creator is the actual um, decision work. Um, so running a very tight discovery, managing, um, different time horizons, looking release ahead but also two years ahead, framing the vision, um, doing competitor research, talking with users, all of this won't go away. It will become massively more impactful in the future. And this should have been the core job of product managers five years ago as well. But for most teams it wasn't. And now the PM's need to step their game up and fulfill this role or if they keep to this rather limited set of job definition, um, will largely be replaced by AI.

Speaker C: And what prevented them for having the role that you're describing before? And how has that changed now?

Speaker A: Honestly I think it was about being in a very luxurious situation that it didn't count that much. Um, I think we always um, like building a SaaS business was never easy and anyone tell you differently would be lying. Um, but that said you could get away with building a mediocre product before and if you had a unique angle, if you had some funding, if you had a good go to market strategy, you could still make it work. But this era of building something that's good enough that simply is vanishing right now, um, good enough doesn't cut it anymore. Anyone and their grandmother right now can vibe code good enough. You have to do exceptional work, and exceptional doesn't come cheap. Um, it requires very much discovery work and deep understanding of the market, making the right calls. So this is where it shifts out of necessity for being better than good enough.

Speaker C: Yeah. And I mean, you were also limited when it came to how much you could ship because, uh, both of your development resources and the testing and the deployment and all of that, and now suddenly that shifts. You can create loads of features, um, and suddenly you're in a position that, as you said, you need to decide what to ship and what not to ship, uh, and so on. So what do you see there? Because it's not just making your life easier, that you can do more in less time. Right. There are new challenges coming with that.

Speaker A: Oh, absolutely. And I think it's right now a very interesting in between time where if we look into new companies that start with a blank page and not inhabited by tech debt, um, they actually, um, realize this 10x engineering effect that everyone is talking about with AI. Um, but they're usually missing the diligent product part. So they're building massively bloated products. And you can see the patchwork product being like getting out of that and out of hand. Um, every customer, hey, I have an idea, Bam. Next day it's in the product. Um, that works very well the first couple of months to, to get somewhere to get them traction in the market. Um, but at one point it will severely limit growth. You will have this behemoth of a product, um, that nobody can actually wield or maintain anymore.

Speaker C: Yeah. Can you give some examples? You don't need to mention company here, but you have 24, so it can be quite anonymous. Right. Because as you say, it's very easy to ship a new feature or a customization and so on. But still you have the tech debt.

Speaker B: Yeah.

Speaker C: And so on. And that's harder to just, you know, give an instruction and let, uh, an LLM go in and fix that. Or am I wrong here?

Speaker A: No, no, absolutely. And I think we are exactly on the other side of the spectrum where, um, we don't have the blank page and the problem of being too fast. Um, we have 10 year old legacy code basis, um, and we're not seeing this 10x effect that much. Of course we're being faster. Um, but AI is an amplifier. Um, whether you have a, uh, good code base or a bad code base, it will amplify that. If you have a good process or Bad process, it will amplify that. Um, so we have to be a lot more cautious uh, about what we actually ship. Um, so this hasn't materialized in the same way that it might have for a new startup. Which makes the, the gap between this even more concerning. That you have companies that have been dominating a certain niche for maybe a decade, um, and now the new incumbents can basically get to that feature set if they want it in a couple of month time and you are not starting to sprint at the exact same velocity. Um, you're throwing AI at it, but you're wondering when will this take off? When will we be at the 10x mark? Um, so that's a challenge.

Speaker C: Do you see companies building the product from the ground up based on new technology now, when it's faster to uh, develop? Or are they more trying to catch up with what they already have while putting AI on top of it?

Speaker A: This is a bit of the age old question in software development, right? Uh, how to get it away from legacy Even before AI. Do you do greenfield and just build the damn thing again? Or um, do you do microservices and go bit by bit? Um, in my opinion, my experience the um, greenfield approach never really worked that well. Um, it was always more appealing than in the end it turned out to be and it was a ah, sunken cost after some time. Um, whereas going bit by bit was the right strategy to do. And this I think where AI presents an actual lever in um, building the mock data and um, whatever is needed to safely go component by component and rebuild it bit by bit. Um, but that has to happen and ideally that happened three years ago or was started three years ago and now you can reap the fruits of that. Um, but it needs to happen and um, I'm completely with you that you can't just throw an LLM on an existing legacy code base and um, just describe a feature. It will do something but you probably don't want to put that to production.

Speaker B: So let me ask you this Daniel, and you mentioned this in the beginning here also, that the type of companies you work with, I think that very well, uh, resonates with us and who listens to our podcast. So most of the people listening to this represent, gosh, I hate the word, But a legacy SaaS company, they're older than three years. They're older than three years for sure. And listening to you here now thinking like, yes, I have a bunch of PMs here that may be simplified now of course lived in the backlog world like you describe it now looking at your 24 companies you have and looking at all other legacy SaaS companies there, like, what is your advice to them? Like okay, how do we move our PMs from being uh, backlog slaves to this future state of PMs where they add more value and so on. What does that mean in practice? What have you done with your companies that other companies can copy and steal that drives more business value?

Speaker A: Yeah, sure. Um, so I would say it's a bit of a patchwork thing of uh, smaller changes or practices um, that make a difference but they all come together in the end. Um, so let's start for example at uh, the ideation and the design phase. So um, the classical approach is that you have a PRD and then you give it to the designer. They come up with the 50 different mockups in all different states necessary. And then you hand this to the developer. They have to build it pixel perfect, but they also don't have to use their brain. Um, it's just all spelled out there. And in the end, um, you give it back to the PM that some uh, uh, find the 10, uh, differences between these two pictures and try to do a uh, QA with that. Um, so there are different ways to solve that bottleneck. Um, so first thing, a um, really good design system. Um, this frees up the designer to actually be part of the discovery work. Uh, most of our designers, um, they don't actually enjoy the UI work and they do a lot better job at um, figuring out the flow, the value proposition, talking with the use, who are exploring the competition. Um, so now they can semantically describe um, what should be on that screen. And based on the design system the developers would automatically or the AI will automatically, um, build it to design guidelines. Um, that makes a big difference. Um, then I think we also have to be honest about who we are actually shipping to and what problem we're solving. So I always say, well we're not putting people on the moon.

Speaker B: Um, most of us are not for sure.

Speaker A: Not if you actually are literally putting people on the moon. You know, please do the qa, please double and triple check it. But most of us are not.

Speaker B: Mhm.

Speaker A: Um, like I've seen a lot of PMs spending close to 15 hours a week in manual QA. Um, why not just ship the thing to a couple of, couple of users first 2%, then scale it to 10%, see what comes. If a bug actually arrives, um, let it be fixed immediately and then roll out again. Um, there's so much that we can do to get out of this mini waterfall series that we sometimes disguise as Scrum and be more pragmatic with this if we're actually honest about what we're shipping. Um, so with those very very easy things, and let me give a third mechanic here of feature flex. I think feature flags are the hidden champion of unlocking all of this. Um, I for example think that the product managers um, should be able to vibe code. I hate the connotation that this word right now has. But the idea is sound, um, that they can prototype on a production environment so the developers don't need to spend 90% of their time with tickets. Like can you change the button text here? Can you do another pop up here, Add a product analytics tracking to that page. All of this is busy work for a developer. Why not have the designer, um, the product manager do this immediately? Um, but how to do this safe? Mhm. So the two things that make this safe is that the developers take care of the actual system so not the feature. But building an AI friendly and AI friendly is human friendly build um, a very good code base. And the feature flags mean the product manager can ship this to a handful of customers that they know and then they can scale this. Having solid product analytics mean that uh, the feature flag is tied to a kill switch. Whenever um, one of the core metrics uh, drops by x percent the feature flag is automatically disabled. This is very very safe to do. Um, and this means that uh, I wouldn't call them junk work but all of the bits and pieces that just go through the development workflow, um, um, they just get front loaded now to the PM and the developers can do the high value work things um, around scalability, around billing, about security, about platform work, um, the AI algorithm and whatever their, their expertise actually is required to do.

Speaker B: Mhm.

Speaker A: So I think that those are smaller mechanics and they made sense five years ago as well. But right now they would solve the bottleneck and all of this shifts meaningful work to the PM where uh, they can iterate faster, iterate on real customer data, on real customer, um, feedback, um, frees up the designer to think about flows, think about holistically the product, think about the future of it um, and not be just burdened down by having to do the QA and the mock ups and every little detail and writing every little spec for every little feature. Um I think this is why a lot of teams um, are so slow

Speaker B: and based on this, have you seen in your portfolio companies or somewhere else that the product team, so to say the constellation of that designers, PMs, engineers. Is it changing? Is the ratio between designers and PMs and engineers, is it changing? Do we add more to one end than compared to what we used to do or is it more focused on another end? Do you see any changes like that?

Speaker A: Um, not yet. I think it's a little too early to tell. So the basic ratio that I always um take for advising companies is um like 1pm should be able to fuel nine developers. Um, it's a little different for each system but if you have four developers and three PMs um, um that might be an issue. Um, or you have severely no idea of where you're going with the product to warrant that. Um, otherwise if you have 1:00pm and 20 developers, um. I think that's also a little out of balance. But I could see this actually changing in the future. But it's a little early to tell in what direction.

Speaker B: And what does your crystal ball tell you? What is it? If you would be uh, a betting man, what does it change to?

Speaker A: I think we will have um, um, less product owners. Mhm uh, more strategic product managers. We will have more UX designers than UI designers. Um and if it comes to the development team, and this is something that we are already seeing is that um, we will have a bunch of very senior developers. We will have some native AI young talent that grew up with that as juniors but highly effective. But this mid level engineer will kind of vanish. Similar as we might not have a mid level product person anymore. This um comes again around to. I um think these resources need to step up their game to be relevant anymore. Um but their job is not going away. It's just shifting to something that um, they have neglected before.

Speaker C: Is it even possible to continue uh, work as an engineer or within product without starting working with AI? Can you be?

Speaker A: No.

Speaker C: No refusing. No. Then you need to go and get another job.

Speaker A: It will be like AI is the, the equivalent of the introduction to the Internet. Um, this is massive. It won't go away. Um, and especially in these roles, um, leveraging this the right way will be a key differentiator. Um, that said I also don't believe that everything needs to be AI right now. Right um, right now. Every feature, every roadmap, if it doesn't have AI on it, it's not compatible. Um, and, and I don't believe that. I think for a lot of problems there might even be an analog solution and not even a digital one.

Speaker C: What do you think people miss now because they're sort of just Looking at AI and what you can do, is there something companies, they miss or they forget?

Speaker B: Oh, I have an answer to this one as well, but this is for you, Daniel.

Speaker A: No, no, please, go ahead.

Speaker B: No, no, just my general take is sometimes I think, uh, and we're all victims for this or we're all the villains here. I don't know how we should explain this, but, uh, we are all in this tech bubble, all of us. This is our daily job, this is what we do. And all the people we talk to are people just like us. But sometimes I think people forget that the people that buy most of the software are not technical people. And I heard the greatest example, there was, uh, some company and a CEO there. They had built this great platform for golf courses, M. To book tee time, you know, like, so you go there and you book the time and what, whatever else you need to know about, uh, if you need balls and stuff like that. And he said it very well. Like, I mean the golf courses that we sell to, I mean they could care less what we do with AI. Like what they're interested in is like, is it easy for my members to book a time? Can I keep some stats, their points, their whatever it is like, you know, how often they come and not come and so on is like they don't need on the front end anything fancy AI. It's like if you on the back end use AI to build product and make it cool and so on. But it doesn't help in this case to tell the golf course owner we have an AI enabled golf course platform, they could care less about that. So sometimes I think people tend to forget, like, who are you actually selling to and what is the value you give to them and is it important to say that it's AI enabled or not and so on. And I think in many cases it's not. People just want shit to work and they don't care how you get there.

Speaker C: Usually people say that they need to say it, uh, because otherwise they don't get an investment or. So is that how it is for you, that if a, uh, company doesn't say that they are AI enabled or so you're not interested? Or do you see that as an opportunity that now we can go up and take this to the next level?

Speaker A: I mean, sure, AI has management appeal. There's no way around that. Um, and for a good reason. Um, so of course what we look at is, um, is it an industry that will in the long run benefit from AI or is it an industry that um, has it as a threat. Um, and we did turn down deals in the last year because we think that that whole industry might be under pressure from AI and might not survive it. Um, so, uh, from a risk perspective, an opportunity perspective, it's a big thing. Um, for me, it kind of stops when, um, AI is put on the roadmap for the sake of AI. Exactly. That has happened before as well. If we look at Blockchain, every single Fortune 500 company, uh, needed to do something with Blockchain. And we.

Speaker B: My favorite piece of software was like. Because nobody talks about it anymore. Ten years ago, 20 years ago, I don't even remember. It's a long time ago. Mobile software. Yeah, nobody talks about mobile software anymore. It's just like, I just assume that whatever shit you're producing, I can use it via my iPad, phone or, you know. But I think it's in some extent on the marketing side becoming too much of a buzzword, which means it, it doesn't mean anything.

Speaker A: Yeah, we have a solution. Desperately looking for a problem. Um, and I do believe that the problem space itself is pretty stable. Um, like going back to this job to be done theory, um, the problems that we're solving for our users or the customers of our companies. That problem existed 10 years ago and it will exist in 10 years. Um, the way we're able to solve this will massively change. So AI now expands the solution space so much, it doesn't mean that it produces the right solution. It just opens another angle to look at this. Sometimes it's the right one and sometimes it's the wrong one. Um, so again, first principles, we need to understand the problem and then we figure out the best solution. Now that we have AI, that's another angle to look at it. Um, but if you figure out that you can solve your customer's problem without AI better than with AI, and for the love of God, please do it without AI.

Speaker C: So what would you say back to the product manager, the product manager of the future? Uh, sort of the AI enabled one, or whatever you want to call them, the senior one, the product engineer. Yeah, but what tools do this person have in order to be efficient, produce quality work and all of that?

Speaker A: Um, what tools would they have? Well, in terms of, um, skills. Um, again I would say, um, they have the critical thinking and the ability to distill what's actually relevant from customer conversations. This is the one skill that won't go away. And we've seen, um, synthetic user interviews, we've seen AI, uh, bots doing user research. Um, and honestly, they're all really, really bad right now, and I'm not seeing this problem being solved. AI is by definition an averaging machine. Um, it's not meant to uncover the things between the lines. It was never its job and it simply doesn't excel at that. Um, so this is where the PM needs to excel.

Speaker C: And I hear a lot of PMs talking about that they get access to all the customer calls. Maybe they use gong or something similar where they record everything and so on. Have you seen that work in practice? That they actually get good value and can act upon that information? Or is it just a big chunk of data that you know it's the

Speaker B: right thing to do?

Speaker C: Yeah, it's a cool thing to show. Um, but it hasn't really had the impact yet.

Speaker A: I mean, it does have value, um, that's for sure. But would say you can't be the lazy one and calling it a day and just say, I now have access to, uh, my gong, my granola meetings from the colleagues. Because if we're honest, who actually runs those calls? Their customer support and their sales. I think if you have a lot of things around customer support and they do a tremendous job, then you might be lucky. Um, if you get all your conversations from sales, then you might be out of luck.

Speaker C: Um, in what way?

Speaker A: It is the typical question that I get. Well, um, can't I just view the recording of the sales demo? Um, they've been in touch with that customer. Why would I need to have a separate call? Um, they go in there with a different agenda. Um, and no disrespect at all, I have a massive respect for the salespeople. Um, but it's not their job to uncover what the customer actually needs. Ah, it's about uncovering how to sell what you already have to them. Um, and that's the opposite of what you want as a product manager. You don't want to know that much about the product you already have. You want to know about the product you're not yet having and if it's worth building. Um, so you have to have those conversations on your own. Um, there's no way around this. And I expect every single product manager to be in contact with their customers at least three times a week. I think this should be the absolute base minimum. And if you're outsourcing this to AI to granola meetings and have a skill in cloth that tells you in the morning, this is what we learned from our customers yesterday. And, uh, should I write a PRD for you? Um, you again in good enough, uh, territory and not in Excellency. Well that is the best explanation I've

Speaker B: heard ever on sales. Being focused on selling what I have right here, right now and convincing the person that this is what they need versus your PMs. They need to have a different type of look into the future.

Speaker C: Do you agree, Daniel?

Speaker A: I do agree, yeah.

Speaker B: And my m. Daniel, I agree with the fact that you know, on the sales side and we've been trained the hard way by uh, the other Daniel here on this recording that uh, don't over promise, don't sell something we don't have and so on. So I think all the training has been at like just make sure you identify problems that you can pick back to what we can do today, right here, right now. And then of course, uh, no salesperson just sticks to that. They try to paint a picture about how great the future will be. But yeah, it's a lot about focus right here, right now because you want to get to that decision.

Speaker A: Um, there is an interesting anecdote that happened um, at SaaS Group. Mhm. And I um, think confronted with this that um, there was a. I think it was a designer, not the product manager in this case. But um, they've been kind of frustrated because the um, salespeople used uh, lovable and other, um, no code environments to um, build out the potential features and demo it to the customers. Um, and the customers uh, at point loved it so much they would have bought it on the spot. So they now took this as validation and put this to the development team. Hey, here's the code. Here's the concept I've already validated with the customer. They love it. Um, can you build this out of it? Um, and design and uh, PM kind of felt a bit out of the loop. Um, and I believe, um, it's an interesting problem to have, but it just highlights what I want product managers to do in the future. Yes, we need to be faster in prototyping, in validating things, but we still um, need this to be done, um, under the filter of our vision and strategy with good user experience in mind, with monetization in mind. So I think the salesperson had the right mechanic, um, and was just the wrong person, wrong skill set to actually do it. Um, but I love that they took the initiative and the courage to do this and not just stick to whatever the rest of the team is doing and try to sell it, but be proactive. Yeah, I love that. Um, now this needs to become second nature to the rest of the team as well. Um, and they need to do this orchestrated together.

Speaker B: Yeah. And I got news for the PMs. If like the fact that a salesperson can do that in lovable right now, that's just, you know, they do it now because they can and they can show it. What used to happen in the past, salespeople would still try to paint um, a future picture. They just couldn't demonstrate it in a particular.

Speaker C: It's bad enough when they could do a PowerPoint that looked like it was real. Right. So being an old pre sales guy, a little bit afraid what the account executive would have done out in the field.

Speaker B: But Thomas you remember, so like Daniel, you Probably remember Watson AI 10 years ago. Like that's how long it's been. Thomas Now 10 years ago we used to sell something called Product Information Management System. It's a, it's essentially a database to manage your product information that uh, about your products that you're selling on websites and in other channels and so on. Uh, a technology that's been around for 30, 40 years. Probably uh, many established players and we were somewhat a newcomer and there was a couple of feature sets that would make everybody feel like holy shit, this is different. I'm betting on these guys because it's future proof. Thomas and his team, they used to demonstrate a uh, Watson AI integration that was, you know, like, let's say it not 10 years later it was a hack job. Uh, but it showed something that people never thought about. Like instead of you dealing with your own product information, writing these text translations and whatnot and so on, there's a machine that can do this for you.

Speaker C: You could add certain sentiments to the text, uh, and so on. Which was a little bit fancy.

Speaker B: Exactly. If on brand and whatnot and so on. And there was no customer that ever used that, but it was that type of feature sets that made them feel like holy shit in river. They're ahead of everybody else. We don't need this today but they're ahead of everybody else. And we want to bet on somebody that's going to be future proof. So I think if used the right way it gives people confidence to buy from you even if they don't need it today. But I think it's also a responsibility from the salespeople. Don't tell them this is a uh, standard thing or it's easy to use. We were very open with it that you need to have a Watson license. It comes at a master cost. It's not standard in the product. You have to build this in and so on. But the fact that we could demonstrate it I think helped us win quite some deals. Nobody ever used it in real life,

Speaker A: but I think on the meta level it's not only the specific feature, but being bold and shipping new stuff that is what makes a company future proof. And this might be um, a little outside of the AI thing but, but one thing that I'm recognizing a lot of these companies that fall into our ICP is that they've, if you log in once a year into their software, you might uh, over the course of three years not actually see a difference. Mhm. And if you confront the team with that, did you ship anything? And they will likely tell you, look here, we shipped over 400 tickets. There's another column here and another button there. And this text got changed and this is now 5% more performant. But it doesn't move the needle. So what if you haven't shipped 400 small things but you shipped four massive things?

Speaker B: Mhm.

Speaker A: Wouldn't that have a bigger outcome? So I'm a firm believer in focus, in going from scrum to Shapeup and saying we play six week bets and we just let go of all the small stuff. We need to make massive jumps. We don't walk, we don't run, we jump. I think that's the kind of mentality that's needed right now to be relevant. And if you are logging into your product once a year and you can't really tell the difference, then you've wasted a year.

Speaker C: Yeah. Love it. Really great. One thing that I would like to uh, ask you here before we wrap up, uh, we already mentioned the product manager role being more of doing informed decisions, uh, and all of this. But also we talk about product engineers like a new role and how it shifts. So it sounds with that terminology that the product person is going more technical or what does it mean, would you say?

Speaker A: Yeah, um, so we had a long discussion in our latest off site in Nice a couple of weeks back. Um, the term product engineer is not inherently new. It's not something that we invented. Uh, but it has been coined for us at saskrip at that meeting again, um, to describe that product management and developers will need to move closer together. They're still on a spectrum. Um, a developer, um, will never need to, or they should, but they don't need to interview users or um, run monetization scenarios. And um, a product manager will never need to architect a database or something like that. Um, but they need to move closer together. I think in the Future, we need product engineers coming from development that have a genuine interest in the actual product, in the ux, in the outcome and the impact that the product has. We will have product managers that need to, at least on a surface level, understand the technical implications that their decisions have. Um, where is it easy and cheap to add stuff? Where is it risky? Um, where is our tech debt concentrated? Um, I think this mutual understanding will become more and more important. Um, so you might both call a product engineer. Just coming from different sides of the

Speaker C: spectrum, do you think others then engineers will ship features in the companies?

Speaker A: Absolutely. Um, I'm seeing this in design, I'm seeing this in marketing, I'm seeing this in support. Um, why not? There's um, very few people that I think might get away with not trying to ship something.

Speaker C: Okay. So it will be easier for anyone to contribute to the actual product that uh, you deliver to your customers if done right. Yeah.

Speaker A: Yes.

Speaker B: And I think we already see it. We had someone on our last conference that took the stage and said like, oh, I had an idea and via some kind of a slack, uh, channel and some mechanism in there, I could write, uh, my, uh, whatever it is, call it the feature description and a click of a button, push it into production. It sounded great and scary all at the same time.

Speaker C: Yeah, it was Johanna at lovable and she showed what different things you had contributed to in the product, uh, you know, over the last few months.

Speaker A: Impressive. Yeah.

Speaker B: And scary though. A little bit scary, right? It is, yeah. So Daniel, I wanted to ask you, like, uh, let's imagine that like now there's CEOs listening to this podcast, there are CPOs listening to this podcast and what would your advice be to them? Like, so as soon as they take off their headsets, like what should they do? Should they walk into their product team and be like, we're changing things. What is your advice to them right now? If they represent the legacy SaaS, where do they start? Where do they start poking around to start forming a team for the future?

Speaker A: In any case, I would say start with the team that you already have. Mhm. Don't get too excited about switching roles or ah, hiring or firing in any case. But um, do this mental exercise of jumping a year ahead and think about if we look back, what will be the things that actually made a difference? Mhm. And then probably only three or four will actually pop out of that and say, okay, now we have four things. Let's say we have four quarters. How would we actually get this one thing done? Shift and Impactful in one quarter. And what do we need to change in how we run things to make that happen? And then a lot of the actual decisions that that need to follow will come out of that question. They will immediately stop doing some stuff. So stop kidding yourself with three three year roadmaps and half, uh, a year of strategy work. And if you, if you have that point where you need that, great. But all honesty, most of us are not. Most of us don't need a better direction. They need better execution.

Speaker B: Yeah, well said.

Speaker C: And if we look a little bit forward right now, the next 12 months, how many companies are you going to buy?

Speaker A: Um, well, if all goes well, I think like six to seven companies.

Speaker C: All right, not bad, good pace. And is there something that you're looking for right now? A new hiring SaaS group or something that you think you should. This is a role we need to put in one of our portfolio companies. What are you looking for when it comes to talent?

Speaker A: Shamefully, I have to say that I'm not sure which roles we currently have on our job board. But um, we usually hire around 30, 40 people a, um, year on top of those that we acquire, um, via the businesses. Uh, so there's constantly something um, surely around marketing and development. Um, but whatever role it is, we um, uh, make sure that there is at least an AI driven mindset present that has become one of the core criteria for anyone from finance over HR to development.

Speaker C: Okay, and can you find all of these open positions at SaaS Group or.

Speaker A: Um, we have an amazingly talented recruiting, uh, team, I have to say. Um, um, so I've never seen uh, this done that well in practice before any of my companies. Um, so kudos to them. Um, and being 100% remote changed the game massively. Uh, I remember I was working in a digital agency in a smaller German town when we put out the design role. We had over three, four months. We had three applications and you chose the least worst one. Um, and now in one week for the same kind of role, I get like 800 applications.

Speaker C: Wow. And lastly, is there anyone that you think we should put on the show here or a topic that we should go deeper into?

Speaker A: Well, probably any one of my colleagues would be a great guest here. We have so many interesting people and specialists.

Speaker C: Who's the most interesting colleague you have? Um, or is there any angle that you think we should, that you know, that you are doing well at SAS Group that we should dive into?

Speaker A: And we have um, a massive and incredible marketing team, for example. So if you want to talk about, uh, go to market, um, performance marketing, stuff like that. Talking with a shout out to Tim Hikes. Um, one of my colleagues, amazing guy, uh, would do an amazing job on the podcast. Um, if you actually want to go into SaaS recruiting and hiring right now, um, we have amazing people for that. Um, so highly recommend a couple of them. Sure.

Speaker C: All right. A lot to discover, uh, I hear.

Speaker B: All right, uh, Daniel, thanks a lot for joining the show. Um, my mind is certainly expanded and I'm a sales guy here, so I'm always, uh, interested to hear how the other side of the company works and how people will kill me for, say, the other side. There's no other side. We're all on the same side, yada, yada, yada. But it's always interesting to. Excuse me. To hear. Uh, we hope that you have a wonderful summer whenever your summer breaks arrives here. Until then, take care.

Speaker A: See you. Thanks a lot, guys. Thanks for having me. It's been a pleasure.

Speaker C: Our pleasure.

Speaker B: All right, Thomas, I know through the years you've been really, really close to product and engineering and everything that, uh, those teams have built and spit out in the companies you represented. Like, was there some news to you here today? Was there something you felt like, huh, huh? Uh, I haven't thought about that before. Or maybe even that Daniel confirmed some of a working thesis you have.

Speaker C: Well, uh, I can't really let go of the thought how a company would work or how company is working, where, when all the different teams may be sales or others are, you know, building prototypes on the fly, showing customers what they can do with the product, with things that might not already exist, um, becomes an interesting situation for all the different parts. And I think in the long run, it can have a really good impact on everything you do do towards the customer. But you need to find a good. I don't know, I don't want to use the word process, but you need to have a good framework for it, right? So it doesn't come to a surprise suddenly for the product department and so on, that it was actually done in a certain way. And also you don't want to show a customer a design that is total, totally different from the design you were going to deliver. So I think, you know, that there is some. Right now we are all testing things and, um, yeah, trying to do good things and are doing good things. But I think, uh, this will mature over time and can be a really good asset for companies that wants to go out and, um, solve the problems that the customers has out there.

Speaker B: Right. I mean listening to you, I just thought about maybe the future is some kind of a hybrid version. Yes. You get a set of a hyper, here's a standard toolbox. And maybe during the demo period the sales guy or gal showed something that's not necessarily doesn't come out of the box in the standard toolbox. But maybe in the future, thanks to AI, you will be able to expand yourself as a customer much easier based on the standard toolbox compared to what you can today. So if you saw a sales guy doing a hack job with um, and demonstrating something, adding a particular, I don't know, I was about to say skin or a feature set or whatever that was appealing. Maybe the future is that we allow our customers to have more power of expanding the products than they have today.

Speaker C: Yeah, because you know, usually you set up uh, like a sandbox, a demo environment and they get limited access and so on. I mean there is definitely a much better and value creating way of uh, doing that exploration together with the customer. So yeah, if you can nail it down in a good way, I think you can have a big advantage when you're getting your product to the market.

Speaker B: Yeah, yeah, yeah, absolutely. And for me it comes down to, again, it's about expectation setting and communication. Like yeah, just because you have AI, uh, you can't lie about stuff. You can, you can't over promise because that's going to bite you in the butt if you sell something that looks really good but it's a hack job. And then you put your development team or your product team in an impossible situation to start chasing this that maybe doesn't fit into the overall product strategy and then eventually you'll end up with a churn customer and it's not a good exercise for anybody. So keep expectations, uh, where they should be. You should be able to talk about the future, but don't over promise anything.

Speaker C: And I also think it's good, you know, to have others to um, talk about these things with. And I mean in, in saskrip's, uh, case they have their portfolio companies that can talk to each other. They are also there, you know, guiding them. And we do similar things in the community with the networks, with conferences. There's a lot of different arenas where you can educate yourself, where you can meet peers and um, yeah, try to figure this out that we have in front of us. But uh, yeah, really interesting talking to Daniel today.

Speaker B: Definitely. All right. We hope we can continue this conversation and these types of conversations when we meet, hopefully many of you guys in Munich here next week. So Sassyism. You'll find all the information there. It is taking place in this beautiful park. The building is called Isa Rinkel June 18th. So Thomas and I will be there. Hope to see you there. If there's anything in the meantime you want to chit chat with us about, let us know. You'll find us@danielsassius.com or thomasasseus.com or for that matter on LinkedIn.

Speaker C: Yeah, you can head over to sass.com as well. And if you want to get engaged in the community, there is a menu option community. You can join the Slack. You can also apply for our executive NCO networks if you work in a B2B SaaS company that is above 2 million euros in ARR. Ah. So we hope that we will see you one way or another and we hope that you will have a great summer.

Speaker B: Take care now.