Building the first product teams in early-stage startups - with Sebastian Sabouné @Founders Factory

Welcome everyone to a new episode of the Product Bakery Podcast. I'm here today as usual with my co-host Christian and with Sebastian Sabonet. I hope I said it right. Hi guys. Hello, nice to be here guys. Thanks for having me. A short story about who is Sebastian. I was in 2019 at a conference called the Product Management Festival. And once I was listening to your presentation, Sebastian, I realized it's time for me to quit my job and start working as a product coach. It was back then the first time I heard that name product coach and also the concept behind it. So I said to myself, hey, this is exactly what you want to do. I just saw him speaking behind him a couple of slides with spider graphs and I was like, okay, that I need. From that point on, I was working towards that goal. Nevertheless, it's not about me as always. It's about you, Sebastian. So you started your career originally as a journalist, but then moved into project management, product management, and moved all the way up to the head of product position, which you are fulfilling right now at the Founders Factory. Maybe you can tell us what the Founders Factory is and what you are doing there. Yeah. I'm happy that you have found your goal then, Christian. I was a bit worried there about you quitting your job. That was not my intention. But as long as you're happy, I guess I'll take credit for that. So yes, I can tell you a bit about Founders Factory. We are a corporate-backed accelerator and studio. What that means is that we have investments from bigger corporate institutions. So if we take London, for example, we have The Guardian, Aviva, L'Oreal, EasyJet. And the overall idea is that if we could capitalize, use some of that capital that big corporates have and do what they are notoriously really bad at, which is creating early stage, either creating early stage ventures or investing in early stage ventures. So corporates have venture arms where they may potentially invest in later stage, but just early stage investment is and creation is really difficult. So what we have done, what we do to those corporates is we say that we are going to invest in a set of companies and create a set of companies per year. And that creates the two different programs. So on the investing side, we have an accelerator program, which is compared to other accelerator program, a bit different in that we do it completely bespoke and we don't do cohorts. So you as a startup can start whenever suits you best. We also have a big operational team. We have everything that you as a startup might need when you join. So product engineering, growth marketing, investment, legal, et cetera. And we will essentially become not so much like an extension of your team, but you will get, it's like less about mentoring, but more about teaching people how to do things and then them retaining that knowledge. And in the studio science, we try and create companies from scratch using insights that we get from corporates and from our own team and our own insights, try and create like concepts and prototypes and validate that early on in the market. And then we try and attract a CEO or a founder to that idea. And then we help them go from basically zero to one building the initial product and building the initial team in the hopes that will become like a really successful business in the end. And we've been going for almost five years now, I think with a studio in London, New York, Johannesburg, and yeah, it's good fun. So with the studio, does this mean that I could pretty much apply as a CEO or for a CEO role and you would equip me with a package, which is like already like the kind of idea and a first product in place that I would then like scale from there? Or how can I imagine that? Yeah, it will depend a bit on what type of project there is, but essentially, yes. So the deal is that we give you 250,000 pounds in cash in two tranches. And we take 25% and the rest and the 75% is yours or like yours and the team and whoever's investing going forward. So essentially you will become like the owner of that, the majority owner of that idea, essentially. With Founders Factory, we act as a co-founder and you get a dedicated team and you get access to all of the resources at Founders Factory as well as part of the deal where we together will build out this product and help you spin out into a proper company after that. So essentially, you're actually a Founders Factory employee founder in residence until we incorporate the company. How is your day-to-day business as a head of product that helps other companies to build products? Yeah, so that I guess is why that's how the coaching part came into it in the beginning. It's that because what we do is not necessarily product management on a day-to-day. Me and the team, we have created this product coaching framework, which you mentioned that you've seen as well, Christian, early on, that I'm sure we will get into potentially in a bit more detail later. But the day-to-day is essentially a mix of hands-on coaching with founders or teams where they have product ownership, where we take them through the product coaching framework. It's also getting our hands dirty and actually doing some of the product management work if needed, especially products that are maybe a little bit in the beginning. And it's facilitating workshops, it's showing best practices. It is mostly what you would see senior or lead product people do within companies anyway. But more focused on actually building businesses as well. That means you are fully focused on the early stage development of the products and of the team, right? Yes, more or less. Everything that Founders Factory does is seed stage, so from our early seeds. And then hopefully when they have graduated the program for a year or so, they would probably go for a Series A. But I would say the majority of the companies that are within our programs at any given time would be at seed stage, yeah. I hear quite often the question from product leads and heads and product people in general, how does the whole process look like from having an idea to going live with it? Yeah. How do you think about that? Well, it's a million-dollar question, right? Because I think that everyone is looking for the recipe, but essentially it's not necessarily as easy as that. I think... For recipes, you have the product bakery now. That's why I'm asking. Yeah, exactly. We're trying to get as many bakery metaphors in as possible. Put the money out, we just focus on the recipe. Exactly. I think that I can tell you what we do in terms of what I think is most important that I think is potentially useful for people to listen. As with any product development process, it's always important to focus on the learning, obviously. Early on in a product, that's probably even more important because you have less resources, you have probably less budget, et cetera. So you really need to focus on getting as most value out of as little as possible. And really focusing on getting to know your customers, the people that you're building for as much as possible. And that includes not always being successful. So that includes showing people and customers things that you naturally probably aren't going to be able to have built and probably are going to revert. I'm a big proponent of hypothesis-driven development as well for a couple of reasons. One, I think it focuses people and teams to construct a problem in a very succinct way. It's also naturally you can only disprove on hypothesis as well. So that lends itself easier for people to think that actually this might not work and hence get more learnings from that. So if I were to draw a straw man from idea to something going live, I think that the idea stage, I think that what's important is to give as much creativity room as possible, really expand what is possible and what is not possible. And then I would probably start thinking about using, when the idea has crystallized a bit, I would probably suggest to do some sort of like canvas exercise where you can either use like a business model canvas or like your own version of the canvas, depending on what you're familiar with. But just so that you can see the idea, not just as a concept, but as like a, what are the different parts and what is important. And from that generates like hypothesis on what is, what is the most, what do we know the least about here? And like, where is the most important to start? Probably some sort of prioritization of that. And then moving into a sort of like more iterative process where you build something, you learn something, and then you iterate moving forward, working towards having. in something that is probably very hacky in the beginning, more prototype. So if you then have a set of hypotheses that you're, that you tested or want to test, you can move into a more build that measure, learn type process, focusing on. What is the smallest thing that you can build to learn? And I think depending on what industry you're in and what you're focusing on this, or if you're a B2B or B2C that can be like different things and different. I don't think that there is a recipe for what is the right test, et cetera, but utilize as much as you can, even if that's like something, no code, if that is surveys, if that's doing loads of interviews, just anything that makes you, that puts you in front of the customers as much as possible. One thing that is always interesting to me, or that I also get sometimes as feedback from clients is how and when can you actually show something to customers in terms of, I see a lot of people being afraid that ideas might get stolen if you launch something too soon, or if let's imagine you're still in a prototype kind of phase and you would landing page test something. So you, you actually show people your idea before you build it. What's the best timing? I guess there is two different, there's always that scare, I guess, for me, I think that an idea in itself has very little value. So I think that as early as possible is always my answer, to be honest. I have yet in the 10 years I have done this yet seen an actual idea getting stolen. So I don't know really what that like notion actually came from, but you will have the, you will already have the leverage anyway, and I think that if that is an excuse not to talk to customers or prolong to talk to customers, what I would say is, I would say weighted up with, with the risk of not talking to them and building in a vacuum where you, they might, you might be spending money and building something and then the, your customers won't, won't like it. So if that is a risk of you, if that is something that you're really considering, then do a, do a risk analysis on like what it would be if you didn't do it. It's the blunt answer. Yeah. Yeah. I think it's, it's always hard to answer it because there is some entrepreneurs simply have this fear of, or they see the value as very expensive. But I think usually, as you say, ideas are cheap. It's probably anyway, something that many already built. So you can simply launch it and, or get it into the hands of the users. So yeah, absolutely. Yeah. But there's a lot of time. Yeah. I think that a lot of times people forget that products and services are also the, sometimes like the same thing. So not everything that you present, like when you're trying to, when you're trying to learn something, you can make it as small or as big as you want. You don't have to show the entire pitch deck to someone or like your entire plan. It could be like as miniscule as you're trying to figure out how someone would interact with a very specific part of your product, you can do that in isolation without having to, without giving everyone the big context at times. So if you are feeling a bit apprehensive about that, you can break it down and do it in small chunks, and then I think it's also very hard, even if you sit in on an interview or if you're listening to someone's idea, I think it's really hard to even then get like the full understanding of what the services that this person is trying to build and what the vision is for it. So yeah, there really isn't like many. I don't think that there were, I can see why it would be where people should be thinking about protecting their ideas, of course, but I don't see it as a reason for not talking to your customers. Yeah, I think it's just getting it out, getting it out as early as possible. Done is better than perfect. Yeah. And ideally you even, I love the idea of not only getting early feedback, but even getting early signups, put them on a list and they're interested in, and maybe it's a first sale that you... Also getting early ideas, how you can make it better. Yeah, yeah, absolutely. When I have an idea and start talking to people, then I realize, wow, there are so many more crazy things you can do. And without a conversation, I would never have thought about it. Yeah, no, I think that there's a lot of people taking after what good companies are doing, good products are doing these days around like what you said, Christian, around like building this community of early users to get feedback or doing something crazy like superhuman and having a very strict onboarding process, but they ensure that someone is using the product as they intended. The last thing I want to mention in terms of zero to one, which is sometimes overlooked is really thinking about building your first team and who do you want to have around you that you think can execute on and really build like a business for you? Cause I think that there is quite a lot of focus all the time around building the right product, building it in the right way and building it for the customer, et cetera, but you're also building a business and a company. So really try and think about who are the people that I want to have around me, who's going to help me grow this business and for us to grow this, for us to grow this company, because regardless of how many good ideas you have or how good you are at executing yourself on that, if you hire wrong, or if you think if you're not really thinking about the team early on, you're going to lose a lot of momentum. I was just about to ask regarding zero to one. So let's say you have a motivated CEO with a spec idea that makes sense to start working on. How do you step in your role to empower them or to help them to build a business and to hire the first, for example, product manager and establish a product and engineering mindset within a company? Because we see many companies out there who are maybe very sales driven or very engineering driven, but on the other hand, not product driven enough or vice versa. So how do you find the balance and how do you support founders with that? Yeah. So at Foundry Sector, we try and find, we try and find for each of the projects in the studio that we're building, we're trying to look at what is the best archetype at that given point to be like the founder or the CEO or the co-founding team, et cetera. Sometimes it's, sometimes we think it would be good if they had a product or engineering experience. And sometimes we think they will be better if they had more of a sales and commercial experience. Either way, in order for us to get to, in order, the way I think about instilling good product thinking and product coaching is to empowering founders to see what good looks like and to be able to be part of that journey. So early on, we will probably be a little bit more hands-on and showing best practices and probably like executing on some of that product management stuff, setting up the process, doing a lot of, doing a lot of the heavy lifting. With the founder always present with the idea that they would take over the ownership of the products at some point to be able to like, if they want to go down that route of being the founder with the product ownership, they can, they, we will then equip them with the tools that they can, or if they want to hire someone, then at least they know what they're looking for. Cause what people forget is that product is such a nuanced world. There's so many people with so many different experiences and there's not really like one definition from it, like for exactly what it is. I think we're still evolving that craft of what it really means to be a good product person. So taking someone through that journey of what we think is important for you and what we believe is going to be important for you for the, like maybe for the next couple of years, really helps like inform that person, like when they're going to do that hire, do I want someone with a bit more technical experience? Do I want someone who has a bit more design focus? Do I want someone who has done that before? I mean, there's many, there's many ways that you can, we also help in the hiring process of the first product people as well, but I've seen so many mishires of product people before and even before Founders Factory, people who've needed hire to be, and potentially someone who would like, for example, that on paper might have looked really good, maybe been in like, been in like a big company at, let's say like an Uber when they were late to stage and has a lot of experience running, like maybe a big engineering team and coming and working at a startup and then being a bit of a mismatch or hiring to junior early on potentially. So yeah, so it's getting them to understand and feeling that they really do understand what it is that they're looking for and the coaching framework really helps with that. As a founder, what should I invest in first? Should it be a strong product leader or should it be someone really hands-on who I can throw into the dirt and get the work done? I'm going to give you the most product answer ever, which is the, it probably depends, but okay, but I can give you it from my point of view. You're dead a lot. I'll give it to you from my point of view and if it was me, and then we can, I guess we can extrapolate to see if that makes sense. So if it was me, and even if I was a founder and I decided I wanted to be the CEO, I would still want someone who is equally comfortable in the execution of product management, as well as being a strategic thinker, if that makes sense. And I would probably look for someone who had maybe not necessarily been in a startup before, but someone who can explain the process of taking an idea and a product or a feature to market in a very succinct way, and I've done that a few times, I would also look for, and I would look for probably for that profile in the other disciplines that I'm looking for as well. So engineering and design, et cetera. Some people who are like equally comfortable with strategic thinking. and comfortable in contributing to the direction of the company, as well as like, at some point, like push pushing pixels or writing Jira tickets. And it's hard because not a lot if you a lot of product people when they reach a certain time in their career that don't want to do they don't want to sit down and write like, or do story mapping or things like that again, they want to maybe run why not run a team. Exactly. Christian would always want to do story mapping like his whole life is about story map. Yeah. That's fine. I think a lot of great senior product people are great product managers and are happy like being great managing of other products of other product managers. And that's perfectly fine. Early on, though, I would pick someone who's comfortable in a little bit of both. And you mentioned mishires. What would you say are like the red flags when hiring a product manager? When should I stop? Right. For early stage, let's say early stage and mid level product managers. Yeah, mid level. Yeah. So I think that yeah, I think with red flags, I it is such a big difference. And I don't want to discourage anyone from thinking that they can't do the jump from a big corporate to a startup. But I think there is a very big difference between working in a product management environment in a big corporate and being the only product person or maybe the first product person in a startup. So I'm not necessarily saying it's a red flag, but I would, I would really try and dig deep into do they actually understand what it is, what it would take to be the only product person, you're not going to have a mentor. You might not, you might having to do like loads of different things and not just the core of your job. You're probably not going to have a big team of, of engineers around you that can help, that can help. You might want to have, you might have to do quite a lot of decisions on your own. And the other important thing here as well is that something that bigger companies are used to that early stage aren't used to is data. Being comfortable in making decisions. And if you can't make a decision based on data, then how do you get to a point where you can feel more comfortable in the decisions you're making? And that skillset is also like a little bit different than if you like have like endless amount of data, if you're a product manager at Google or Facebook, for example. Other red flags that I have personally, just because of the nature of the ever-changing landscape of working in a startup is product people being a little bit too dogmatic about their own processes. It's good to have a backbone that you like, this is where I feel comfortable with. But I would always question people who be like, this is, without even knowing what the problem is, it's like applying, say, oh, we're definitely going to do Scrum or we're definitely going to do Kanban or et cetera, and feeling a bit rigid in that. But that is a personal preference just from seeing what has been worked and not worked. For me, product is a lot more like you're applying different tools depending on like the situation rather than it being like a one process for everything. And this is the same like when you say I am Agile, right? I am Agile means everything and nothing. Understanding the mindset behind it or the philosophy is what many people heard just recently from an engineering manager from Urbi saying that it's easy to call it Agile or it's easy to say I want to start with Agile, but it's way harder to implement it and make it work. But I think it's even a little bit this problem that maybe also some certificates introduced, it's so easy to be Agile certificate, Scrum master, whatsoever. And I see those people coming in companies and they have, as you say, they follow certain frameworks strictly, they have no flexibility and they think they're doing it because they've heard it, learned it, and so on. But I think it's just such a more flexible kind of working style that's needed when you work on a product, especially in an early startup where you don't have the structure that you might have at Google and Facebook and whatsoever. When we talk about processes, how do you set up product processes, especially in early stage? Let's say there is right now a founder and a couple of engineers who just want to get started. And as long as you don't have the money or the priority to hire a product manager, you need to do it by yourself. How do you set up a product slash engineering process in early stage companies? Firstly, you have a very clear vision of where you want to go. So that could be a vision for the company, it could be a vision for the product, or have a clear vision of what do you think that the first version of your product is, work backwards from that and think about how much you want to learn along the way and build out a process based on how quickly you actually do think that you can move. And it could be as easy as just like setting up fortnightly sprints and doing daily standup that you can do well. And going from zero to one, you could potentially take away stuff like having, like thinking about your velocity, et cetera, because during a three months time, like if you're going, if you're building your very first product, getting to that sense of velocity is less important, but knowing that you're learning and that you're doing the right things is more important. Something that does that, there is a lot of good tools out there, continuous discovery and things like that we're big proponents of at Founders Factory as well. So think of constantly learning. So I think like an initial process should be starting with, starting with your vision, how and when you want to get there, what is important to learn along the way and set up something from that. Recently, I had a second look at Basecamp's book, Shape Up, I don't know if you're familiar, which has some really cool elements in that, which we've tried out with some projects at Founders Factory. I'm excited to get a bit more learnings in that, but since we're geeking out, I might as well share now. But what I find interesting is that I really liked the idea of not having a backlog or deleting a backlog completely, because I just think that like long list makes everyone stressed. So what I really liked about that, when I went back to it and when I went back reading it and started thinking about it more from like the context of like very early stage, zero to one at Founders Factory, I was like, well, this makes quite a lot of sense if you either break it down in terms of, okay, so what you could imagine and what hypothesis are we pitching that are most important to learn? What is the length of time that we want to work in? Do we want to work in three weeks? They suggest six weeks. We have tried a few smaller ones and it really creates focus for teams. So this is the one thing that we are building and releasing potentially or what we're learning during this time period to creating tasks around that pitch and like what we think the problem is to solve. After the period of time, delete and apply for new pitches. And then you discuss as a team on what's important next time based on those learnings. Yeah, I really liked that. And by default, you have created an agile process just by thinking about what is the most important thing to learn during this time and then moving on to something else based on those learnings. If you have stuff in your backlog, which hasn't been tackled already since three, four or five months, then it's very likely that you won't tackle it in the next week as well. So that's all by mouth. I would say. Yeah, I would say three or four, five weeks, even. You could probably already delete that. I agree, yeah. I mean, you can't even go that far. Everything which is more than three sprints, I usually say, which is six weeks, just delete it. I mean, for sure, if you are an enterprise business company and you have bug ticker where people have paid money for a fix or companies have paid for a fix, for sure, you can prioritize it accordingly, but you have any way longer and slower release cycles than in a startup. So therefore my recommendation is if you are flexible enough, shorten your backlog as soon as possible. Close everything which is older then and then put in your time. We should just have a plugin for Jira that simply sweeps everything that's old. And it doesn't secretly, so you don't even notice and it phases out into this. Getting rich with Jira plugin is so easy these days, really. You just build a plugin, you charge people for, I don't know, a hundred bucks for a hundred users and the more users they have, the more it costs. But we don't show that on the app store. We just show a hundred bucks and then you're a big enterprise company, you click the button. You're one step ahead. We're not thinking about monetization here. We just want to have this plugin that silently cleans up every single bug. I want a win, Alex. I wonder what the data is. I wonder if Atlassian would ever share the data of the amount of finished tickets versus unfinished tickets in Jira, like at any given point in time. It would be interesting to know. Yeah. Maybe we should apply as data scientists. I mean, I think the data Atlassian has on understanding how companies build products and how their products look like said, this must be amazing. Just writing a book about it and rethinking. Rethinking Scrum. Let's imagine you have started your company and you started your business, but you don't have data. And for sure it's good to talk to customers, but how can I nail that down as the first PM or the first product lead in the company to really make database decisions? Yeah. So I talked to a product person the other day who put it quite simply and said that there is always data. You might not have as simple access to it as before. You might have nothing in your database, but the data is there for you to collect it somehow. And I think that the first step, if you're in a place, and I think that the people get obsessed with the collection of data, but again, I want to stress that the data is only important if you know what you're learning. So Always start with what it is that you want to learn and create a simple test for yourself or an experiment for yourself to get an understanding of what that learning is. And you start in collecting data. If your test is, if your experiment is like running some landing page ads to attract like an initial waiting list, for example, like you have, you can have some hypothesis around who you might attract and match that. If you're doing like more of a customer discovery piece, you could have an hypothesis around how they would feel about different value propositions of the product. You could talk to them, you can do more quality breaches, then that's data. And then you like, you obviously refine it, it becomes more quantitative all the time. But I think work backwards from what it is that you're thinking that you need to learn. I think the simple top down or bottom up analysis can sometimes be so helpful now by just starting with, I don't know, you want to start selling bread in New York and making this croissants in New York. You wanted to hear a croissant example, Sebastian. Now you get it. But let's say you want to sell croissants in New York. Does that make sense? So you check how many people living in the hood where you want to open your store. You check out what the average consumption of bread and stuff like that is in this area. You can break that down. So you can also generate data by using common sense, by breaking things top down or bottom up and then making your conclusion, which is for sure not the most professional way. If you, but if you just want to get started with it, you have at least some data points you can make use of and that give you a direction you can work towards. Exactly. And I think that the key there is direction because I think that, and that's another, I guess, the difference between having a conclusive data set versus what you're actually looking for is signals. So another thing that we, that I stress teams doing early on is that when you're creating these experiments or like when you're testing these hypotheses, try for you guys as a team to decide on what an expected result could be. So not just like deciding what the test would be, but also deciding what the, what the expected results before you do the experiment. So for example, if you take your, what you said, Christian, let's say that the experiment is that we want to try and figure out if people would want to purchase croissants in Brooklyn, in New York on this specific street or whatever it is. Maybe your suggestion is on Baker Street. Oh my God. It took me quite some time to actually get this joke. Yeah, it's good. Far too long, Jesus Christ. That's good. I like it. Let's say it's on Baker Street and maybe your suggestion of an experiment is, okay, before we open the store, I want to create like a, I want to create like a landing page. I want to make it seem like that we are opening and I want to see if I can get people in that area excited about the business that I'm opening somehow. Maybe that's you going there and creating like little flyers and putting in people. And then maybe there is like a little like code that they sign in for saying, Oh, this is exciting. Maybe it's a landing page. Maybe it's doing like a pop-up or like a prototype. Maybe you just go and sell croissants directly to people's houses, COVID friendly, obviously. Whatever the experiment is that we have decided is the lightest experiment that we can run in order to get the learning that we're looking for. And for us as a team to decide, okay, what would good look like from this experiment? Like, what is the, what would a good signal be for us to be able to decide, yes, this is now, we have now, this is now something that we believe in and we can continue it in the further in the product development process. Cause it also creates a bit of like alignment in the team. Because it could be that Christian goes away and does the experiments, for example, and he comes back and say, Hey, I talked to 40 Brooklynites and 20 of them were super excited and pre-ordered for four croissants each, and me and Alex go, that's just 50%. Like we wanted at least, we want at least 35 out of 40, you see what I mean? And then what do you do? So the hypothesis also needs to be measurable, you're saying. So the moment you start the experiment, you have, you should have some clear criteria in place. They need to be matched to say, Hey, it's proven or disproven. Yeah. And also an alignment piece of there in the team is, it's important that we have an understanding of what we think good looks like, because even if it's disproven afterwards, or even if it's like, doesn't come to the expected result, we can at least decide, we can at least discuss around it. So even if it's like, Oh, it was only, we only got to X and we expected Y, we can say actually looking at all the different things and seeing, we still feel based on this result, we still feel quite comfortable that this is all right, or it's not, or we want to do another test, whatever it is. Cool. But so Sebastian, before we try and slowly wrap it up, there's one thing that I'm still curious about, which is when starting or when going from zero to one, what are the people that I need to have a successful team? Should I start with some engineers in place to be able to build it? Or should I fake it with some envisioned prototypes? Or what's the best suggestion? Yeah. So I would, I wouldn't necessarily say that I would build it from the start. I think you can start with loads of prototyping, et cetera. However, I do think that if you're not technical yourself, having engineer and someone like even if that's an advisor, or if it's a friend, having someone that you can lean on for those conversations early on is really useful. I think as much as possible, have a cross-functional team. And I think that is one of the reasons why people get so excited when they join Founders Factory, because that's exactly what you get. Like you get access to people that you might not necessarily know, like experts in their fields, but I would suggest that people try and emulate that even if they don't have the budget to have someone that they can talk to on the design front, on the product front, on the engineering front, maybe even on the marketing and growth front, or sales, like people that you can trust on that are in their field that you can discuss the ideas with and how you move forward before you hire your own team. And the reason for that is that the people with different experience have different opinions. And you could, even if you're not building something directly, if we take the engineering example, you could, what you, having someone there that you can discuss with and talk to, you can de-scope so much stuff that you might do in the future, right? You will get a better understanding, like further down the line, okay, what is potentially possible and not possible and what is potentially the best path to move forward. So I would always try and have as much of that input as possible early on. All right. Then I would say we can wrap it up. Two questions. I have two more questions, Sebastian. So number one would be, what would be three key tips you would share to aspiring CEOs or early stage product managers? Three tips. Three of your personal favorite tips when you get started with product. Okay. My, okay. So let's not beat, let's try and not be too vague though. Yeah. Three personal tips. I would suggest that read either of these three books. That was my second question. I want to ask which book would you recommend? Okay, cool. Okay, cool. You can edit this later and then you can, we can go back to that. We can go back to the second question then. Okay, cool. So tips that I would, that I would give is, it sounds vague, but being uncomfortable with uncertainty is definitely like a big one that you most likely are going to fail in 90% of the things that you try early on. And that is great because that is learning and that will help you go in the right way. And as part of that, I think that if you are the first product manager in a startup and you're new to that role, or if you're CEO and you're building something else, talk to as many people who are in a similar situation or has been in that similar situation before. Maybe even get like a product advisor or a, or if you're a product person, maybe like a mentor who, someone that you can reach out to. I think that our community is so friendly that I think that if you find someone that you really look up to, people want to give their time. So I think I would definitely do that. And then another thing that I like doing, and I tell other product people to do as well is, is really try and build something yourself. And with that, what I mean is if you are the only product person, or if you are the CEO in early on, see how far you can get on your own so that you really get to grip some, like the different parts of your business, learn, maybe go in and learn, like envision and see like a prototype. Take a pen and paper and sketch out and go to talk to customers yourself and don't lean into other people to talk to and see, and then see how you can also like expand on what it is that, okay. So this is my comfort zone. This is where, how far I can get this and then move on from there. Cause you get a little better understanding of, okay, cool. If I really need to do this myself, then how far can I get? Yeah. Is that free? Let's go with that. Yeah. I like this one a lot because not only that, to see how far you can go. On the other hand, also doing all those things, you will appreciate way more the help from other people. The moment you start hiring, I think it's, it's also about the empathy, right? Because you start building empathy with the different roles. And I think that's, that's, that's the one thing that they usually also tell designers have the empathy for the developer, for the product person and for whoever is the CEO of the company and understand why they're saying, why they're doing things and where they're coming from. And this is such a key thing. If you once did it yourself and you have a little bit understanding of how far you can things work, then this helps you a lot. Yeah. I mean, that is the two. Yeah, sorry. Go for it. Now I was going to say, I was just going to finish and I think it's, I think it's, that is a hundred percent correct. And I think that uncertainty and empathy and resilience are the three main pillars on the coaching framework, which Christian knows as well. And I think we have talked about, go through it. And, but yeah, so definitely when it comes to building empathy, it's really hard to get, unless you're in, unless you really try and be in someone else's shoes, including customers. Yeah. Question number two, which book would you recommend? What's your favorite book for product leaders or CEOs to read? And please don't say zero to one. No, it's not zero to one, even though that's the one thing that we talked about. All right. Can I have two? Sure, please. The more the better. Okay. Okay. I might have, okay, there might be more than, everyone has read Martin Kagan, which is a fantastic book. And it's still the one that I tell everyone who's asking about, who's new to product, who's asking about what product management really means, that is the book to go. I do think that if you're looking for some, if you're looking for a book with a lot more practical advice, Melissa Perry's Escaping the Build Trap is excellent. It's really good. If you want books that I think have helped me in terms, but it's not necessarily like filed on the product management and thinking fast and slow. It's by Daniel Kahneman, just because I think that in terms of the, there is a lot of, it's a lot of things that we can, that product people can learn from like the behavioral economics and behavioral psychology space, and that book is excellent, and recently I read a book that I am, that I think is going to be really helpful. And I think a lot of people might find helpful as well, which is Never Split the Difference. Oh yeah, that'd be a good book. Yeah, yeah, exactly. And he, and it's, yeah, it's just, I think that sometimes we underestimate the power of negotiation, how important negotiation is in our role. And it really, it was really eyeopening for me because like a lot of the tips that he gives is, is the complete opposite to what I thought negotiation was. It's super practical. So, so many good insights. And on top of that, I recommend reading Getting to Yes as well. Oh yeah, which is the book that he references a lot, right? Never Split the Difference talks about it. They are not the biggest fan of the philosophy from Getting to Yes, but I still recommend doing this and finding your own style and you can negotiate everything, is the third book. I read all this free, one after the other, and I can tell you my negotiation skills were boosted. I feel like this is becoming like a book club kind of show now. Yeah, we can add the links to, also to the, to the description. But Sebastian, it was a pleasure talking to you. One final thing, where can people follow and find you on the internet? On the internet. Yeah. So they can find me at AdSubSub on Twitter. That's probably the easiest thing. Nice. We will do that. For a shameless plug. Yeah. Hashtag no advertisement here. We'll make sure to put everything in the description as well. And cool. Exactly. All right, Sebastian. Thank you very much for the insights. Alex and I will, as usual, jump now into our debrief and looking forward to talking to you again, Sebastian. Welcome back, Christian. Another debrief round after another great session. I have to say, just summarizing a little bit for the audience today, we actually changed some things in terms of like constantly iterating and trying to improve how we do things. So we both upgraded to some microphones. I have to admit, I still need to get used to it and talk in the right direction and don't move around in case that's something you might hear still need to get used to it. But yeah, also on this side, always happy to get some feedback here. If we need to improve something, we still have our email address. It's the hello at product bakery.com. But with that said, yes, thank you. Hello at product-bakery.com with that said, Christian, back to you. What's your summary or how do you feel about it? Or how do you feel after the talk? How I feel is that the topic of hypothesis driven development and also research as well as data in general is something we touched now a couple of times in our episodes and with other people, but this time I really liked how Sebastian deals with uncertainty by saying you're not necessarily looking for the answer, but you're looking for signals and direction by taking a couple of hypothesis and trying to iterate on them as quick as possible and still having uncertainty in place, but seeing a kind of signal that guides you in a direction where you feel comfortable enough to execute upon. This is something that I think people usually underestimate because they think too complex and too big, but it's really good sometimes to go the easy way and say, Hey, I don't have necessarily all the data I want, or I could potentially get in 20 years, but I just take what I have, I formulate a couple of hypothesis and as Niki last time said as well, I define some goals with it that I know how to measure and what does good mean, as Seb said. I wanted to say that Sebastian also brought that up. How about you? I think it definitely also got that one as a reminder and it just also closes a little bit, the loop between the different functions. If we talk about coming up with a hypothesis and validating them, this is what research is about. So it's simply again, highlighting the importance of researching the product in the product development phase or in product development in general. One thing that I wanted to bring up again, because it was only a small note in what Sebastian was saying, and it's about hiring product managers for all the new or soon to be product managers that are looking for a job. One thing that was interesting to me is when Sebastian talked about coming from big companies and not having the data. And I think there might be this, and I think that especially junior product managers, when they interview for a company, they obviously know about best practices and what's important. And there is probably many people who would raise exactly like wanting to have the data, who would raise following like strict processes. And this is exactly the opposite of what Sebastian said. It's about also being flexible, sticking to the uncertainties, knowing that you won't have all the data in early startups. So if you want to land your job, make sure that is your mindset and make sure that you're also fully aware when you move into such a company and when you work zero to one, you won't have everything in place, you won't be able to follow the super perfect process right away. It will be something that needs to be established. It is something that needs time and it's something that needs flexibility. And if I would go back into my old interviews, probably too often, I also tried to sell myself too much along the lines of knowing the best practices and maybe forcing them or trying to force them into some companies. I do have to say, I haven't considered this big company, small company distinction since a long time when I was hiring, because I believe that product managers generally should be pragmatic when it comes to dealing with your environment, your processes, your teams, et cetera, nevertheless, it's definitely something you should consider when you, A, look for a job as someone in a big or a small company or vice versa. And also from the other point of view, by being a company hiring people. What I want to say is that both is great to start a career. So you can go into a big company and you will be from day one in a very structured environment where you can, for example, work in best practices, set up processes, be process driven and data driven. On the other hand, you are really hands-on. You are touching all different types of the system. You're working across all departments. So both can make you a good product manager. It's important for people to figure out what you want to do. Absolutely. If you're more comfortable in a fast changing environment, or you rather want to work in a structured environment. Yeah, it's definitely not about the experience that you have. And Sebastian pointed this out as well. Like you can hire people from big companies. I think it's a mindset thing, and it's not only important for the company who's hiring, it's also important for the person who's looking for a job. Because if you land your job with the expectation that you have a data analyst sitting there, that you have a massive data warehouse behind you and a lot of business intelligence that you can rely on, and then you're sitting there as the first solo product manager, and maybe have a designer and a couple of engineers, and you have a leadership team that expects you to deliver, good luck. I think it's also about understanding what you want to do, again, for both sides. Understanding who you're looking for, understanding what you want to do, having the right mindset for it, being fully conscious of what you will get, and yeah, yeah, and then enjoying the ride. And every ride is fun, and in your career, you should definitely make all the experiences. Great final words, Alex. One more little thing to share with our audience. You can also slowly start following us on social media. If you look up the Product Bakery Show on LinkedIn, we share our posts or drop a couple of comments. We're happy to interact with you, and also, you can, anytime, reach out to Alex and myself on LinkedIn. And with that, thank you very much, and talking to you next week. Yeah. Enjoy the weekend.