Today's podcast is all about “How to take a digital SaaS product from an idea to launch”. Our target audience is not only CEO's, but also product managers without much development experience. We want to find out what the secret behind successful product management is. In our conversation we will look at the foundation of product management, project strategy, product discovery, delivery, and marketing. Ultimately, it's about the practical approach of how to bring a successful SaaS product to market.
Wondering how to go from an idea to a successful digital SaaS product? Don't worry, you've come to the right place. We'll learn the tricks to make product management simple and pragmatic. Let's forget about complicated frameworks because today it's all about how to successfully bring products to market without much effort.
Valentin, we already know each other from 5 to 6 ventures where we worked together and built SaaS products in an agile setup. We have probably worked together on and off for the last 15 years with mixed teams, so some remote and some onsite.
Midlife Entrepreneur Podcast
Subscribe to our podcast and join us on the journey through entrepreneurship
Practical experiences on lead management, product marketing and product management. Solutions from like-minded software entrepreneurs with their work-life balance stories.
Listen to the podcast, How to build a SaaS product in 3 months (German)
You've always built products there, and I've come to extremely appreciate how you manage to be so pragmatic, and felt without much effort, so on the side, and without being overworked, to get those products off the ground while also managing the development teams.
That impressed me! Still, I wonder – the hard-core prioritizing, the transparent approach, and the team management – that's not all there is to it. There has to be more to it than that. If you look in theory, there is a foundation from product management
That's in the intersection between the technology, user experience and business.
In UI or UX designs, it's about mockups, user flows, information architecture. Or in business, when it comes to business models, financial KPI's. But also project management - Scrum, Kanban, Backlogs, all the user stories. Certainly not just Data Analytics, you just have to have a deep understanding. So, that's the foundation.
But product management is also about project strategy. So a vision, who is the customer. It's about product discovery, how you research that. You do interviews with the target group, it goes into protoyping. You test it again. It goes into product delivery. So the Requirement Specifications, it's about Product Roadmapand the prioritization. Finally, it's also about product marketing, how you go to market, positioning, with messaging, what are your unique selling points.
My thesis is that you can't find these skills in depth in one person after all. And not even in you.
That's why I'm asking you today how you built the products, what worked, and what not so much. I don't want to talk about complicated frameworks right now, I do that enough. I'm also super happy to apply any frameworks. But it's about the pragmatic approach of how to get a SaaS product on the ground.
That's why we want to look at these three topics. Maybe you can answer the first one. Why are you building a SaaS product?
I think it's predominantly when you're solving a problem for a specific group of customers.
There the ideal customer profile, we call it the Ideal Customer Profile (ICP) has either a pain where you have to solve something, or a need. And so one is either a “Pain Killer” - a pain pill or a vitamin. In reality, most vitamins are those that bring improvements from a process or something and rarely a “Pain” without which it would not work and which causes pain.
So there are actually few "Pain Killers" but many more vitamins. How do you go about it, what do you do differently in the approach when you build a vitamin?
I think the important thing is that you work with understandable methods. That you have simple, clear processes and frameworks. A simple framework that I think is cool is the “Golden Circle” by Simon Sinek. It structures in Why? How? and What? and you can orient yourself to it.
When it comes to building products, simple & pragmatic always beats complicated & perfectionist. Every time. That has also been my experience over the past 20 years.
When I started as a developer, in product management and then a bit bigger in product teams. And now also regularly in SaaS products, you always learn something. You have to apply it dynamically, but it's not a 10,000 step process, that's thought out with all the details.
It's brought together by trying to put yourself in the person's shoes, bringing a lot of passion and getting that across to the developers, the team and others. So that you can be guided by a vision and always know where the North Star is and where you want to go.
What is from such a pragmatic approach, ultimately the product?
In the end, if you do everything right, you always get a digital product. That can also be a mobile app, a SaaS product, or an online service that you offer to your target audience and really adds value to them when they use it, that they can be better off or achieve more.
The problem we see when there is endless discussion and the product never gets released, you don't move forward and it gets delayed. The processes and the whole product team end up not putting out what you hope for.
First, why don't you tell me what's a really good way to blow money instead of working on a targeted solution?
I think the first thing is already in the “why” of not knowing exactly who you are building a solution for. If the Ideal Customer Profile (ICP) is not clear and everyone has a different idea of whom the customer might be, what the benefits should be exactly, and if you don't have a cornerstone – that is, a cornerstone or a clear north star. Then everybody will develop on it and change everything again all the time. Every week new discussions and always discussions of principles, or you get completely lost in details and can't do the benefit anymore.
If you also don't know how you want to validate it and don't have acceptance criteria that you know when you've met them, it's fine. If you also don't feel who the customer is.
There's often a big gap between the customer and the developer. The developer may be in a different place and doesn't know what makes the customer tick, how they live, how they use the tool, and how they have to deal with it in the first place.
And where are these flaws in the approach? Where can you lose money there?
There it is also often that you simply work inefficiently. The first is times when there is no ownership, when no one stands for this product, is responsible for the decisions and defends them against others.
You're a group, something unclear and everyone gets a say and no one knows where to go. Every week the CEO comes in, then the investor has another idea, then the developer has another tool released, no one is really holding the strings together. If this process is not managed, if everyone can do everything, everyone would prefer “the jack of all trades”.
If you've never learned to say no and want to implement all the features right away, you'll have a never-ending development list that never gets done. If you overload a project, there are far too many stakeholders in it, and you want to please too many people, like in the Dilbert comics, where there are lots and many buttons because everyone wanted one more.
Or when you just don't have the know-how, when you want to build a SaaS product, but you don't know how to build a project because you don't have the knowledge. There aren't that many people who know how to build a SaaS product.
And if you've never learned to prioritize and weigh features against each other. That's very hard for everyone to do. Like when you have a business idea, and you're not a techie, you don't have technical people, and you can't give the responsibility to product owners. If you have far too little time to put into a product, but are busy with many other things because you still have to do marketing and sales.
What about the unique selling proposition? With the result, is it really that important to differentiate yourself?
You often see when you have diffuse solutions that neither focus nor cheaper. After all, they always say you should get 10x improvement, create 10 times more value. You can also do that by being 10x cheaper. If you give it away for almost free and only have 10% of the cost, but the same value.
Otherwise, you have to deliver more value, or you do a mix. You might be a third cheaper and three times better, then you also have 10X.
You often forget that, you get a squishy solution that has no clear better value. People think it's a little better, but doesn't really do much. You can't convince people that way because you're usually a new product or someone new.
That's why you always have to focus on the benefit and the result at the end and figure out how to measure that. So that you can quantify the purchase value as well.
You can waste money by not knowing the target audience, not managing the process, not having ownership, not prioritizing, or even not having a user focus. It makes sense.
This problem description sounds as complex to me as an SAP integration project that takes a year and you still haven't really started. How do you do it pragmatically, how can you solve these problems?
I think the first step is to find your Ideal Customer Profile (ICP). Ideally, of course, you know it, you might be the user yourself or have worked with them for a long time and be in it. But often that's not the case.
And if it's not the case, you have to find a way to get there. First you write it down, do a persona project. You derive exactly what the Needs and Pains are. It's not just that they're 50 years old, male, and have a cell phone. That applies to far too many people. Then you have to validate it. The way we do it with a new product idea is we document it. We do a slide or sketch and send out emails to the potential ICP audience. We validate it in calls and then you see already in 10 calls and people are wondering what exactly is the benefit, then you are probably not on the right track, we have had that experience ourselves.
Then you validate it step by step and increase the complexity. First you discuss it, then you make a mockup. You draw it and maybe build a clickable prototype and test it. That way you always have more meat on the bone, you put more energy into it, and you don't start developing it right away. If you do a sketch and have it developed right away, it's expensive, and the risk is high.
You try to get there with experimentation.
So you're already going into the process. Can you describe it in more detail? How do you build such a product now?
Yes, I would like to say three things about it:
For “design the product” you could do quite a few podcasts just about the design process. I'll sum it up, I really like to work with a model and successfully.
This is called “The 5 Elements of UX” by Jesse James Garrett:
There you have a clear structure in there on how to get to a product relatively easily, which the user can then see. You can test it or then develop it later. It's important to first know who you need to build for and what you need to build, and only at the end how it should look then.
Don't start discussing button color when you don't even know what use case you want to map.
Then of course you have the agile methods, there are several. The best known are certainly Scrum and Kanban. You must have a methodology and stick to it and that you have clearly defined this process. But you can have long religious discussions about which one is better. That's where Scrum's processes are still explained.
Then you should work with mockups to make it quickly visible. That's important for you so that you have a clear demarcation and that you can also show it, test it with customers and that also internally everyone knows how it should work in the end – ideally with clickable prototypes.
There are today's technologies that do that well, with Figma or Balsamiq. Then to the rhythm, there are a few points I'd like to focus on.
I work in a “scrum” agile development process. You have sprints that work for me and are scheduled every two weeks, but with a small backlog. Not the huge crushing ballast of everyone writing in an idea and user stories.
As a product manager, you need a small backlog, and you clearly state where the focus is. Everyone can commit to get there that way, too. You work in small teams, 3 to max 6 people, including the designers. Everyone understands where the journey is going and can also dynamically adapt and commit to every sprint where they want to get to.
Then you have Daily Standups, Touchpoints Huddles, whatever. It's good to have a structure to measure progress. Then you can review monthly or bi-monthly, it depends on the team, and iteratively always improve.
Then it is already worthwhile that you make a quarterly planning as a product manager or with the management, possible investors or product owners, client.
I really like to work with vision and roadmap. That you have a big long-term vision of where you want to go, what you'd like to have happened, and how you're going to get there
To really create that added value. That's often where the gap is also huge with developers. You actually always have to communicate that much more than you feel like the end product should be. You can do that with pictures or videos to really convey that image.
When you break the vision down into an annual roadmap that's very rough, with big goals, and then plan those into Quarterly Roadmaps. I've mostly done that with a normal presentation. In a simple document, one page that everyone can look at and discuss. In Quarterly Roadmaps, it's logical that the current quarter is a little more specific, with the things you want to accomplish.
And the next quarter is already more imprecise, the third quarter is very “fuzzy”. You don't want a nuclear power plant there, but you build a product of which you don't yet know exactly where the end goal will be. You want to learn and get there iteratively. So, you say, in three months I'll have the first version. And then the next version will come, and there's a lot to learn along the way.
I think the dynamic, constant updating, is important. So you can visualize, but you are always ready to change things again. That you also put in every quarter big cornerstones that bring a change. Often when you ask in everyday life, there are 300 small features that you have to improve. But the end customer doesn't see that so firmly, only the individual user. Then you may have developed half a year and feel the product has not progressed.
Every quarter, you should set yourself at least one peg that you say will take the product to the next level. Every so often that has no effect, but occasionally a big one. You can only create long-term goals if you constantly work on them again.
Otherwise, you're overwhelmed by the daily clamor and demands of Sales and Customers. In addition to the process and the vision, you need a top 100 feature list as soon as you get bigger. Everyone has requests, everyone is super important.
Now it needs to be done, if I had that, I could have one more customer. Then you have to write it in and keep updating it, so it's plausible that there are many other wishes. You always have to prioritize it against each other.
A list always has something at the top and something at the bottom. And so it is also clear that not everyone can wish. Still, you don't just ignore it. That's also a dead-end, you lose people along the way if you always say no. And the reality is that you always have to say no.
Then there are a few stumbling blocks to avoid. With experience, you can abstract a bit and pragmatically weigh, when do I want to release, what is the MVP, and leave stuff out of the scope for that.
Initially, you always have too big a list. I have never experienced that the list was too small. Then you look at what you can take away, and that can be pragmatic. That you also don't get lost in the project management tools, of which there are so infinitely many.
Or task lists, where you have 3000 tasks on it, everyone knows what they have to do.
Then change something, and you only have half a day already to update the tool. So simplify. Better to use short, simple things, a simple to-do list, even if it's just post-its on the wall, than too many tools.
And as always, say no. Feature creep always comes, there are overflowing requests. You always have to internalize the ICP. What should you do, what adds value, and what is just not relevant? So that you can get it on the ground, release it and do stuff later. If you can't do it that well yourself, don't have the know-how for certain skills, then you have to get help, buy in knowledge.
On the technical side, if you have smart developers, they prefer to build everything themselves. They want to reinvent and preferably not use existing solutions because they don't do exactly what you want. You have to be pragmatic about that. It's not Rocket Science. Most of the time, after all, we build applications based on it. That's why it's always about speed. If you can release fast, you can improve faster. If you release slowly, you have to be right.
You said before, get help. That's a good transition. The development, how do you ultimately make the team that builds the thing? After all, you are the product manager yourself and not actively involved in development?
That's often an obstacle, most people are business people with business ideas. They would like to build something, have a vision, want an app or tool. But they've never built anything before, never had a co-founder or CTO with them.
Now they would like to have this mysterious egg-cellent co-founder who can also design, understands UX and the customer, and also develops everything on their own. If you have that, then go for it, take it, that's great. But it's also luck and if you don't have that technical co-founder right at the beginning, then you can also find him later and bring him in later when you might already have an MVP and he can imagine it better. Top people are always busy, they don't just come along.
We have the option of hiring an agency. That can work too, you can define it and make it live.
But it has two disadvantages. For the agency, it's always a project. You start, have an end date, then it's out of sight out of mind. But you want a living product that evolves and has ownership. That's why it's a contradiction. On top of that, it's also relatively expensive.
The second thing is freelancers, building remote teams.
There are good platforms like Upwork, Toptal, Fiverr and other things. That's where I've had excellent experience, but you have to practice it and have a process for how you find them and recruit them and also how you quickly weed them out if it's not a match.
But you can find excellent developers who also have some ownership and are reasonably priced. Or you really create there with a remote team if you have a bit more budget and if it's a long-term thing. Then you recruit them and build it with them. You can also grow it, preferably in one location.
I recommend in the beginning it's easier if it's closer and in the similar time zone.
As if you just go to the Philippines or Indonesia, that makes it harder. Generally with remote teams, it's either you're a strong product person yourself. Or you bring in someone who has ownership of the product
That can be as an advisor or otherwise a partner. But somebody needs the ownership. The remote teams are then often very far away from the business and the customer. As a CEO, you simply burn yourself out if you do everything yourself. If you do a product, customers and funding, it's a matter of time before you really have no energy left.
Your approach to solving these problems is always a crystal clear ICP. Interviews with target audience, then the rhythm with vision and roadmap and finally the development processes, team management to have a grip.
How do I know it's working as well? Are there signs that a result is coming out and is the right way to go? How do you see that?
After all, we often compare it to Random Acts of Marketing (RAMs). You do something and suddenly something works or doesn't.
In product management, yes, it's similar; you take an “educated guess” approach. There are two dimensions you want to pursue.
You want to get a measurable value add for your ICP. There are several frameworks there as well, if you know what the Acceptance Criteria are or have a constraint-focused strategy (EKS) where you always know if it needs more light or more water for the plant to grow.
Or a framework, like “jobs to be done,” where you can also measure. How did we solve what the end customer wants? Is he better off now or have we developed past him?
It is then important that you measure and compare it again and again. So you can also find out the trend, whether it goes up or down. You can't quantify it that well in some cases, but you can quantify trends well. You have to keep updating the living documents, like the roadmap, always.
And take a step out and ask yourself if you're on the right track. The second dimension is that you have a shipped product. After all, there's a graveyard of startups that have been developing for years and are still investing money because, yes, they still need features before they go live. One day, you have to “ship.” That's what they say.
As a Founder or as a Visionary, you should actually be "embarrassed" that you are "shipping"
your product.
What's important is that you're constantly improving and upgrading. The continuous is more important than the perfect product.
And what also helps is if you have a motivated development team that thinks along, has low turnover, and won't leave you. And creates an environment that people want to work on it long term, generate more value and if you're lucky, you find those ominous 10X developers. I find those occasionally too, but they are rare.
You can also create good value with normal developers and motivated people.
Do you have some examples where you can show that there have been results?
Yes, I have a few listed there. A couple I've built myself. One is Payyo, a payment gateway like Stripe but very focused on tourism.
That was an extraction from an existing product, we solved the individual functions but didn't have our product, as a stand-alone.
We then wanted to build this as a pair. Then we had teams of 3 and teams of 4.
We said obviously, 3 months, then we have to be live. What is the core, what do we need to be able to do? How can we show that we are solving the most important things?
Then that worked out, we added two more developers. The team is still there in the same form, and it's 6–7 years later. That worked a lot that everyone has that ownership mindset.
Then other things, like with Trekksoft it was like we built a simple prototype first. Before we built the real product. The first version of Trekksoft was developed in 2 weeks over Christmas. We wanted to see if it worked, and we had no money either. Then numerous things didn't work well, but the core thing did, the booking solution.
Then we built a mobile app, like Square, where you can do credit card payments. It was clear we wanted to do something revolutionary.
Something we could show at a conference, at a launch day. We knew we had 3 months, we had a limited budget, and it had to go live.
We've never done credit card payments with a swiper like this. Then we compressed the scope and the closer we got to release day, the more we cut out of the scope. Simply so that we could launch. It actually went live then as well. That was pretty cool.
Then there are examples like Doodle. It was also a product where we did a prototype while studying because we had a problem, we were ourselves the ICP of complicated scheduling.
It was able to solve a huge problem. The product is scaled to 10 years, with pretty much the same design. We were always trying new things. But you can argue if you did it better.
Then there's SmallPDF, which also came out of a need because someone was overseas. He wanted to get his mail sent as scans and teach his parents how to shrink scans, that's why the website is called SmallPDF.
Obviously, many people had the same problem. A core feature is being built more and more all around, that it's a whole suite of solutions.
One product we are also developing is a chatbot for the hotel industry. There the focus is clearly what are the use cases of hotel guests and of the concierge. What do they need, no blah blah blah, but what does the individual hotel guest want and when is it easy to do a chatbot.
It seems familiar. When you're building a new website, even a small project, you have this idea of what else you need to put in it
You want the thing to be bigger. That pragmatism you described is necessary there, too. So what are your personal learnings, how do you deal with it? You manage to implement the product felt on the side or with a certain calm. How do you do that?
I think step by step. How do you cut down a whole forest, tree by tree! That you start with a small scale, when you come to a team with a product idea, that you don't just throw everything overboard, want to implement all the frameworks, and want to implement all the stuff I was referring to.
But rather, you look at exactly where you want to start. Once everyone understands it, and it works, we move on to the next thing. In the back of your mind, you already have to keep the vision of where you want to go. But you have to change things step by step.
It's about hard decisions – the hardest thing is predominantly in scope. That you shrink the scope, and say no to things. That's certainly one point. The second is also admitting when you're wrong.
Or when learned that the ICP is different, and you make a different decision. That's okay if you're sure of it. You don't always have to be consistent. As should be the case in other environments. You should also make decisions unemotionally. Even if you thought the feature or design was mega cool, if it doesn't work, it's the wrong thing to do.
I think it's also important not to be influenced by external stakeholders.
Only if the ICP tells you that it is clear, or the benefits will not get better. Your vision should only update based on the ICP. When you start to doubt the vision, when you are unsettled, then you listen to this and that. To investors, to the board, to colleagues who are not your ICP at all.
Then you build something completely useless. Then it's still about skills, which you can learn, or at least know is important.
The differentiator in recruiting people, from a good product, from a developer, is always passion. There is always a company that pays more.
Even in Zurich, where Google is, the financial services and banks, you can only convince by people also believing in your dream and also making it their dream.
There is this saying: “If you don't build your dreams, someone will hire you to help build theirs.”
But I don't think you have to have others build your dream. But rather you have to get people on board, start a fire and everyone works on it.
That's something you underestimate, that's important everywhere, for everything you do.
You've talked so much now, I've forgotten half again. What do you give to these CEO's and product managers who now want to pragmatically build a SaaS product? Can you summarize that?
The one level is already, don't get discouraged. All these so-called successful overnight success examples. In reality, it wasn't quite like that either.
The most important thing, is to have a vision. As a founder and builder, you need the big story. It may take fake-it-untill-you-make-it until you get there.
But that you continuously see improvement, that it's always something more.
It is then also a marathon, and not a sprint. It takes a long time until it then comes so far. And everyone is boiling with water. When I read the press releases, LinkedIn posts and sales pitches, it's always the “pretty version”. It's often not the truth.
And it's not Rocket Science, after all, but you have to keep at it.
Then comes focus on the ICP. The motivation has to get there that you think the ICP is cool, and you like the customer. There are books, like by Stefan Merath, The Art of Loving Your Customers (German).
You have to like spending time with customers, like understanding their problems and needs. Then you build a better product. If I build a product for someone I think is dumb, then it will never be a good product.
Be pragmatic – always keep working on it, accept that it's not perfect. Speed is much more important than perfection.
The second thing is ICP. Focus, focus, focus. more focus. Don't get watered down, always have the wool in your head, and yes, don't go there.
And learn what the customers want and solve it ten times better.
And the last one, that's probably the biggest one: the vision. The passion and being driven by the vision. That's the core thing.
You're never as good as the category leader, either. But your passion and vision is key. That can light the fire with your customers, with your early-stage customers, your employees, investors, and developers. They take all the energy out of your passion.
You can also look that nobody leaves you, that actually worked very well. Geil. Merci, now I'm just mega driven to build a product.