How To Harness A Founder Mindset Within An Established Company (with Brendan Fortune)

Read The Transcript:

We’re trying out transcribing our podcasts using a software program. Please forgive any typos as the bot isn’t correct 100% of the time.

Hannah Clark: Honest question; which gig do you think is harder—being the founder of a startup, or being the first PM at that founder startup? I think you could make a case for either one depending on your past experience. So while that question might be a bit subjective, I think we can agree that both roles are deeply invested in the success of a product. But here's the rub; success of a PM is also tied to their ability to earn and keep the trust of leadership. And if you want a founder to trust you, you might need to start thinking like a founder. 

My guest today is Brendan Fortune, Chief of Staff at Customer.io. Throughout his career, Brendan has seen firsthand how adopting a founder mindset is a major boon for product managers, especially in a zero-to-one context. In a moment, you'll hear him share some great insights on managing tensions versus solving problems, failing fast (as well as his favorite failures), AND the most emotional moment of the zero-to-one journey. Let's jump in. 

Welcome back to The Product Manager podcast. 

Brendan, thank you for being here with us today. How are you doing? 

Brendan Fortune: I'm doing great. Thanks Hannah for having me. 

Hannah Clark: So can you tell us a little bit about your background and how you ended up where you are at Customer.io?

Brendan Fortune: I'm always fascinated to hear people's stories because they usually stop at the part where they make a transition to product. So I'll try and spell mine out.

I started in IT support when I was in college in Los Angeles. And then after graduation, I just lucked out. I was headhunted by some recruiter I had never met to slave away at a 150 person startup in the voice-over IP space. Very technical. So I was tech support there. And then at night I was writing film music because I still had my big Hollywood dream.

And over time, I realized film music was much healthier for me as a hobby than as a job. So I stopped that. I got into a fully employed MBA program and for anyone who hasn't heard of those, I had never heard of them. It's like a part time thing. You have a full time job and then you also go to school, takes three years.

And that's where I learned about product management is this combination of tech skills and creativity and leadership that was really exciting. So I used the MBA as leverage to get a junior product manager position at the company that I had worked at already for four years in tech support and then I got into IT.

That was tricky. That was hard. I, they didn't want to give it to me at first. Probably they were right, but I ended up doing the job anyway, luckily. And then a few months later I was able to get it. And from there on, I left that company as director of product. I did a stint over at GoDaddy in their hosting department.

Then I worked at Drip, which is a marketing automation, SaaS platform. And now I'm at Customer.io. Started in product and now as chief of staff, my job is to create the organizational systems that help the engineering product and design leaders do their best work. Whatever that may mean. There's so many different things there, so. 

Hannah Clark: So today we're going to be focusing on the founder mindset and what that looks like within the constraints of an established company. It's a very different ball game than for a startup. 

First, let's frame our topic a little bit. So how would you define a founder mindset if you were to kind of sum it up and what does that look like in action to you?

Brendan Fortune: I think this is a really fun one because it's almost like for me, sometimes it's threatening to hear this like founder mindset where I'm like, I've never founded my own company. Well, does that mean I can have a founder mindset? Is there something wrong with me?

Like, why haven't I done that if I'm trying to build products? But as I've worked within four founders over the years, I've come to see it really differently. To me, a founder mindset means a bias toward creating your own thing versus following someone else's thing. And that could be a new product that you're creating, it could be a new philosophy. 

It could be a new management approach. It really could be anything. But the defining behavior is when you're faced with a challenge, is your instinct to create your way out of it? Or is it to look for answers outside of yourself? And I think the founder mindset is that create your way out of it, which doesn't mean you ignore everything else that anyone has said and just make it yourself, but it means that you're inherently skeptical of other materials, other ideas that are out there unless you've really deeply understand them.

So that's what founder mindset means to me, and I can think of a few examples of how that could be applied. Let's see. Let me think of a product related one since this is a Product Manager podcast. When I was hired at GoDaddy, I was told by the leadership team like, hey, we need you to go and build us a cloud hosting product.

And this was in the relatively early days of Amazon Web Services. I think Google had just gotten into the game. And GoDaddy thought, Hey, we've got a shot at this. So they told me, like, that's what you're supposed to do. And three months later, I came back and said, like, no, that's not the right idea for the business.

And instead, we should develop a managed services business on top of Amazon Web Services, which was a pretty contentious plan at the time. And I remember when I was talking with some peers and bosses there, there was this kind of sense of like, oh, wait, but you're not supposed to be doing that. Like, what are the political ramifications of it?

And I think the founder mindset there is you try and say as much as possible what you actually believe in versus what you think might be right or someone else thinks is right if you don't fully understand it. This applies in a couple other ways to one of my favorites, just because it's really nerdy, is an operations example from my time as chief of staff. We have a process at Customer.io where our customer facing teams like tech support or customer success or sales or whatever, they need to either ask questions or escalate issues to the engineering product and design department. Bugs or whatever it is.

And for the longest time, we had a process where like a human would go in and create a ticket and then an engineering manager would look through the tickets and then decide which squad to put it on. And then it just was a very toilsome process. Sometimes the tickets would stay there for an hour, sometimes like a day, depending on how busy people were.

And the decision was framed as either this human does it, either an engineering manager has to triage this stuff or another human does it, the tech support person, for example, they have to decide what squad does this belong to? Like, it has to get some sort of manual review. And I think another example of founder mindset is applying new technology.

So in this case, we applied a AI, very simple Zapier LLM bot. That would take the input of the ticket that was already created, look through it, pattern match it to one of several feature areas that belong to squads, and then just assign it, like it automatically did the whole thing. Almost all of our tickets are prioritized instantly that way, whereas before it used to take a long time.

It's another one of those things where like if you're presented a false dichotomy, like it's gotta work this way or that way, there's probably another way that it could work. And that's one of the things I think the founder mindset helps bring out. 

Hannah Clark: Yeah, I guess it's like an emphasis on resourcefulness and like, how can you achieve more with less or get creative with the solutions. I really believe in the idea that creativity is fed by constraints. So that kind of is like it's akin to that sort of mindset. 

Let's zoom in a bit and talk about a founder mindset as it applies to zero-to-one product projects. So what do you see as a core challenge the product manager would face when trying to build a completely new product?

Brendan Fortune: So I love this question. I'm just gonna flip the script a bit. I think one of the core challenges a PM faces in this case is actually overcoming the founder mindset, which is maybe counterintuitive because of course, if you're creating something new, you need to be thinking creatively like as with this founder mindset.

But I think there's a danger in the founder mindset that comes from this kind of sense of like, well, I created it, so I really own it. So like a question I'd ask is like, have you ever heard anyone talk about a project as their baby? If you have, I mean, there's a reason I think people do that because the ownership can feel that intimate like it's like a, it's a child and sometimes people say it jokingly, but at least in my experience, there's nothing really funny about it in some of these cases. 

I kind of think of it like, if you're coming in to do a zero-to-one kind of thing, and you're trying to figure out how to apply a founder's mindset while also really building a product with a team, which is the only way that I know how to do it, then you want to do everything that you can to, I guess to like share the parenting journey. I don't know if this analogy extends that far, but like we want to co parent or whatever the thing is like, it's really don't want to, there you go, just lean into it. So it takes a village. And so that I think is one of the core challenges. It's very easy to get sucked into like, I need to have the ideas.

I need to own this. I need to make all the decisions. And that ultimately leads to more failures, I think, than going at it with a team. So core challenge, going it alone. But when you're going on this kind of dangerous journey of zero-to-one, I think you need to get the right people on the bus from the beginning.

And that's a phrase that I'm borrowing from the book Good to Great by James Collins, which I still love. It's getting old now, but some really great wisdom in there. The concept is like, you don't actually need to know exactly where you're going, exactly what you're building, before you can know who you need on the journey with you, which is another one of these counterintuitive things, or at least it was to me.

Don't you need to be able to say, hey, join me on this thing. I need you to do this work. Isn't that like the responsible thing to do? But in this good, great book, and the concept of getting the right people on the bus. It's like, no, you need to know your strengths and your weaknesses and you need to find the people whose strengths counter your weaknesses as much as possible.

Like it's about the puzzle pieces clicking well together. And so I think that's the way to overcome some of the founder mindset or the ownership, like bias, like this is my baby. 

Hannah Clark: To sort of extend that parenting analogy. You want to find a partner. If you are parenting, you want to find a partner who has, you know, shares maybe some of the same values, but also a counteract some of your weaknesses and complements your strengths well. So yeah, I actually think that's a really good analogy to use. 

I'd like to dive into the idea of getting the right people on the bus a little bit more. Because I think this is something that it's easy to kind of come up with an abstraction of how we might apply that in real life. But in your experience, how do you assess who should be on the bus? Like how do you kind of assess those strengths and weaknesses?

Brendan Fortune: Maybe starting with some simple examples. Like, let's say this is a fairly common pattern. So let's say you're like a technical genius or you're a technical product manager or something, but when it comes to like storytelling and the charisma that really helps lead a team, you don't got that very common pattern.

And it's like, well, that's probably something that you should find. And this includes, especially includes building a new product, a company with an established one. Because the evangelism effort doesn't just extend to customers. We were trying to convince to buy this product. You also have to evangelize with all the people, especially the leadership in the actual company cause you're divesting people and energy and money to this effort. So you really need to have that. And if you know that that's not a skill that you have, that's an example of something that you would need to go look for and try and get someone on the bus. So a couple other examples, this has happened to me before.

If you're building a product or you're tasked to build a product that you don't really know much about, like you don't really understand the domain, the market, the customers yet, you better find someone who does or you better ask yourself if this is a good product for you to be managing for you to be creating from zero-to-one. Because that's I think one of the biggest risks is if you got someone in a leadership position who doesn't really understand who hasn't lived and breathed the space. It just takes a long time to live and breathe a space. I made the mistake of thinking I could pick that up quickly before and have failed.

Hannah Clark: Yeah, well, and I can only imagine the how heavily you might rely on user input and feedback and all the learning that you have to do to kind of get yourself to a base level of understanding in order to begin to understand the product. And I can see that as being a very capstone challenge for a lot of folks if they're in that position. 

I want to talk a little bit about failing fast. This is something that I think it's kind of like a catchphrase, almost like this idea of failing fast. A lot of team cultures kind of embrace the idea in concept, but we rarely really codify what that looks like. So, for example, how much time and effort do we really want to give an idea before we can say, yeah, this is a failure?

Or how do we even define failure? Or what do we even give individual contributors permission to say, I don't think this is working? Like, do people have that psychological safety? So what are some ways that you suggest adopting that fail fast culture and kind of the practical ways of managing that in a team?

Brendan Fortune: I love this question and it resonates with me when you kind of frame this like, well, yeah, people say this, but does it actually match what they practice or what they really believe? I think the concept of failing fast, there's some value in there, but the framing is usually, at least in my experience has been misleading.

It's easy to think fail fast means like, I could just fail as much as I want, or at least that's what I've experienced. Either that or the complete opposite, which is like fail fast, but there's no real expectation that that's okay. And the second you fail, then there's immediately a change. I think of one of Amazon's leadership principles here it's, and I think it's one of the more contentious ones, which is leaders are right a lot. And my brother worked at Amazon for a time. And I remember I was talking to him about it and he's like, that leadership principle is like BS. Like, no, you're supposed to empower your team. Like leaders aren't supposed to make the decisions.

Yeah. It's a slightly different conversation, but I think the concept of failing fast oftentimes actually means, you're right a lot. And yeah, you fail sometimes, but really, you succeed fast through failure to get there. I mean, that brings us to another topic you're talking about, which is like, how do you define success and how do you define failure? And I think it's a classic smart person question to ask, like, you know, the middle of the meeting, they're talking, okay, pitching this project. And then you're like, yeah, yeah, okay, this all sounds great. But what are your success metrics? Ooh, like now, okay. Well, that's a nail under the ground.

Yeah, exactly. And the thing is, like, it's a good question. That's a thought provoking question. And there should be some success metrics in mind. But sometimes there's an implication that you need to be able to define success metrics before you take any steps. And those success metrics should stay and they're the binary of like, okay, yes, this is a success or this is a failure.

And maybe that has worked somewhere. But for all the products that I've built zero-to-one, it's never once panned out that way. And I've got a kind of an interesting example that's fresh in my mind from customer. I know where I'm at now. We had a, the most recent product that we've been working on is called Customer IO Data Pipelines.

It's a customer data platform. And for anyone who hasn't heard of that, it's a single point of data integration for all of a company's data. So you pass all your customers data in there, like what's their name? Like what are the behaviors in the product? You put it all in one place. And then it's easy to send to all the different places you might want that data, like a CRM, like clothes or sales force or marketing automation, like Customer IO, Drip or anyway, stuff like that.

So when we started working on that project, which was about a year and a half ago, the success metrics that we planned were, we want to win business from competitors like CDP competitors and do that by having a lower priced product. So kind of betting on the commoditization of the CDP. We'll kind of start the race to the bottom.

We also wanted to generate double digit monthly recurring revenue off of net new customers that were only using this product. So we have our established marketing automation products. Now we've got the new one that we're adding on and we were like, no, we're going to get people that we're going to make it so good that they just pay us for that.

They don't even need to use the other thing related to that. We were like, okay, CFO, we're going to make enough money to pay for the team that we've asked for to build this product. So to kind of put that team on the line, six months after ship, guess how many of those success metrics we had met. 

Hannah Clark: I would either guess zero or like one.

Brendan Fortune: Yeah. Well, zero, maybe I led it strongly. Zero is exactly right, but we're not shutting the project down. So the question, well, why not? Is it sunk cost bias? Like, Oh, we put so much in it all. Let's just keep kind of playing this out. I don't know. Maybe we just need more time. It's not that. It's because even though we did not find success in those metrics, we found success in different metrics in unexpected places.

So, we found that customers that had never used a customer data platform before were the ones that were most successful in adopting. And we also saw the beginnings of a new economic flywheel. So we had priced the product the same way most CDPs are priced, which is by API call. And that's a variable pricing model.

More data you send in, ideally, the more value you get out of the product. And then the more we charge you as a result. And we've seen that the customers that are adopting are growing their usage month over month. Which is again, key to Customer IO's, economic flywheel. So, we didn't win competitors with the lower price.

We found out most folks that were already using competitors were like, yeah, I mean, that's fine. I can get a discount though. Wasn't a big deal. Basically zero traction there. We were much slower to growth. We were chasing revenue, but actually we should have been chasing this economic flywheel of growth, which will eventually turn into revenue.

Like we can see the projection there, but it's a slow build. It's not a fast build. And that's why the product has kept going. So I think if you're doing zero-to-one, be thoughtful about your success metrics, but expect them to evolve and sometimes to find success in different places. As long as you find success somewhere, the project should keep going. If you're really not finding success anywhere into that, that's when you've kind of hit that point of failure. 

Hannah Clark: That's really insightful. And I think that that's something that a lot of us can relate to across many areas of life, where the expectation that you have doesn't necessarily materialize as you expected. But it doesn't mean that there's not other value to come out of it, other milestones that you can hit that lead to further benefits down the line. So really interesting insights. 

So since we're talking about failures, I kind of want to put you on the hot seat a little bit. Little zoom out from just Customer IO, I'm curious about your favorite failure in your career that you think has led to the most value in your life.

Brendan Fortune: Yeah, that's a really interesting question. I almost want to say I have so many, but now I'm like, wait, I just said leaders are right a lot. Better not say that, but it's true. I have a lot of favorite mistakes or favorite failures.

The one that comes to mind first was at GoDaddy and that was a new product that we're trying to build called Enterprise WordPress. And it was a hosting product that was trying to help agencies like really big agencies, the kind of agencies that build out the websites for like ABC.com and stuff.

We're really trying to make a product that would scale for the amount of traffic that they wanted while maintaining the flexibility of WordPress, which is was more accessible to less technical people. And there were some existing products in the market that had been successful and we're like, okay, we got it.

We had great relationships with customers. We had like pilot folks set up at some of these agencies. We had all the relationships in place and then we worked on it for about nine months to a year and had a team of five or six, mostly engineers. And we shut the project down about a month or two after it launched.

And the reason is because we had built something that was literally dead on arrival. You could not promote from like a staging environment to production cleanly. We thought we were like super smart, like, hey, okay, we're going to make this thing super secure by like making it so that you can't actually change anything in production and you've got to go through this loop here and then it's going to be like a static.

Anyway, we thought we were so technically clever, and we were. But it turns out that the customers really had no interest in that and we hadn't validated it other than like telling them, hey, this is what we're thinking and getting some like head nods of like, yeah, yeah that's okay. It's like the mom test.

Like we fell straight into the mom test. What I learned out of that is, if you think you're clever, make sure you're clever. And also, if you don't have anyone on the team that doesn't have a lot of domain expertise, even if you've got some of these customer folks working with you, beware, like watch out. And we didn't have anyone, including me on the team that knew much about enterprise WordPress before we started working on it. 

Hannah Clark: For those who aren't familiar with the mom test, would you mind just giving a quick summation of how that works? It's kind of a funny trope at this point.

Brendan Fortune: The way I'd summarize it is if you're going and you're like, Hey, do you think this is great? And you're like asking a question to someone who really cares about you or kind of wants you to succeed like a, I guess, prototypical mom or parent, then you're probably going to get the answer that you're looking for. You're not going to get that honest feedback or that critical feedback that you might need to know if what you're building is something they're like, yeah, cool.

I support this versus like, oh, I'm going to put money down and pay for it. Big difference. Yeah. That's the mom test. 

Hannah Clark: I think it's so funny. You see this all the time with, especially, I think it's a culture thing as well. Some cultures and not so much, but definitely in North America, a lot of people are so socialized to be like, yeah, yeah, that's until then, you know, build something for them that they don't care for at all.

Brendan Fortune: Yes. Yeah. No kidding. This is maybe too much of a tangent, but this takes me to the radical candor conversation. This is another framework of Ken Scott's with ruinous empathy versus obnoxious aggression. Anyway, that's a whole interesting topic. But when I hear you talk about the culture, especially like in North America of like, wanting to be like, yeah, yeah, supporter, like not being direct with your critical feedback.

That's what I think about. Got to get the radical candor and it's totally counterculture. 

Hannah Clark: I'm actually okay with that tangent because I think radical candor is something that we are very enculturated not to engage in. But it's one of those things, especially on a product team, I can only imagine the thousands of dollars, probably millions of dollars that have been wasted because people have not practiced radical candor.

Brendan Fortune: Oh yeah. Billions. I think it's so, and all the companies that I've worked at, I can't say that I've ever worked at one that I think really nailed this. And I think part of the reason is, I think culture, first off is like attention to manage, not a problem to solve. So it's like, never goes away. You're never like, ah, yes, we got radical candor has now happened.

Now, like we've got this culture and we're gonna, we're just gonna rock it from here on out. It's super messy and that is not professional. So there's this kind of tug between like messiness and profound. I'll give you an example, like, when I'm trying to build trust with someone, right, kind of, I'm entering into this first like feedback moment, like with a colleague or something, like a new leader or whatever.

I often tell them something about like my own career aspirations because that's kind of a vulnerable thing to talk about. Like for like, you know, I'm really interested in this job. I'm not sure if I see a path for myself, whatever it happens to be, but trying to open up about something is risky and sometimes comes across as like politically calculating, which is the exact opposite of what you want when you're trying to establish trust. 

Because you need that trust in order to have radical candor rather than just, hey, I just tell you what I think and I just assume that I'm right and you need to hear it, which is, it's also toxic, just a different kind of toxic. So I think that's really messy. And I've worked for people that want to deescalate that stuff.

They see it and they're like, Ooh they're either talking about something. I'm not sure, like, if that is like risky or like, should they be sharing that or more commonly, Oh, they're fighting with each other. I know that they disagree ideologically about something, fail fast would be a potential one.

Like we need to iterate, you need to fail fast. And then you've got someone else who's like, no, we need to scale. We need to operate like we need a cadence. So when you see people kind of going at it that way, it can be easy to say, you know, stop the conflict, deescalate it, like as a manager, and then you've killed it.

Radical candor is gone. And you think you're helping, but radical candor is conflict. And we think about resolving conflict, not encouraging conflict in a healthy way. Conflict is risk and actually it's reward. 

Hannah Clark: Yeah. Conflict is an opportunity, really. We have a whole article about that, actually. You guys can check it out.

But anyway, so moving right along, I did want to kind of call back a little bit because you mentioned tensions to manage. And this is another framework. The tensions manage versus problems to solve that I would love to talk a little bit about because I think this is a really interesting idea. It's not always called the mind in the leadership context, but I think this is an important concept to digest because it applies to so many areas of people management.

Do you mind kind of like walking through that concept?

Brendan Fortune: Yeah, maybe I'll put a product manager lens on it for my own experience. When I started in product management, you're incentivized to ship things. These are problems that you solve for customers by shipping things. And then when you ship it, there is a sense of completion, a doneness.

Now, of course, there's still the scaling and the operations and stuff, but that you hit that moment of ship. And we work in tickets, like user stories or whatever the thing is. User stories get resolved. There's this kind of sequence of progress that you see. And so stepping into a broader impact role, like a people manager.

It's easy to adopt that same mindset, which is like, Oh, let me identify the problems and then I will ship solutions to them and they will go away. And that solution might be the way that I run my product manager team meeting, for example, like I'm going to have this agenda and ask for these things. And then the problem will be solved.

And the reality is because people are ever changing, even if you're not changing the membership of your team, the tension is ever changing. The problems are ever changing. There's always some sort of shift. On top of that, you're supposed to be growing your people, developing your people. So you want them to change and as they change, you're going to need to manage them differently.

And the solutions that you may have put together before and seen some promising results from are gone. So for me, it's been helpful to think of these as tensions to manage and just assume the second I've solved something, it's unsolved again. And stay in that generative mindset as much as possible, which can be exhausting, but we could tie this back to founder mindset.

Like if you like to create, Hey, this is perfect. The managing the tensions fits right into that founder mindset. That's what I think about when it comes to alignment building. That's what I think about when it comes to people management. Just be ready to adapt and try to create. There's no playbook you can apply that will save you from managing tension.

Hannah Clark: I absolutely love that idea because I think also sets you up as a people manager. Not to expect a resolution is a mindset that kind of enables you to manage your energy better when it comes to managing those tensions. 

On that same topic, actually, I was hoping we can dig in a little bit to the idea of alignment. You kind of mentioned it there. So I think everybody kind of has a different idea of what alignment actually means in a team context, but it's really critical. And as we kind of talked about throughout all of this, alignment is just so important to get right. So what are your tips for getting a team aligned on a major deliverable, like a brand new product?

Brendan Fortune: I've been thinking about this a lot recently over the past year with pipelines, and there are a couple of things that I found work really well, and I started doing too late. The first one is one on one feedback, and I don't mean like giving critical feedback to someone specifically. I'll give an example.

Let's say I put together a roadmap. This is how we're going to tackle this year to one. I've got like a vision board. Maybe I've got some mock ups or something. It's tempting to try and be efficient and okay, let's get a bunch of people together in a room. I'm going to present the vision. I'm going to do a Q&A and then, oh, wow, I got lots of questions. People seem kind of engaged and interested. Great. We've got alignment. 

And actually, this group alignment setting doesn't work. Like even if you've got like five or six people, even kind of small groups, I found that it really doesn't work. And what ends up happening is you'll get maybe a month or two down the line and you'll realize one person in that meeting had absolutely no idea what you were talking about, didn't really care, didn't have a chance to engage, didn't feel heard.

And if you don't feel heard, you can't even disagree and commit because you haven't been heard. You haven't even disagreed yet. So one of the things is when you've got a pitch that you think should be shared in a group format, do it one on one first, collect the right stakeholders feedback one on one and make sure that you can repeat back to them.

Okay, this is what I'm hearing you say about this. This is the confusion point. Like, go through that. Sometimes I use like a mirror board since we work remote, like I'll put actual stickies up of what the people are saying so they can kind of visually kind of see like you're capturing it, you're hearing it.

And don't under invest there, especially with your core team. The leadership team, it's harder to do that with, but especially the people building, take the one on one time and do it like you got to hit it a few times. Like one 30 minute meeting is not going to cut it. You'll need more than that. So that's one thing.

The other one, when it comes to leadership alignment, there's a concept. I wish I remember where I, this wasn't mine. I read it somewhere, but it's the concept of a learning roadmap. So, executives are interested, at least in my experience, a lot of the times, in progress. They want to see, okay, what are you shipping?

Where's the value? Where's my money going? Where's the return on investment? And when you're doing zero-to-one, there's a large period of time where you don't have money to show for what you're building. And conceptually, the executives know that, but if they've never built a product themselves, and honestly, even if they have, sometimes they are incentivized to push, like go faster.

Like, is this going to work? Am I going to look foolish? Am I going to be embarrassed by what you come up with? That core feeling is really problematic and alignment killing. So the learning roadmap is a tool that allows you to show progress without actually showing money yet. So rather than saying, we're going to ship this feature by X, of course, you need to have that stuff too, but you say like, well, these are the questions that we're going to answer this week.

So for example, should this be a standalone product or should it be integrated with our existing product? That might be a question on your learning roadmap. And you'll maybe there's some customer conversation, some market analysis, lots of different signals you might gather. And then you write something and you're like, this is the answer to the question.

Here's our evidence. And we ship that. We ship that answer. We ship that learning. And you could move on from there to pricing, for example, that's a fun topic in multiproduct. Should we adopt like a variable pricing model or something that's fixed? I don't know, but that's a learning that you could kind of go through a decision that you're making.

How many customers would sign a contract to pay for what we're building? Going back to the mom test, that's the opposite of the mom test is like, can I get you to sign a piece of paper committing yourself to money for this thing? Even if I don't have it yet, can I sell you on the vision? And that might be another one.

So if you think about the assumptions that you are challenging and the questions that you need to ask in order to build towards your zero-to-one and put that in a learning road map and show that shipping progress in addition to your features, that's a good way to get that executive level alignment where they can still follow and see something is moving and weigh in. They can have opinions on these things, which is another way to build alignment.

You want to engage them, bring them in for the co solution. 

Hannah Clark: Excellent tip for managing that tension, as you mentioned. 

Before we finish up, I just want to spend a little bit of time talking about, as you had mentioned, zero-to-one is a lot like, this is your baby, but then all babies must grow up. So what does that look like?

Taking a step back from a product that you've successfully taken from zero-to-one, and why is it so hard to make that transition? Even, I'll take it a little step further. How can you manage that change when we feel this strong sense of ownership or parenthood over the project?

Brendan Fortune: First thing is like we've already talked about. The best way to do this is to not let it become your baby in the first place. It's hard like if you can do that, that's the ideal way. But if you can't, which is very easy, particularly because for zero-to-one products, you have to believe in it more than anyone else.

You're the evangelizer. You pour some of your soul into it. And whenever you do that, it becomes part of your identity. So it is hard. It is hard not to do that. But I think what I would suggest, and I honestly I'll need to take my own advice on this at times is define some sort of end point, like take control of the handoff so it doesn't feel like it's happening to you. 

It's something that you are making happen. You can find the right moment for that, for the product that I most recently shipped data pipelines. That was a few months after GA when the business had another need for chief of staff that I stepped into and we're like, okay, this is a great moment now to try and hire someone else.

I've got an idea of who we need for the role. I'll hire them all on board them and stuff. So if you can pick your moment, I think that emotionally can be a little bit easier. And then the other thing, there's a quote from Yoda, and I don't, who, who actually wrote that. This was in one of the newer Star Wars movies.

I'm not going to do a Yoda voice. I'm terrible at that stuff. But it goes something like, pass on what you've learned, strength and mastery, yeah, all that good stuff, but also weakness and failure. And then it talks about we are what they grow beyond. That's the true burden of all masters. So it's maybe weird to think of yourself as like a master of the product, but it's that similar concept of like, I grew this, I own this, but real success is when someone else can do that job better than you.

And I think that's also true of people management, but for zero-to-one, I think if you can believe that, then it's easy to get excited about that handoff. 

Hannah Clark: That was so beautiful. I have to forgive you for not doing the Yoda voice. 

Well, this has been such a cool conversation, Brendan. I really appreciate you coming on and for all the amazing insights.

So where can people follow you or work online? 

Brendan Fortune: Yeah, I'm happy to connect on LinkedIn. If anyone has questions or especially if anyone wants to like has tried these things and they haven't worked, I'd love to hear about it. I'm also on Twitter. I'm @mnproductmgr or product MGR, kind of a confusing one. I live in Minnesota, so that's where the MN comes from. 

Hannah Clark: Underrated state. We've talked about that. 

All right, well, thank you so much, Brendan. Hope to talk to you again soon. 

Brendan Fortune: All right. Thanks, Hannah. 

Hannah Clark: Thanks for listening in. For more great insights, how-to guides, and tool reviews, subscribe to our newsletter at theproductmanager.com/subscribe. You can hear more conversations like this by subscribing to The Product Manager, wherever you get your podcasts.