How good design drives sales, saves on development, and increases life-time value with Lukas Klement and Laure Joumier

Product Stories

How good design drives sales, saves on development, and increases life-time value with Lukas Klement and Laure Joumier

Play Episode Pause Episode

Mute/Unmute Episode Rewind 10 Seconds 1x Fast Forward 30 seconds

00:00 / 00:29:38

Apple Podcasts Google Podcasts Spotify Stitcher

RSS Feed

Share

Link

Embed

Video

Summary

What if there was one thing that would help align your developers, save time and money on engineering, and increase customer satisfaction? It’s real, and it’s called good design. Learn how to use the secret weapon of bootstrapped SaaS founders Lukas Klement and Laure Joumier in today’s episode of Product Stories!

Episode

Victor: [00:04] Welcome back, everyone. Today’s guests are Laure Joumier and Lukas Klement, founders of Menutech and today we will talk about how good design drives sales, save some development and increases the general lifetime value of your SaaS. 

We’ll also touch on the life as married founders since they’ve been running projects and businesses together ever since they met. Laure, Lukas, welcome to the show.

Laure: [00:38] Hello, Victor.

Victor: [00:40] Yeah. Good. Thank you for coming. Let’s start off with just a little bit of a background about you and in your business. What [Inaudible 00:51] as entrepreneurs so far?

Laure: [00:55] Yeah, sure. So yeah, my name is Laure Joumier, I’m the CEO of Menutech. And I’m a UI/UX designer by training.

Lukas: [01:06] And then my name is Lukas, I’m the CTO of Menutech. I’ve been on the tech side of life for, yeah, probably well over a decade now, and that’s how we roll together.

Victor: [01:20] That’s awesome. And so you’ve always been a developer, is that right?

Lukas: [01:27] Correct. I started from so in the university more on the business side, but I’ve ever since transitioned towards software development, software engineering. And yeah—

Laure: [01:43] Yeah, all your life, right.

Lukas: [01:44] Hmm?

Laure: [01:45] Yeah, that’s pretty much it.

Lukas: [01:47] Yeah.

Laure: [01:47] What else have you done?

Lukas: [01:52] Yeah, so similar to some of our predecessors on this show, Laure and I have also started from an agency background. We basically run like entire tech and marketing for different startups. We accompany SMEs in their digitization. But we also navigate at corporate environments, especially, automotive industry, we have a lot of internal apps and services. 

I think one particularly cool project that Laure has worked on was a call of duty style task management solution for shop floor workers in automotive factories. So it’s been a pretty sort of broad and diverse journey to get here.

Victor: [02:38] That’s awesome. So you’ve [Inaudible 02:40], but together, and when did you take the leap towards [Inaudible 02:52], I think we [02:52] software here.

Lukas: [02:57] Yeah, doing this for a couple of years, we naturally develop the drive to build our own product, to shift away from this project work towards recurring revenue business. 

Naturally, we started with the sector that we were—that we felt most passionate about, which is businesses who serve food. We started in the niche of food information for food service businesses and over time, we have transitioned to focus on the healthcare market, developing into a leader in the food service ERP space. We now mostly serve hospitals and care homes, mostly in Europe, but also US and Canada. 

Victor: [03:45] So what does Menutech do for these businesses? 

Lukas: [03:52] We basically solve the problem to effectively run a teamwork across different teams in the food service. We enable personalized nutrition for every patient in hospitals and care homes. So it’s the whole process from what meals to offer, who are they suited to display this information, collecting orders, putting together procurement, and everything that you need to run a food service operation.

Victor: [04:25] Cool. And that started, as you said, [04:28] was smaller companies and now moved over to more of the enterprise sector? Did I get that correctly?

Lukas: [04:37] Absolutely. Yes. We’ve been starting mostly with hotels. Pretty soon, we’ll transition to healthcare groups. And then more healthcare enterprises with multiple sides, large teams, working together across linguistic barriers. I think that’s something that we do particularly well and we excel at.

Victor: [05:00] Awesome. Yeah, I know your background of course, and you fit very well in that sort of industry and sector. So that’s fitting, but it’s very amazing to see that you didn’t move upstream towards the bigger deals and bigger clients once that was validated. So I think that [Inaudible 05:18] want to achieve but then find themselves trapped with like their [Inaudible 05:24] position or their complete pricing model. How did you accomplish that? Did you have to make any major changes or did that just fit those bigger companies as well?

Laure: [05:39] Well, okay, like, the value that we delivered was multiplied, right, for a large organization, especially in healthcare, right? The core, so to speak, for the softwares to produce food menus. But of course, for patients, you’re going to have to do food menus, breakfast, lunch, and dinner every single day, there’s no weekend break or anything. 

So the software was definitely more intensively used. And then I have to say, just it came from our customers really, that they had ideas of how to kind of build a whole universe around this whole menu planning. And that’s how it quickly expanded from there. But I’d say it came from our customers, really.

Victor: [06:22] Nice.

Laurer: [06:22] We were really listening to them and being receptive to their feedback.

Victor: [06:28] That’s very good. So well, our main topic, and that’s what I really want to dive into here with you guys is design-driven [06:40] and the common phrase in the startup world, especially with the [06:45] space, true validation is when you build something ugly and people still use it. That’s when you know you’ve got something there. Would you agree or disagree?

Laure: [07:01] I won’t disagree, but I will also say that that’s not what you should be concerned with if you’re at the stage of product validation. What you should be concerned with is good design. And good design does not have so much to do with the aesthetic quality of your software. What it has to do with is the convergence between convenience and reliability for your users. 

So what you want to achieve is that your software is easy to understand and that it matches the expectations. And once you match those two factors, you have a good design and good design is the bare minimum for product validation. And then once you expect—sorry, once you surpass those expectations, so you’re not just convenient, you’re like self-explanatory and you’re not just reliable, but your software kind of overtakes the thoughts of your users, then you have not just good design, you have great design and then you can use design as your USP. And in this, indeed, you can concern yourself about that at a later stage in product validation.

Victor: [08:23] And I think maybe to even backtrack a little. Because I think a lot of founders, especially without a design background, may [Inaudible 08:33]. What in your definition is even design? Because what you said right now, obviously means it’s not about the bells [Inaudible 08:41] and things like that.

Laure: [08:47] No, it’s true. So there’s two worlds meeting in the word design. And I think that has to do also a bit with English language. Product design, you can both refer to the process, the iterative process in which you collaborate with different teams and build a product, build a software or you can refer to the end result, the actual sort of end result, let’s say of building that product. And yeah, this is where you have to decide and you have to be specific, to specify really what you’re referring to. 

Victor: [09:25] [Inaudible 09:25] to make sense. So you said for validation, it is enough to be reliable to solve the need. And so that’s what you’re aiming for during validation prototyping cycle. But once you have validated something, how would you step that up? What is [Inaudible 09:52] and then to add more or better design or make better decisions even during product development?

Speaker?: [10:04] Laure if you want to take this. Laure.

Laure: [10:07] The way I see it is that what you need to inspect to this core principle, let’s say, of product design is that you need to be user-centered. And that word has been overused, but I’m going to bring it up. 

One thing you need to remember is that you’re using a technical tool for a non-technical audience. In our case, where we’re not an API-based business model, we’re not a B2D. So our audiences are non-tech audience.

And so really, what to really remember is that you’re using non-human tools for human problems, to solve human problems. And so you just have to remember to be human. And just be in touch really, with what your customers need and what their problems are. 

And the beautiful moment where you go beyond matching your expectations and where you’re surpassing your expectations, this is really through iteration, through really just being there for your customers, a lot of domain-specific expertise really helps. This is where you’ve got to go also by that bootstrap rule of doing things that just don’t scale. And you have to go and meet with the customers, be there either on the phone or literally just like buy a flight ticket and go there and see how they’re using your software, see their everyday life and be on the same team as them in solving their problem in an efficient and amazing way.

Victor: [11:35] Yeah, it’s great. And it also ties in into two topics we’ve already had on the show, which is user journey mapping, as well as UI/UX testing, which I think if anybody’s interested, listen to that too. Because that also gives a specific tool belt. And so speaking of getting feedback from customers, how do you do that? What your tool belt here, specifically? Flying over, any interviews and things like that?

Lukas: [12:13] Yeah, I think we’ve been extremely traditional on that side. You have to see people face to face when you want real feedback. I think it is extremely difficult to implement this in a digital and scalable way. That’s why we’ve been flying out, meeting customers, especially when being exposed to new context. 

When we entered long-term care market, we had no idea how a care home looks like, we have never been in one, we have no relative who is. 

So our way was really to fly out to customers and accompany them during the lounge and really learn what the needs are on the ground. 

And as Laura was saying, those are things that don’t scale, but they will give you the edge over your competitors to deliver a product that is truly outstanding.

Laure: [13:12] Then that would be at the beginning. Afterwards, like, you train your sales reps, you train, you know, you want your account executives to really be there, to be receptive, to have those good communication with the clients. You can also, to such an extent, rely on some good tools out there that can monitor the activity, you can calculate, you can forecast when people are less engaging with your software. 

But indeed, at the very beginning, especially if you’re in this prototyping validation stage, do things that don’t scale.

Victor: [13:49] 100%. And especially since [Inaudible 13:54] lately, everybody’s been speaking about product-led growth and product-led growth only. Where the goal obviously, is to completely minimize any human interaction there possibly is. And I think that is a very good thing, that’s where SaaS is going in the end. And if you can make a product in a way that it really is so [Inaudible 14:17] anyhow, that’s perfect. Yet in order to get there, I guess that’s what people don’t understand is a lot of times is yes, taking people out of operations is fine, but then how to get there, you do need to interact with customers even as far as you know, buying a plane ticket even if it’s for a small customer because they speak for their entire customer base, I suppose.

Laure: [14:44] Yeah, I can give you a story, like, I think it’s very concrete. But for me that just works every time in terms of empathy, in terms of just getting it, what they need, is using your software on your own customer’s computer. And you’d be surprised, especially to have a non-tech audience. 

So I’m sure for all the listeners today, their computer is positioned in the most beautiful room of their house, of their apartment and it has like the best chair. It has all the accessories, you know, because we are IT people. So our computer is just it. 

And then I can tell you I visited this one client of ours. And one thing you need to know about gastronomy teams, like, professional gastronomy, they—so there’s going to be a chef, the sous chef, the [15:36] and then they all work in this mega room, and that’s where the magic happens with food service, right? And then they had, I think, can be considered one of the loneliest jobs ever, it is the chef pâtissier, so he’s the guy making the desserts. And he’s all alone in a room, in the dark, always cold. And it’s sort of like far away in a sad corner. And I swear, this customer, the room where they had their computer was behind the chef pâtissier.

So it was an even lonelier, even darker, even this natural lit room. And then that humbles you, you know, you remember that the obsession with IT is something very specific to people who love building tech products, but not necessarily those who use them will be who will use yours. 

Victor: [16:23] It’s the, “Oh, I didn’t test this in Internet Explorer,” moment. 

Laure: [16:29] Yes.

Victor: [16:31] Right. That is a very, very good story. So who is on your own product team apart from you two? How has that evolved over time?

Lukas: [16:44] Yeah, so we are a product team of six at Menutech, we’re distributed across frontend development, automation testing, backend engineering and developing marketing assets. And yeah, in our staffing, we were supported by Victor, by yourself. And literally, since day one. I mean, Victor, we met at a shuffleboard bar in Berlin, where we—yeah, we hadn’t even started out. So back then at tzero I think staffing was one of our main concerns, finding the right talent, matching it into the right team. And yeah, I think your support has been elementary for us to get where we are today.

Victor: [17:32] Wow. Thank you. And now you are six people, also congratulations. That is quite a very nice team for a bootstrap SaaS company. So it has been [Inaudible 17:45] guys over the last years. How do you work within that product team? Do you have a specific [17:54] like Scrum? Or is it [17:58] with less process? What works for you guys?

Lukas: [18:06] Yeah, I think we’re, in our tooling, quite traditional. We use Scrum. We are a distributed team now since the whole Corona kicked in. 

So myself, I’m a developer, I take responsibility for the product team. Operationally, I take care of system architecture integrations DevOps. 

But lately, I’ve been shifting a lot towards technical sales, especially in enterprise-level, where my involvement becomes increasingly important. And that’s where, you know, you need to rely on good processes, good knowledge management that people keep aligned on your mission, that other people feel valued in their role that they’re working at. And I think that’s really important to establish early on. I think, right when you start building your product, you have to really make sure to undergo the necessary iteration cycles, but don’t undergo them with the same person. 

So that’s, that’s why I always say that you need to have a couple of iteration cycles before you even write your ticket. Because if you let a developer redevelop the same feature five times in a row, you’re going to burnout the developer, morale will be low, and really you run the risk of developing a low code quality environment. People think that what they do doesn’t really matter, it will be changed anyhow.

And I think this is also my most important—I think the most important part of my job as a CTO is to keep everyone aligned on what we do, keep everyone motivated and you know, make sure that we can undergo those feedback cycles, those iteration cycles without burning out every of our staff and team members.

Victor: [19:58] That makes a lot of sense. Obviously iterating in code is the most expensive way there is. Iterating and design is also not cheap and way faster. That’s what you actively do?

Lukas: [20:13] Absolutely. I think this is one of the things that I’m most aware of all the time, like, what are the iteration cycles? Now, how fast can we iterate with a given process, and then I mean, with a given technology and given team?

So I think choosing the technology and the platform, it naturally implies a certain velocity. And most of the time, like when you’re starting out with your product, and software development will not be the right answer. So I’m saying that as a developer myself. There are better ways, better tools, and that’s where I think being design-driven is so important. Having a designer on board, already on it really helps you, you can fill out those gaps, you can speed up the iteration cycles. 

I mean, especially when you’re selling larger tickets, I mean, you’re going to end up selling things that don’t exist yet. So you have to sell them, you have the sales cycle. And as the sale materializes, you start building the product or the feature or the module that you need to deliver on this contract. 

And throughout the process, you need someone to fill in those gaps. And I think those gaps are certainly not developers. I think in most cases, what works best is you have designers fill this gap, to get you to that point.

Laure: [21:38] And also, if I may add designers are good at this. Like, if you have classically trained designer, if I could call them this way, they will not be afraid of a lot of repetition, a lot of you know delivering, a lot of design outputs in a very short timeframe. 

Really, when I look at some relatives and friends who studied Fine Arts, the kind of deadlines that they have to fit, really having to design your entire software suite against an unbeatable deadline is really—don’t worry, you can give them the challenge and you will thrive in this environment. 

Victor: [22:16] There [Inaudible 22:17] will get a lot of assignments after podcast, we apologize in advance. But I think this is a very, very valid point that you [22:30] especially last year, when [22:35] we met on the software development [22:40] very, very high in terms of the need for developers, but since last year, it has incremented, it has extremely increased. And I do believe [22:54] people can save a lot of manpower, a lot of iterations if they focused more on the design stage. 

Again, not saying that designers are—good designers are less expensive or less demanded, because it’s just as hard to find a good designer, but they can [23:14] so much faster. And the results are just magnificent. Whereas just as Lukas said if he ask a developer to rewrite the same feature for the 10th time, he will [23:26]. So what’s happening?

Laure: [23:30] Yeah, and then imagine you do this, and then you say, “Well, actually, the client didn’t buy it.” You built it for nothing.

Victor: [23:37] Exactly. There’s nothing worse for [23:39] morale than that because in the back and you’ve already optimized algorithms, tried to cache something, tried to fix things and then you have to do it again. But yeah, so that really ties back to being design-driven. Again, what should a founder learn who wants to become more design-driven, who wants to take advantage of that? What should the skills be? How should they refocus?

Laure: [24:10] So I mean, there’s a short answer and a long answer. So the short answer is, what we were talking about earlier is like, don’t forget to be a human. So remember that you’re building a technical product for a non-technical person and a non-human tool to solve a human problem. And sometimes it’s keeping it that simple that will allow you to kind of be design-driven in everything you do, keep it simple so that you can have a maximum impact in all your decisions. 

The longer answer is take a designer co-founder; we’re great people, we’re friendly and we’re good in this sort of—it’s literally our job to work on a blank canvas. Like literally, when I open my work tool and I’m starting, it’s literally a blank canvas.

So when you start a new adventure, a new company, a new startup, it is a blank canvas. So we’re not afraid of that. And we will be a great collaborative arson with development, but also marketing and sales or business development, then you can also count on us to deliver a lot of those design outputs that you need a lot at the beginning and you need to iterate a lot at the beginning, whether it’s a brochure, a sales pitch, a mock-up, all this. So we’ve got to have a good throughput. 

And finally, once you have a good designer who’s thriving in this environment, they tend to then become the perfect person to become a product manager, once your workday starts to get more settled and more sort of predictable. So you will win a great product manager after you have a good designer or co-founders. So they will accompany you throughout the journey.

Victor: [26:00] Which is a very valid [26:01] some of the best product managers be designers, well, particularly for the reason because the goals are very much aligned both roles.

Laure: [26:12] And you’ll tend to have senior designers are those who—the difference between a junior designer and a senior designer will be the amount of lifetime and designer has been exposed to a project. 

So typically, if you’re just involved before lunch, then you leave, you’ll be more on a junior role. But if you’ve seen how your product does in front of customers and you’ve iterated, etc, etc., this is how you gain in seniority. And that’s why it’s a perfect step to then become a great product manager.

Victor: [26:46] This is great. And your advice on hiring design co-founder, which is very uncommon if you look at the startup space, everybody wants a technical co-founder, but then they expect from them exactly what you just said a designer would be doing; to listen to the customer, iterate frequently and obviously, in the beginning, be super scrappy, but then make it scalable to thousands of customers, the same person and build a team, which is something that not every—this is a technical person to be on a very broad spectrum. And not that many people who are [27:35] involved, were asked to describe this is more of what designers do interaction. And then you know exactly what you need to build and you can hire developer, I love this advice. And I think that is a very good summary of this design thinking part. 

And so let’s move on to [28:07]—

Laure: [28:10] Okay. No, I just want to make sure. Lee, is there something that you think you wanted to add or? 

Lukas: [28:17] It’s fine.

Laure: [28:17] Good? 

Lukas: [28:17] No, let’s move on to the next part. Yeah.

Laure: [28:19] We good.

Victor: [28:21] Okay. I didn’t want to cut off anybody here. Wonderful. No, the second part I wanted to chat about because it’s I think it also aligns with our audience, it aligns with that who our listeners are and what kind of businesses [28:37] and that is about being founders together as a couple, even as a married couple. Which a lot of people I think do, a lot of people others [28:54] would never want to admit enough of those as well. 

So that certainly is a very cool topic. Would you call Menutech a—and I know this phrase has been overused over the past decade as well, ever since The 4-Hour Workweek. But would you say that Menutech is a lifestyle business? Do you treat being an entrepreneur like being a lifestyle?

Lukas: [29:23] No, I think there’s a simple answer. We identify as a product-driven bootstrap SaaS. And the property of our founding team being that we’re a married couple. It’s not been a defining feature for what we do. I mean, it has certainly made a lot of things easier, but it does not shape who we are. And it’s one of those, I think, founding combinations that can work very well in the right circumstances with the right people.

Victor: [30:02] That’s awesome. Because I think at the same time, even though you might not call it a lifestyle business, it still enables exactly that kind of a lifestyle. [Crosstalk] When you’re not tied to certain loop.

Laure: [30:16] Sorry, apologies, I interrupted your question. But I would not agree actually. I don’t think that being a couple founder or a married founder means, you know, sort of makes it easier to do to be a lifestyle business.

At least my way understanding lifestyle business is that you will voluntarily cap income by limiting the work effort in order to shield a free time. And with me, that is only possible in an industry where the revenue model is entirely project-based, and where you have 100% control of the projects you choose to take in or not. And that’s why I would associate lifestyle businesses more with creative agency or Freelancer style. 

Again, it doesn’t mean that every creative agency and every Freelancer is a lifestyle business. But I think that it’s more in this type of revenue model where you can exercise lifestyle business. I think, like being a couple is not one of the factors that make it happen in any way.

Victor: [31:25] That’s super interesting. Love this insight. Since when have you been working together so far now?

Lukas: [31:35] Together; we have a long history of working together. I mean, going back to university when we first met, whether it be for student assignments, projects, you know, later on in the agency, and then when we started Menutech in 2018. 

So I think we’ve always been very close-knit in our collaboration, very complementary. I think what probably defines us the most as a team is that we have a very divergent approach to thinking and problem-solving. And I think that kind of mirrors this design-development contrast, where Laure is the horizontal thinker, she thinks about everything from you know, not just the software, but where people use the software, in what context, with whom, what is their mindset and builds entire systems around the product or family of products to deliver this experience that the customer is looking for and eventually is paying for. 

Where myself in contrast, I exercise mostly vertical thought. I try to think of problems from A-Z, to think in-depth about all their interdependencies, to create a logically coherent system. And I think those approaches are entirely divergent. But this is exactly what makes a good team in my opinion.

I see it so often. And I think especially too with couple founders, the danger is probably more aggravated to where people tend to found businesses together with those people that they’re close with that often are similar to each other. And I think this is a very dangerous path. If you’re founders with too much of a similar not just skill sets, but mindset and mentality, then it may be hard to build sort of sufficient, like resource acquisition capacity as a team.

Victor: [33:50] Also, because [33:51] distinct roles within the business and you almost tried to compete within that one specific area or how do you see that?

Lukas: [34:00] Yeah, absolutely. I think in our case, we have a clear area of competence. I see this in every well-functioning team that this has to evolve, be at explicit or emergent, where defined by your skills and the time that you can devote to certain tasks and that will give you leadership and competence over that area.

And I think for us, we always had a very open style of communication and especially as a couple, I think that’s something that you can probably train and that working and talking about work is entirely different from a private conversation. And where you have to be able to express feedback. We do that a lot, and especially after conversations with customers, where we feedback each other, we analyze this situation and build lessons for all those situations that—or similar situations that will arise. And I think that’s something where you can build capacity together and that it’s—it may be easier as a couple because you also have just more time in the day to create those moments, to exchange feedback and to, yeah, build this capacity together.

Victor: [35:33] So that sounds a little bit, and that probably is exactly true. Like, if you step above and look at yourself as a team hiring both of you within your company and that makes sense, irrelevant of are you [35:51] not, then that might work out and if [35:56] that happening just in general, personal things, but simply because it doesn’t make sense for the business, then that will be hard. Is that kind of it?

Laure: [36:09] That’s a good rule. Even though every couple is different, I’d say that every business is different, every founding team is different. So it’s difficult to kind of give a—how do you say—hard definition as to what makes such a teamwork. 

But I’d say this, like if someone is wondering right now, if they should found a business with their spouse or with their husband, I think the first rule is if you want to do it, it’s usually a good sign. I mean, just do it.

But I’d say there are three red flags that where you should not do it if you have not. So one would be if you can’t disagree in public, you know, if you feel it hinders your couple to disagree in front of others, then don’t found a company together.

If also you feel it hurts your couple to not being able to like show signs of affection in public, don’t found a company together. 

And also, if you also need to be the kind of person where it’s just a fight, like you’re constantly, really passionate and talking all the time about what you do at work and what motivates you. And then do, this is a really good sign that you should found a company together because all those conversations, you might as well be talking about the same business, which is a return on the time spent talking about work if it’s on the same venture. So that’s usually a really good sign that you should found a business together.

Victor: [37:49] It’s also a great way I know that from personal experience to never stop working because essentially you—there’s always a topic to speak about even after work. That means that you can’t talk about these things very [38:05]. 

Wonderful. I thank you for that advice. [38:10] help people out there. I appreciate you guys coming on the show. This was super, super helpful. 

Where can people find more about you, about Menutech, get in touch with you?

Laure: [38:28] So you can follow us on Twitter and LinkedIn, you can follow Menutech on Twitter and LinkedIn. And for us usually, we’re very accessible if you invite us for a coffee.

Lukas: [38:44] You’ve got to buy tickets. You’ve got to buy a ticket. 

Laure: [38:48] We are foodies. So we are like hardcore foodies and techies, so I mean, if you tempt us with conversations about tech or about food, we’ll be there.

Victor: [38:59] Awesome. Thank you so much and speak soon.

Laure: [39:04] Speak soon. Thank you.