My philosophy is if you put 80 % of your time in laying the foundation and doing solid discovery work, really understanding the problem you're trying to solve for whom, and have some of those foundational questions answered, then you're not going to be spinning your wheels later and wasting a ton of time because you did the wrong thing, right?
Now, you can't do everything perfectly, and certainly, again, with great tools out there now, you can whip up a quick MVP and do a lot of prototyping and other things pretty easily and experiment.
But what often happens is this this temptation to build something and put it out there, and then no one understands, everyone says, this must be a marketing issue.
I don't understand why nobody's adopting this.
And then you start unpacking it and you realize, we don't really understand our customer.
We don't really understand the pain point.
I do a session in my class where we talk about the feels, and you'll have one co -founder who maybe had a comfortable life, has some cash, so they're not really so insecure or worried about taking a big risk, and then you can have another founder who's just getting by, paying a mortgage, maybe they have a family, and the clash becomes everything from how much capital to raise and are they comfortable with that or does it feel like a lot of debt or a lot of weight for them?
So I've seen co -founder relationships where the tension really will get down to even just how they're paying themselves.
And then you add investors to that and their expectations on the growth of the business and all those other things.
And you can run into not just money, but even alignment on direction and strategy for the business can create a lot of tension for co -founders.
Creating great products isn't just about product managers and their day -to -day interactions with developers.
It's about how an organization supports products as a whole, the systems, the processes, and cultures in place that help companies deliver value to their customers.
With the help of some boundary pushing guests and inspiration from your most pressing product questions, we'll dive into this system from every angle and help you think like a great product leader.
This is the Product Thinking Podcast. Here's your host, Melissa Perry.
Hello, and welcome to another episode of the Product Thinking Podcast. Today, I'm excited to have Julia Austin with us.
Julia is a board member, an author, senior lecturer at Harvard Business School, and the founder of Good4Her, a community connecting underrepresented founders.
Julia taught the PM101 and 102 courses at Harvard Business School before me, and then she went on to create a course called Startup Operations, which led to her new book, After the Idea.
Today, we'll dive into this fresh release and Julia will share the key insights and practical tips from the book about what it really takes to create a startup after you have that great initial idea.
But before we talk to Julia, it's time for Dear Melissa.
So this is a segment of the show where you can ask me any of your burning product management questions and I answer them here every single week.
Go to dearmelissa .com and let me know what's on your mind.
Hey, product people, I have some very exciting news.
Our new Mastering Product Strategy course is now live on Product Institute.
I've been working on this course for years to help product leaders tackle one of the biggest challenges I see every day, creating product strategies that drive real business results.
If you're ready to level up your strategy skills, head over to productinstitute .com and use code LAUNCH for $200 off at checkout.
Here is this week's question.
Dear Melissa, I've been trying to implement outcome -based roadmaps at my company, but every stakeholder still wants to see future lists with dates.
Sales needs it for deals.
Marketing needs it for campaigns.
And engineering wants sprint planning clarity.
How do you practically transition an organization from output to outcome thinking when everyone's incentives seem misaligned?
So this is a really common issue in many companies, but I want you to remember one thing.
Outputs are not the devil.
You want to connect your outputs back to outcomes and your roadmap should really tell that story.
So it's not that we're just communicating outcomes and saying, Hey, we're going to go go do a bunch of stuff.
And hopefully you see that outcome in a year.
What we want to do is connect the things that we're doing back to the outcomes.
And we can do that by discussing the problems that we're really looking at.
So when we're looking at a roadmap, and we want to see what we're releasing, we should be saying these releases are going to help us reach these outcomes.
And that's how we prioritize a roadmap.
And that's how we figure out what goes on the roadmap, we figure out if we need to do trade -offs.
It all comes back to those outcomes.
So that's what it means to be outcome focused.
And that's what it means to really have an outcome focused roadmap.
It tells this story.
So when you're having issues though, where everybody just wants to see what's released and you know that you need to take some time and discover what those outputs should be, you want to make sure that the roadmap is clear to communicate what status your different items are in.
So for example, at another company, what we did was we labeled everything on the roadmap map on whether it was in discovery mode still, if we were experimenting in it with alphas or betas, or if we were ready for release and it was going to be generally available.
This allowed us to communicate to the rest of the company that if you see things in discovery mode, don't expect an output to be around it.
It's going to be more about what we're exploring, how we're going to really solve that problem, but we can't really promise that we're going to pursue it because we haven't validated it yet.
Things that were in experimentation mode are still being validated validated and we're having them introduced to a few customers here and there, we can start to talk about the problems we're going to solve, but we're not committing to super specific functionality.
We're still uncovering that.
And as we do, we're going to update that roadmap item to be a little more specific about the solutions we're building.
When we're getting ready to release to everybody, then our roadmap is going to get a lot more detailed about what we're releasing.
So here you're really evolving the roadmap and pulling that theme through, but you You're also connecting that back to the outcomes that you want to release.
And when we did this, we would also hide it for certain audiences.
So for example, if we're talking to sales, we're not going to show them everything in discovery when we're not sure if we're actually going to release it.
We're going to show them what is going to get released.
So that's a good way to help you really think through what am I showing on my roadmap and what I'm not showing on my roadmap.
And then we also want to communicate things that are further out that we might be looking looking at, let's say, further in the year as bigger themes, bigger areas we want to uncover, we're not going to look at super specific functionality.
This can also help them with planning.
So you do want to make sure that sales is ready and enabled to actually sell the things that you're building.
So you're going to want to include them earlier on when you have validated that's the thing you're going to build so that they can get ready, they can make their materials, but you start to create those working relationships about when you can actually expect things to come out.
So just hiding your roadmap or not sharing it with people is a really bad idea because they're going to make up things and fill in those gaps.
But if you create the structure and the communication framework around it, then roadmaps can be a really strategic planning tool.
So I hope that helps and I wish you the best of luck in getting your team to really be more outcome centric.
Remember, it's not just about outcomes.
It's about what outputs create outcomes.
So that's how we connected back to that.
And again, if you have questions for me, go to dear Melissa .com and let me know what they are.
I'll answer them on a future episode.
episode. Now let's talk to Julia.
Welcome, Julia. It's great to have you on the podcast. Thanks so much for having me.
So I'm very excited that your new book is out there called After the Idea.
Can you tell us a little bit about your career journey and what led you to write this book?
Yeah, absolutely. So I've had three decades in startup land, which makes me feel really old, but that's how long it's been.
I was at three different startups.
All of them I joined very early and all of them went public.
So that's kind of cool.
And I was there for most of the journey all the way through IPO and scale.
All three companies are platform infrastructure type of businesses.
So I was on the product and engineering side, spent a lot of time with engineers and product managers, but also because they were really early stage businesses.
I worked with marketing and sales and everybody else throughout the business.
Learned a lot through all of that journey.
And eventually towards the end of my journey in startup land as an operator, I started teaching various courses at Harvard Business School.
And one of which was a course I created called Startup Operations.
And the course is designed for MBA students in their second year who've already started their businesses and are trying to get it organized and launched before they graduate.
And what became apparent to me is there are a lot of people who don't get to go to Harvard Business School.
And there are a lot of alumni who never had the opportunity to have a course like this that really prepared them from running their businesses.
So I decided to democratize my course and make it available to everybody with my book.
And so that's what it It really is.
It's really broken down similarly to the curriculum in the book, but it's not designed as a textbook.
It's really designed as something that can be easy to digest, but practical to use.
And I watched you make the course at Harvard, which was really exciting.
And I saw the need for it too, because we had all these people coming into PM 101 who already had these ideas that were further along, or you were mentoring them the whole time.
And a big part of that I remember was a lot about founder dynamics.
Can you tell us a little bit about what you talk about in the book about founder dynamics, what the premise is, how people should be thinking about reading the book?
Yeah. So you start with your idea, right, which is some problem that you want to solve.
Typically, sometimes it's solution looking for a problem, but oftentimes it's something I'm dealing with or my family or my friends are dealing with and I'm going to solve it.
And then very quickly, most people either decide they want a partner to work with or they're told you really need a co -founder or somebody to work with.
Could unpack that a little bit more if you want to, but let's assume you're going with the idea that you're going to have a co -founder.
that's complicated.
And in the middle of trying to build something and figuring out what the problem is, how are you going to solve it for whom you're also dating?
And so I talked about the founder or the co -founder courtship, which is figuring out who is your person.
And I think a lot of founders don't appreciate or understand this isn't simply complimentary skills, right?
It's not just who's going to be the tech co -founder, who's going to be the business co -founder, because I'm the technical person.
It's your your person.
It's the person who will be your only confidant probably with every little detail of the business.
They will be the person that helps you get aligned on strategy, talk to investors, really deal with the heavy things that come along with building a startup.
So what I often see with co -founders is the lack of appreciation of the time that's necessary to build that relationship.
And I actually did some research recently where the average co -founding pairs or groups, because it's not always just two, that stick together are those that have known each other they're at least six months to a year.
They have a higher likelihood of success for their businesses, so if they've been together for at least a year.
And that could be former coworkers, it could be classmates, people they've been in school with.
But even in those cases, those circumstances aren't running a startup together.
And you know this, you've seen this as well, right?
So you're going to have somebody, I've known you forever, but oh my God, now all of a sudden we're making big decisions about hiring or about raising money.
And now this this person to have a different relationship with when we were just coworkers.
I see a big mistake too, where you were talking about in early stages where people go, oh, I need a technical co -founder.
And then they offer like a big percentage of the company to an engineer who's never scaled the team or they're the CTO.
And now they're in that role.
And a lot of the boards that I work on with companies that are scaled and they're like 10 years down the line or 15 years on the line, sometimes that founding engineer is still the a CTO, but the architecture is a mess, like nothing's really working.
And then you have to come in and try to figure out how do we revamp this?
But the person owns like 20 % of the company.
And it is wild to me.
So like, how do you suggest in those stages, those early stages of creating the company founders think about that relationship?
Like how should they actually approach getting to know each other?
And what do you do about the equity piece too?
Yeah, such a good question.
A couple of things, again, going back to the partnership, that's first and foremost, most important thing you need to solve for.
So if you need a technical person, either because you don't have the skill or because you're getting a lot of feedback that you're not technical enough, if that's what you're doing, then find that founding engineer or find somebody who's going to, even a contractor can be great.
You can always try before you buy and really start to work with them and see what that's like.
I have a few founders that I've worked with in my career where they started off as just the first engineering hire.
And then after a year or two, the relationship was so solid with the founder that they converted them and gave them more equity and brought them up to snuff in terms of their ownership of the business.
But I do think it's important to figure out what you really need.
And that's usually not just technical skill, especially these days with AI and so many things that are out there right now.
Oftentimes, that's not really the thing that is going to make it compelling to be a co -founder.
And it's much harder to claw back equity than it is to give equity.
So I always say start small, baby steps, build a relationship, do some projects together, other, see what it's like beyond just coding or beyond just design work or whatever you've hired them to do and limit the equity for now.
You can always give them more later.
Where do you see when people are working together?
Are there any like particular areas they tend to clash more on or disagree or working styles that just are good signs that this is not going to be a great partnership?
Yeah. So the number one thing, and I actually cover this in my course and I have a a whole chapter on it in the book, is their psychology around money.
So oftentimes teams come together, co -founding teams, and very, very common for them to have different backgrounds and different sort of feels around money.
So I do a session in my class where we talk about the feels and you'll have one co -founder who maybe had a comfortable life, has some cash in the bank, maybe they had a high paying job before they did their startup.
So they're not really so insecure insecure or worried about taking a big risk.
And then you can have another founder who's just getting by, paying a mortgage.
Maybe they have a family or they're used to having a lot of debt because of school or whatever it is.
And the clash becomes everything from how much capital to raise and are they comfortable with that or does it feel like a lot of debt or a lot of weight for them?
So I've seen co -founder relationships where the tension really will get down to even just how they're paying themselves.
So you'll have somebody who came into a business, a new business where they're used to making $300 ,000 or $400 ,000 a year.
And someone else is being told you shouldn't make more than $100 ,000 a year if you're a co -founder, right?
Until the business starts to scale and you can pay yourself a normal salary and clash tension, right?
And then you add investors to that and their expectations on the growth of the business and all those other things.
And you can run into not just money, but even alignment on direction and strategy for the business can create a lot of tension for co -founders.
Yeah, that sounds like a really important conversation to have earlier rather than later.
Yeah, totally. And you're absolutely right.
In fact, I often ask founders, how often do you talk to each other and check in with each other about just those things?
And they say, oh, we talk to each other all the time.
And I say not like slacking and DMing each other every day and talking about transactional things.
I'm talking about sitting down and saying, how are we doing?
How are we feeling about the business?
How are we feeling about the direction we're going?
How are we feeling about the culture we're building for a company.
They avoid that. It's crazy.
They don't want to talk about it because then it might unearth some uglies.
But that's what then, again, I'm an executive coach and I get them in my safe space sessions with them.
And that's the stress factor.
It sounds like, too, this kind of almost like relationship dynamics that we hear about partners, like not talking about money or not having those hard conversations that go back to romantic relationships, too.
Oh, 100%. And I say say that all the time this is either your first or second or maybe third marriage when you're doing this and i think it's underappreciated for co -founders they don't understand this isn't just another human being to do the work this is really a relationship and most startups last seven to ten years if you do well like if you actually get traction and you get to product market fit you're going to be in business seven to ten years together and you're going to spend most of your waking hours together so it really is that relationship it's very intimate perhaps more more intimate
than you have with your other partner if you have one because you're in this like constant interaction dealing with a lot of really big decisions all the time.
Wow. Yeah, that's definitely a key thing to start thinking about when you're building a company.
So I know founders are not the only thing that you talk about in the book too.
What other considerations do people need to take into account that maybe they might neglect after they come up with that idea or after they might start testing it with some customers?
Yeah. So one of the things I notice often with founders is early stage startups is they don't appreciate some of the more mundane, less sexy things that you have to do when you're starting a business like legal and finance.
Those are the two that are the most common. So we talked about money a little bit, but even in the money case, like understanding your burn rate, not just how much capital you're going to raise, but how are you going to spend that capital?
Or maybe you're not going to raise, right?
There are a lot more founders now are trying to bootstrap and not raise capital and have a little bit more independence, which can mean it's harder, but it's a little bit more freedom, that doesn't mean you don't have bookkeeping.
You have to think about taxes.
There's all these things that you have to worry about that a lot of founders get surprised.
Like I didn't know that I was going to have to start tracking all my receipts because I have to do taxes at the end of the year.
So that's finances.
And then on the other side is the legal side, which is everything from contracts, the co -founder agreement, the employee contracts, the term sheets that you're going to sign with your investors if you take money, customer agreements.
If you're doing a B2B business where you're going to be selling to big enterprises, you may have to do compliance work like HIPAA or SOC 2 or whatever it is you're going to do.
So there's a lot of those things where I think it's underestimated how much time they will take.
And a lot of times it's not your time.
You're like, oh, I pulled that contract together.
No problem. It was easy.
I used AI for it. But then you're sitting and you're waiting because lawyers have to review it and changes are made that you didn't expect.
I would say that's one of the most common things I've seen is the number of times I've heard from a founder who said, we had everything done, and then we got the contract back, and they made changes in it, and they didn't tell us.
Or the lawyers made changes, even though we already agreed we weren't going to do that thing.
And now we have to go back to the drawing board and re -redline and do all these other things that just takes an inordinate amount of time and money.
It can potentially cost a lot of money too when you get into legal stuff.
Oh, yeah. In the mentality of with startups.
We always hear about the sexy build the product and shipping and get the customer's part.
We don't hear about these operations pieces you're pointing out.
I think there's also this like mentality of, oh, that stuff doesn't really matter.
Like all that matters is we just build a great product.
When should you start thinking about all of those things that you mentioned, like those legal things, those compliance things?
Because I imagine there's a lot of people out there just going, eh, it could wait.
Like it could wait.
We'll just shove it off.
Yeah, exactly. And that's exactly why I started my course too, because all these founders or or these students were like calling me after they graduated and saying, my product's great, but oh my God, I didn't know how to do all these other things.
So I think it's a good idea as things start to gel and you really feel like, okay, I think there's a there, I think we have our first customers, or I think the product's starting to get some interest. It's a good idea to just at least start laying out the foundation.
What are we going to have to think about if we are selling to big businesses, enterprises, or even medium -sized businesses?
Are there going to be any compliance things?
At least start with asking yourself, what do we need to be concerned with and what don't we need to be concerned with today.
So a really common one is trademarking your company name.
And so I'll tell founders like, you know, unless you came up with some really cool like niche thing that you're like, oh my God, no way we want anyone to steal this.
This is the best name ever.
Don't worry about that right now.
That's really not what's going to make or break your business, right?
Spending money on trademarking, all those kinds of things.
You should do that at some point if you find something good.
But so many businesses pivot, it, I don't know, you know this, 17 times before they end up in the thing.
And they spent all this money on trademarking and lawyers and a beautiful URL that they end up throwing away.
So a lot of those things.
I think you should say, is this something we're madly in love with and we should do everything now to make sure we protect it and get it lined up for success?
Or can we wait on that thing?
The one thing I would say you should be doing from day one, and it does feel like it's premature, but I don't care.
I think it's just really important is what kind of culture do you want for a business?
Even if it's a tiny business, everyone's talking about AI businesses being like like these tiny businesses now, you're still going to have a culture.
People are still going to work together, even if you have a mix of contractors and full -time people.
So what is that for us?
And let's have that conversation.
And let's, again, check in regularly.
How is it evolving?
What do we need to...
If we're going to be all remote, have that conversation early, because that can also affect your finances or where you're going to hire people.
So I don't think you can avoid it.
And it is very common for founders to just like, I'll get to it.
It's not important.
It's not important.
When you start raising money, money, you're going to have to answer where that money is going to.
So you're going to have to think about for those reasons as well.
You also mentioned a little bit about bootstrapping versus raising money.
And I find that a lot of founders don't understand like the terms in their term sheet that they're getting into too.
And now we're hearing some stories about companies that have been out there for 15 years, raised all this money.
And then the founders leave with like a million dollars after spending like 20 years on it.
What are the types of things like you should be looking at there?
And how do you suggest people find out like what good is, right?
Because if you've never done it before, you've never raised money, like where do you go to actually understand if terms are written?
Yeah. So talk to investor friends if you have them, but the other is talk to other founders who are in the process of fundraising or have finished fundraising recently because it keeps changing.
Like the rules are changing.
Valuations are definitely changing, right?
Like when I first started in this industry, a series A was like 30, 40, 50 million.
That's like now a seed round, right which is like ridiculous it's just to me how much money people are raising i don't even know if the letters matter anymore so i say talk to other founders understand what they're hearing what kind of deals they're getting what kind of valuations they're getting because valuations have changed a lot the big bubble has burst so what used to be something that unless you're in some niche again ai business where you're just looking at it going i don't understand how come it was valued at that much money but for most average businesses that it's it's come down a bit,
but have a couple of things.
I would have a startup savvy lawyer look at any term sheet, not your dad's friend who's a real estate lawyer, but like somebody who actually knows what a term sheet is and should be able to tell you like what's boilerplate and what's stuff that seems a little sketchy or unusual.
And then I have other founders give you their take.
Those have been in the trenches, have already done it, are going to have a more honest view and no stake.
They'll be much more objective.
And then if you have former professors, investors mentors angel investors anybody else who can help you don't try to figure it out yourself is my point that's definitely good advice for that yeah in your book you also mentioned this whole concept of moving slow to go fast i feel like that's not what we hear from mark zuckerberg's move fast and break things that everybody was into with facebook so what do you mean by that like what what does it mean to go slow to move fast yeah so i my philosophy is if you put 80 of your time and laying the foundation and doing solid discovery work really understanding
the problem you're trying to solve for whom and have some of those foundational questions answered, or at least you've thought about them, right?
What kind of company are we building?
What kind of legal things might we have to worry about?
Those types of things.
Then you're not going to be spinning your wheels later and wasting a ton of time because you did the wrong thing, right?
Now, you can't do everything perfectly.
And certainly, again, with great tools out there now, you can whip up a quick MVP and do a lot of prototyping and other things pretty easily and experiment.
experiment but what often happens is this temptation to build something and put it out there and then no one understand everyone it says it must be a marketing issue I don't understand why nobody's adopting this and then you start unpacking it you realize we don't really understand our customer we don't really understand the pain point or guess what there's a user and there's a buyer and our user it lands for them beautifully but they're not the ones that are going to swipe your credit card to buy this thing so we haven't really fully understood the pain point of the people who are going to spend
the money to actually give it to them to use if it's b2b And on the consumer side, I'll give an example, and it's in my book.
Yinka, who's one of my former students, she was building, she wanted to solve for hair braiding for black women's hair.
And she's a mechanical engineer.
She can 3D print like anything.
She's brilliant. This is her second startup.
But she was trying to solve for two things.
One is what's the consumer experience when it has to do with braiding hair?
And she knows from her own experience, but a lot of founders tend to build things for themselves and they don't think about what about the global sort of broader group?
because I'm not the same as everybody.
And then she was also thinking about the stylists and she was going after stylists and salons and what do they need and what works for them.
So she cared about stylists who were struggling with arthritis and other things that were happening because it's very tedious, painful process to do the hair, but also the clients.
So she spent hundreds of hours doing ethnographic research, slowing down and really understanding what's the client experience in the chair, but also what's the stylist experience and things like, do they even have have space in the salons for my device?
If they already have a blow dryer and a straightener and these other things, are they going to have even a place to plug this thing in?
Which was something I see a lot of founders just don't even stop and think, oh, so it's a really basic question.
But if I hadn't watched them, it wouldn't have occurred to me that they love my device, but they're like, we don't have any space for it.
Where are we going to put it?
So that's what I mean by slowing down is take the time, do the ethnographic research, do some experiments, really spend time with your target audience.
And that's going to inform you, not only get you closer to, we should build that for these particular groups of people.
But then the other thing it does, and I have another example for this, is it helps you understand and learn whether this is something you want to do.
So I see a lot of founders who crank it out, get out there, start building something, and then have this realization that they're in a space they don't want to be in.
So the example I have, This one is not in the book, so I'll give you a freebie there.
I had some students in my PM101 class years ago who started their second year having figured out a way to get security deposits back for renters.
That's always a pain, right?
You leave a rental place and the landlord comes up with all these reasons why they can't give you your security deposit back.
And they figured out a nice way with an app for you to log everything in when you get into the apartment and then everybody signs off on it and there's really no way for the landlord to justify.
keeping your security deposit.
That was cool. So they were really excited about their business.
But then they realized they were spending most of their time with lawyers and landlords.
And they were like, cool, we have traction, but we don't really want to spend all our time with landlords and lawyers, right?
We love the tenants.
They're great. Like those people renting places are awesome.
But we're going to spend a lot of time with these people.
And we're not going to hire a whole team right away.
So it's not like we can just delegate that to somebody else.
So I think that's important when you're moving slows, not just to make sure you really understand the the problem and who you're solving it for.
But also it gives you a better sense of this is the business you want to be in.
Does that make sense?
Oh, totally. And I see that a lot, too, with founders who they find like an interesting idea and they're like, oh, I can make a lot of money off this.
It's a potential. But then they get into it and they're like, oh, I don't even like this business.
And I think there's a question I have for you, too, is do you see founders be more successful or like those problems that they work on more if they have a background in those those problems or they're worked in it?
Or is it something where you've seen them like see an interesting problem and then go learn out there?
Is there anything to think about like domain expertise?
Yeah, I've seen both.
I've seen the founders who this is their sweet spot.
This is what they know inside and out from prior experience before they decided to go after this space.
And so of course it makes natural sense for them to do it.
They know all that it's all their people, it's their network, it's everything.
So it feels really good for them.
But I've seen others where where they know nothing about the space, but they really find a niche.
It's something people are excited about.
And I have examples for each. In the book, I talk about the bridge team, also former students of mine.
They were building a consumer app, a digital insurance type of app, where they were helping people find lost items. And it was cool.
They were using QR codes, but it was hard because it was this whole like - Oh, I remember that team.
Yeah. Yeah. It was before like QR codes were like a big thing too.
Exactly. Exactly. So it was very novel.
They were like, and it was a perfect business meets meets technical co -founder relationship they met at school and they were putting lost items all over the place to see what happened when people found the items and what would motivate them to return them and what would motivate them to log them.
Like a swell bottle people didn't care about, but laptop or headphones they would care about.
But then they also found that people were finding the items were like, I don't really want to meet the person who lost the item.
I just want to bring it to the lost and found or something.
And so that was like, really, there was a lot of friction direction in the business.
And neither of them had any kind of consumer business backgrounds at all.
Kate, the CEO, had a marketing background and knew a lot about marketing.
So she had assumed that her co -founder, Zach, was technical.
They figured they would just balance that.
But as they were in their journey through a lot of experimentation, they realized that the brands that they're putting the QR codes on wanted to leverage the sort of last mile connection with the buyers of their products that they didn't get when they were selling their products through retail markets.
So they pivoted to a B2B solution, which is now called Bridge.
It was found now as Bridge.
And not only did they find a really great sweet spot for a problem to solve and the brands love them, but it was far more aligned with their backgrounds and their interests.
And Kate was like a different person once she realized this is the thing that really she knew and she had the connections and it was right up her alley.
It was just easy for her to double down.
But I've seen other stuff.
I have a student who just graduated who really wanted to create a healthy protein snack.
I guess I would call it that.
That was like yogurt, but had the texture of fluff.
And he has no real, I would say real like strong background or experience in that area.
He's not a foodie. He was just one of those people like, we're missing this.
This is a category we don't have. So we created a product called Pluff.
So it's a protein fluff.
And he is, oh, my God, follow him on TikTok.
He's so he's just nailing it.
And it's the greatest product.
I've done taste tests with him.
It's awesome. And I wouldn't say it was like a perfect came with that background.
It was the perfect founder market fit.
He just fell in love with what he was making and it just it's landing.
It's great. I love that.
That's so cool. I think when we're talking to you about how we have to slow down and understand our customers to really figure out what the solution should be.
It made me think of AI too.
And I'm sure you have a lot of opinions on this, right?
With all of these prototyping tools that are out there, your lovables, everything.
I see so many people go, oh, we don't really have to do discovery.
It's cheaper to just build it, put it in front of somebody and see if it works and tweak it from there.
What do you say to people who say that?
Yeah, I have such a visceral reaction to this because because it's so funny, right?
Because I'm an innovator.
I've always worked on cutting -edge technology, but also AI is not new, right?
So it makes me laugh also.
It's this false sense of security that an AI will give you all the answers so you don't have to actually talk to real people.
And this, I think, is a big struggle for founders is talking to strangers and actually getting out there and understanding human dynamics.
If human beings are going to use your product, you need to interact with human beings.
And AI is definitely great.
It does a lot of really cool cool things, but humans will do things that you don't expect.
And you and I've been building products for decades.
And even when we think we've done all the user research and all the focus groups and all the things, and then we put our product out there, I don't know about you, but I've had plenty of times where then we put it in front of the customer and you're like, oh, they're doing that.
Like I hadn't thought about that.
Or they developed some workaround because we didn't think about some natural thing in their environment that some tab they opened on their computer they never told us about in an interview.
Or like back in the day, it was like like opening a drawer and looking at a sticky note because there was some code they needed to do a thing.
They never bothered to tell us that.
So I think that AI can be helpful to get some efficiency going.
I'm going to go run an experiment.
What am I missing? Or what would be a great place to go find these people that I want to go run this test with?
So I think it can be a great thought partner and maybe a first pass in certain simulations you might want to do before you get out there.
But I don't know. I don't know how you feel about this.
But I feel like at the end of the day, you got to get it in front of real people and you got to see what the real environment is to really know if you're building the right thing.
Yeah, completely. I, it's funny because the more I hear about how people are using AI, the more I'm like, I can just rewrite my book and take agile out and put AI in.
And it would just be exactly the same, the build trap.
Like it's exactly, it's really cool that everybody can vibe code.
And I think it's fantastic for ideating through prototypes and I like use it with my designer and we go back and forth and can get to a state faster, but we still had to do a bunch of research before.
Otherwise you're just swirling in directions that are not going to amount to anything at the end of the day.
Yeah. And I would say this, and it's interesting.
I was talking to someone about this yesterday as well, that the level of efficiency and the way you can now extend your burn rate if you're a startup, because you don't have to hire five designers to get mock -ups of this thing that you want to do.
I just did this recently for my own website.
I just asked ChachiBT to give me the HTML for this interactive website that I wanted to created and literally got in two minutes.
Now that was more of a mock.
It wasn't going to be what was actually going to plug in, but then I could hand it to the designer and just say, do this.
This is what I want.
And I didn't have to wait a lot of time or spend a lot of money to get that far.
So I think it's going to be similar to what you said in agile, but I think it's a superpower for entrepreneurs to be able to do a lot more with fewer people and for a lot less money.
So they have a longer runway, which I think leads or lends itself more to the slow part, part, because I think you can have you can do more with less money and learn more about your customers without having to worry that you're not quite fast enough.
Yeah, that's a great way to position it, too.
I like that. Like, it's actually not about just spitting out stuff as much as possible.
So you can extend your burden rate.
That's the slow part is like actually take the time to learn.
So you do it right.
And I also find that there's all these, like AI startups that are running into the market right now.
They don't have a moat, right?
Like they can move it it really fast and they put it out there, but they haven't thought about like, how do I keep people here forever?
What would make this really sticky?
How do I protect ourselves from like somebody else just spinning, like a larger person who does this better spinning it up very quickly.
If it's not a super complicated functionality.
And I like the idea, the premise that you're setting about like going slow, really thinking through those things.
Because if you start that from the beginning, you're going to have, you might not build it all at first, but like, you will have a plan to do that next.
And you won't be caught off guard too.
That's right. And it's interesting that you said that.
Having been at a company that was one of the first internet companies in the late 90s where everyone was like, the internet.
And now it's like table stakes, right?
We can't do anything without the internet.
We can't have this conversation without the internet.
I look at AI the same way as if I have one more business say to me, we're an AI for this.
You're not. You're solving for this problem.
So I had one yesterday, or a couple days ago, which was we're helping development teams do better QA for AI tools.
So we're an AI company for QA.
No, you're not. your product your software productivity tool your dev tools company and you're helping engineers you'd be more efficient and i asked them is that what you're doing and they said well it's really for the head of engineering and i said okay so then you have two stakeholders you have engineers then you have the head of engineering have you spent any time to really understand the dynamic there and how that's going to play out and they had to spend none because they were already they'd written code and they couldn't figure out why no one was like downloading their or or going going
onto their SaaS app and buying the thing.
So I think this whole, we're an AI company, you're using AI, you're AI forward, that's okay.
But to me, the AI company is the company, I work with the founder of Deepgram, they're building text -to -speech, speech -to -text backend technology that is AI.
They are building the LLMs, they are actually training and building the engines to do all that.
That's an AI company in my mind.
So I think it's table stakes more more than people are allowing themselves to say.
And I want to hear more from a founder about what problem are you solving and do you really understand the customer than you're an AI company?
When we look at product management and understanding customers, starting from zero to one is very different than like being a product manager at a scale up.
When you're a founder and that's your role, like being a product manager too, what are the things that they should prioritize the most in those discovery processes?
What techniques, what kind of tools do you recommend they go do to deeply understand who the customer is at a startup?
Yeah. Yeah. So I think when you're a product manager going to a startup, there's two flavors, right?
There's the product manager who's never been in a startup before and they're about to get themselves into and then, and those who have, but let's start with the former.
So bearing in mind that the good founder who's got traction, who's ready to actually hire a product manager has been eat, sleeping and breathing this business.
And they've probably spent a ton of time with the customers and also are madly in love with what they felt and it's their baby.
So one of the tools, this is an actual tool, it's just a matter of shadowing and giving some time to the founder to really help them understand what got them here.
So for founders, I always say, even though you're taking for granted, you don't need to document things.
I wouldn't say go heavy on documentation, but at least when you've made key decision points for your discovery process, have it somewhere for a product manager to understand This is what got us here so that they're not reinventing the wheel.
And that could be like that didn't work for us six months ago, but now maybe we need to do new discovery work because we're getting bigger.
And that audience that we weren't going after before, now we're ready to go after.
So I think the product manager should start with some historical context, what got us here so far, shadow the founder to understand how they talk about the product, what they seem to care about, how much of this is what the founder thinks the customer needs versus is what the customers think they need because I've seen a lot of that, right?
The founder's like, the customer doesn't know what they want.
Like, I know what they want.
And sometimes it's true.
When I was at VMware, I would say 80 % of what we built was because we believed our customers needed something they didn't know they needed.
And then over time, that evolved into something that, and that as you get to be a bigger company, then the customers start informing more.
So I'd say that. And then beyond there, there's things like I talk about in my book about journey mapping and storyboarding.
They're very basic tools, but I find them super useful when you're having a conversation about what we think our customers need to break down in very simple steps.
Let's use the QA example.
I'm going to help engineers QA their code.
Okay, what is the process that gets them to the point of QA, right?
What is their vibe coding method?
What different stakeholders are going to review the stuff they're doing before it gets shipped or before it gets committed to the main line or whatever it is that you're doing?
Break that all down and understand really what's the most painful part.
And then how are they measuring that you've actually done a better job than what they're doing today?
Is that quality metric?
What's your KPIs? The quality metric?
Is it a time to ship metric?
Is it the number of bugs that are reported after you shipped it?
So spending some time really breaking that down and saying, really, where are we solving the problem along the journey for the customer?
And how do we know we've actually solved it?
How are we going to measure it?
Yeah, I think those are super important activities there.
when you're also the first product manager coming into a company who have to work with founders and I find that product managers and founders butt heads all the time what what's your advice for people who are like I want to be the first product manager at this startup like what should they know getting into it and then how do they work better with founders yeah trust building it's the number one thing is don't assume you're gonna just walk in there and take over the reins and the founder should be like great I'm gonna go do sales now that's probably not gonna happen it.
Once in a blue moon, you have a founders.
Thank God. I don't know what I'm doing.
Please take over for me.
But most of the time it's, I really want to understand your passions, what you care about, relationships you've built with customers, especially if you have like early pilot customers, beta customers, and really build that respect and understanding of this thing that they've built.
Again, it's their baby, right?
So when you bring in a babysitter or a dog sitter, you want to really make sure this is somebody that you're going to feel comfortable walking away and letting them own it.
And I think that's what a lot of product managers and startups don't appreciate or understand.
You can't just walk in and take over, right?
What you can do is spend some time really understanding how they got there, build trust by doing things like, again, a mock -up or you can use AI to do this, but I think what you're talking about is something like this.
Does this make sense for you?
I often see product managers come into startups to help prioritize and roadmap.
I think that's really common. We have all these features and we can't prioritize and we don't know what we're supposed to do next.
So can you help us figure that out?
So I think starting with the founders and understanding directionally, where are we going?
What do we think our true north is for the business?
And what does success look like six months from now?
Usually in an early startup, you won't know anything beyond six months.
But if you're a little bit more mature, 12 to 18 months out from now, where do we wanna be?
How are we being measured?
Not just revenue, but are we getting more customer logos?
Is there a particular new type of technology that we feel like, or capability that we feel like we have to have out there within a certain period of time.
Where are we going?
Then putting that into some kind of digestible framework can be a great way to build trust with a founder.
I think this is what we're doing, right?
The founder will feel like, okay, good, they get us.
Then the tactical, okay, how do we break down the queue of things that we have to actually get there?
I actually had to do that when I joined DigitalOcean as their CTO.
We were a four -year -old company, 170 million in revenue and absolutely no product roadmap whatsoever.
And we hadn't really shipped anything new in months.
And so there was a lot of frustration in the business and with our investors because we were this wildly successful business, but we plateaued and we weren't going anywhere.
And we had product managers and we had a ton of engineers, but there was no process.
There was no organization.
It was really messy because the growth was just so fast. And so that was my first order of business is I built a product roadmap.
I understood where the founders wanted to go.
They had a sense of what kind of cloud company we would be in 12 to 18 months.
And then we worked backwards from that vision into a practical plan that not just included product, but also included support, operations, all the other things that we're gonna have to go into making sure we could realize that goal, which I guess is the other thing that we tend to forget that you can't just do product, like support sales everybody has to be bought in and ready for that too and it's such a it's such a big role too right when you're you're a product manager especially the first product manager in a startup there's so much scope to actually look at when people are coming to you and telling
you like hey I want to be a product manager I want to go to an early stage startup what's the besides working with the founders understand the role how can you tell someone like you might be ready for this or this might not be for you what do you look for there to set their expectations expectations?
I look for someone who nothing is beneath them, first and foremost. My first job at Akamai, my very first startup I joined, they called me a release manager, but it was really a product manager.
I didn't care what the title was.
They were like, can you just make us organized?
I was like, yeah. Project manager meets product manager meets program manager.
I don't know. It was like a lot of things.
You have to be comfortable with that.
Ambiguity of the role is really important.
So be comfortable with your title might not make sense or what they ask you going to do, might seem menial, just take notes in the meeting.
Okay, fine, whatever.
So they have to be someone who's okay with that.
I think that's first and foremost. And then they have to also be okay with a lot of context switching and shifting and pivoting because if you're joining an early stage business, it's not all figured out yet.
So I get lit up and other people that I know who work in startups get lit up like, cool, we get to figure out what it's going to be.
Some product managers, that sounds cool, but then they get really frustrated because they don't understand in, that thrash can be really painful if you're not ready for it.
So I'm looking for someone who can tell me they were at places that it was like messy, ambiguous.
They put some structure in place, but also when things change, they roll with it is really what I want to be looking for.
And then also know that things like upward mobility and all that stuff will come.
But if you get too caught on title, I don't care where you went to school or how many years of experience, if you're going to be a first product manager at a business, you've just got to know that if business does well, you'll do well, but you're going to be part of that story.
Yeah. That's very good advice.
On the flip side, there's a question of founders always ask, when is the time to hire my first product manager?
Yeah. So I think it's at that point where you feel like we're getting real traction.
We're starting to feel like the pull, right?
Product market fit is the pull when customers are coming to us or their friends are coming to us and saying, we want that too.
And you're starting to feel a little bit overwhelmed with prioritization.
To me, that's the biggest signal is we have the good problem of we have a lot to do and we're not really sure how to order and sequence it, or we've got something moving and we're realizing there's a new market segment or new set of features that we have to add to what we're doing, keep this set of customers happy, but to expand the way we need to, we have to have somebody who can start thinking through that next gen of things that we're doing.
That tends to be, for me, what the signal is, is that pressure point.
The other thing is when we have a CTO founding engineer who has been pinch hitting the product management role because you're a small enough business, but they really are a coder and they're not a good project manager, and they really just want to focus more on the architecture and the technology, that can be the other signal where they're feeling like I can't focus on all the trains getting out on time and what we're supposed to do and make sure we're building high quality code if you're building software.
Then I think that's another another good opportunity to bring a product manager in very interesting signals to look out for Julia with your book who is the right audience who should be reading after the idea yes so I have three primary audiences the founders obviously and I think founders can be just thinking about it maybe I'm not even sure which after the idea so maybe I'm noodling an idea and I'm not sure what I'm about to sign up for so you're a great audience for it founders are already in it and I've even had founders who they're on their second companies and they've said I'm reading your
book because I don't think I really did the last one.
I wasn't really prepared for that.
So I think founders in any period of their journey are great.
Joiners. So I has a three -time joiner myself.
I think it gives, I've written it in a way that gives perspective for joiners to understand all that's going into building this company.
Because again, I think joiners sometimes don't understand why isn't this working or why is this so ambiguous or whatever and saying, because it's a lot and these are all the things.
I put a lot in the book for that audience as well.
And then the last is as investors.
So I believe that most investors are great.
A lot of investors have not been operators at startups before.
And so they don't really understand when they say, can't you just do this thing?
And they don't realize all the things that the founders are focused on at the time.
So I hope that investors find it helpful to understand the behind the scenes, the day -to -day, the kinds of things that their portfolio companies are dealing with, especially if they're an earlier investor.
So they haven't been around the block for a long time.
It can really incite what's happening when they're outside the board meeting.
Really cool. Diverse group of audience is there too.
And I think they're going to find a lot of value in the book.
Julia, my last question for you.
What advice would you give to your younger self?
Ooh, that's such a good question.
I'm going to have to think about that.
I think the one thing that I wish someone had told me to do, and I'm certainly biased now because I'm an executive coach, but I wish I'd had a coach or someone had told me like if you're going to eliminate the first management role I had in startup land should have been a signal for me to have somebody help guide me or at least give me a reality check when I was dealing with certain things and I didn't know if it was the startup I was in that was crazy or this is normal startup crazy what's common pitfalls and then how do I handle certain things people stuff in itself is so complicated and so I
would say that getting a coach which is never too early in my mind, if you can afford it.
Getting your company to pay for it or your investors to pay for it, which a lot of investors are doing now, which is great.
But I would say get help.
I think I also, as a woman in tech and also at a time where there were very few of us since I started so early in my career, that I didn't have role models and I didn't have mentors like me.
And so I would say get that for yourself.
They're much more available to you now than there was when I was in my career, but I probably could have found someone.
I just just didn't know to do that early in my career.
Yeah, that is such great advice.
And I know having worked with coaches myself, it's super valuable to get other people's perspectives on there too.
Yeah. Thank you so much, Julia, for being on the podcast. If people want to go buy your book, where can they find it?
Yeah. So aftertheideabook .com is the best place to go.
And I have other resources on the website as well.
And certainly they can reach out and DM me on LinkedIn if they want to chat with me about their businesses.
Great. And for the people out there who might want to work with you, what's the best way to get in touch?
Same way. Go to the website and, or DM me on LinkedIn.
Either way, you can contact me through either venue and I'm happy to chat with you.
Great. And we will put all of those links on our show notes at productthinkingpodcast .com.
Thank you so much for listening to the Product Thinking Podcast. We'll be back next week with another amazing guest. And if you have any questions for me, go to dearmelissa .com and let me know what they are.
I answer them every single week here.
Thanks. And we'll see you next time.
