we built a prototype of this video conferencing software that worked well enough that we could make calls within Google.
And that prototype took off inside the company and people started using it for meetings and eventually it became what's today Google Meet.
But that moment for me was a huge one because up until that point I had been thinking about designing products and how do you make a product work as well as possible.
And I just had this insight that you could apply the notion of design to the way that we work, Differentiation is huge, it's the only thing that matters.
It's something that I think every product person, every founder, they ought to be thinking about it from the moment they start the project.
You're absolutely right that you see a lot of large companies delivering products and it's not clear that the differentiation has been thought through.
It feels very much like at the last second, we're just trying to develop a story around this.
The product should start with a story.
your future. 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, we're joined by Jake Knapp, co -founder and general partner at Character Capital, and the brilliant mind behind the New York Times bestselling book, Sprint.
Jake has been instrumental in creating products like Gmail and Google Meet, and is now reshaping product development with his new book, Click.
As someone who transforms complex ideas into actionable strategies, Jake's insights are invaluable for any product enthusiast. I'm thrilled to dive into the Click book more today and explore how he helps products succeed in today's fast paced market.
But before we talk to Jake, it's time for Dear Melissa.
This is a segment of the show where you can ask me any of your burning product management questions.
Go to DearMelissa .com and let me know what they are.
Today's episode is brought to you by Live Blocks, the platform that turns your product into a place that users want to be.
With ready -made collaborative features, you can supercharge your product with experiences that only top -tier companies have been able to perfect, until now.
Think AI copilots, like Notion, multiplayer like Figma, comments and notifications like Linear, and even collaborative editing like Google Docs, and all of that with minimal configuration or maintenance required.
Companies from all kinds of industries and stages is count on Live Blocks to drive engagement and growth in their products.
Join them today and give your users an experience that turns them into daily active users.
Sign up for a free account today at liveblocks .io.
Here's this week's question.
Dear Melissa, how do you recommend a strategic portfolio view for 28 different products?
It's a lot of products.
One thing I would think about when you're thinking about views is who is viewing it.
Who's your audience?
what do they have to do when they are looking at 28 different products?
It's probably going to be the product leader or the CPO across all of those products, trying to figure out how to bring them together.
You might also have a view for different dependencies between the different products.
You might want to do a view as well for sales so that they understand what's coming up in the rest of the company, what's coming up with what's launching.
Let's think about the different views that you would actually do.
When you think strategic, I'm thinking that your executives are probably going to be the ones who are looking at this.
Executives, maybe a head of product.
And they probably want to look at what's laddering up to our strategic intents.
So I would try to think about what are the big types of initiatives going on across these products?
They're going to ladder up to making meaningful progress towards our business goals.
And how can I show that interview?
What do we believe these different products are going to do to contribute to those business goals, which I call strategic intents?
And how do I put a view out there to bubble up all the nitty gritty into something that an executive can look at and say, oh, I understand that.
I understand that when we achieve this initiative, it's going to make meaningful progress towards reducing our churn or entering a new market, anything like that.
So you don't want to go into all the nitty gritty that's on the roadmaps for every 28 of those different products.
Right. You don't want to get into what I call options.
Some people call epics on the teams. We want to go up a level into initiatives and then the initiatives they to be defined so that they're long term enough to actually make meaningful progress.
But they also should be things that are tying back to customer problems, tying back to bigger featurer ideas or bigger product ideas, and then relating them back up to the strategic intents.
So you want something that's like a portfolio roadmapping tool to help you do this.
I'm an advisor for a company called DragonBoat that does do that.
And I like it because it does give me those views all the way back up to that strategic portfolio.
So if I'm an executive, I can actually look at my 28 different products, all those different views on there.
So whatever tool you do decide to use, you want to make sure that it's at a strategic level that's not at the roadmapping level.
This is a different view.
We're not looking at, what am I going to release today or tomorrow?
We're looking at, how does my strategy actually ladder up to reaching those business goals, and are we on track?
And the information that's on the roadmap should be condensed and pulled into that portfolio roadmap in a way that comes back to your executives and some information about what they need.
So if you're trying to design this, I would first start with talking to your audience, your executives and saying, what types of decisions do you need to make?
What types of information do you need to understand to make those decisions?
And then back out from there to actually design your strategic portfolio roadmap.
That's going to give you the information that you want.
Then you're going to be able to start to slice and dice your views in whatever tool you're using, to be able to deliver that to them.
I'd also recommend consolidating these things around one tool eventually.
So that you can have different views for sales about what's going to be released and hiding a bunch of stuff that might be in discovery.
You're going to have different views for the rest of the organization, maybe cross teams, interdependencies.
That's what happens when you start to put this more into a tool that can do portfolio road mapping.
So I hope that helps with your question.
28 products is a lot.
You want to make sure that you're giving the right people the right information.
And remember, there is no one view to rule them all.
So that's it for Dear Melissa this week.
If you have questions for me again, go to dearmelissa .com and let me know what they are.
Now let's go talk to Jake.
Hey Jake, welcome to the podcast. Hey, Melissa, thank you for having me.
So you have written a very well -known book out there called Sprint that talks all about how people can test their ideas and figure out how to deliver value to their customers faster.
Can you tell us a little bit about what got you into this journey of authorship and writing books about how we build better products.
I'm going to take you all the way, way back to me as a kid, because I there's a connection for me.
I started off as a computer nerd. I started off as a baby, but as I got old to being a kid, I was around Apple computers.
And then Mac computers.
My mom was a teacher.
And this is in like the 1980s and nineties.
And she always had a computer at home and I was always tinkering with them playing games.
And then eventually.
trying to figure out how to make my own computer games.
And that process of having an idea, making it and then testing it with people.
In this case, it was my friends, but seeing if that idea could come to life and actually work for people was just a delight for me.
Just one of the absolute highlights of growing up.
And when I grew up and started working in technology that drive to create something that people love It's just always been there.
So I worked at Microsoft for a few years in the early 2000s.
And then went to work at Google and kind of mid 2000s, and I was a product designer.
I was building products and.
Leading projects like Microsoft and Carta, which was an encyclopedia on CD -ROM long time ago.
And then at Google working on Gmail.
And I was loving the difference from being on your own, making your own product when you work with a big team and a big organization, you can deliver something that's much more complex and you could reach a lot more people.
It takes longer, but you get those advantages and that's wonderful.
But around the time I had been at Google for maybe a couple years, I started to notice something that was a problem, a gap.
And it was, we often took so long figuring out the form of the thing.
And a lot of times we didn't get it quite right.
And so I had seen projects at Microsoft and at Google that were really great ideas.
They had promise it seemed, but they never saw the light of day and other projects where you're like, gosh, the form that it came out and it just wasn't quite right.
And so I had been working on this project there for, at Google for a couple of years, a side project.
So my main project was Gmail.
Now I was working on this side project with a couple of colleagues and we had this idea for video conferencing in the web browser.
So this was like 2007 2008 and at that time it was really a hassle to do a video call and we thought, gosh, we have the technology at Google, we could deliver this right in the web browser and so we're working on it but we keep trying to pitch it to different people, trying to put together like a deck or like a PRD that'll explain it and nobody's really quite getting it quite loving it.
And anyway, I reached this moment in 2009, after the financial crisis, Google had started shutting down some of the small offices, and my colleagues worked in this office in Stockholm and I freaked out, I traveled to Stockholm for a week to work with them.
And we're like we have to this is our last chance really to get this thing going because we were afraid they would close the office.
And in those few days, we canceled all of our meetings.
And we said, forget about the document, forget about the slides, we have to make a prototype.
And we built a prototype of this video conferencing software that worked well enough that we could make calls within Google.
And that prototype took off inside the company and people started using it for meetings and eventually it became what's today Google Meet.
But that moment for me was a huge one because up until that point I had been thinking about designing products And how do you make a product work as well as possible?
And I just had this insight that you could apply the notion of design to the way that we work and that moment at the beginning of projects was really crucial.
So I ended up creating this method called the design sprint for use at Google at first, and started leading these design sprints at Google.
Did that for a couple of years.
Went to go work at Google ventures and started doing it with startups.
And eventually I thought, man, this thing is so useful.
I just, I want to share it with more people.
And that led to the sprint book.
That's the long backstory from baby to sprint book of how that happened.
It's a great story though.
And it's pretty cool that Google Meet started out that way.
Just like a prototype inside the company and then it took off from there.
So did you, did you get to keep your team in Stockholm?
Did you guys - They're still there, yeah.
They're still there?
And it's my anxiety that says that they were maybe going to get closed down in 2009.
I don't know if that actually would have happened but they're still there.
So that's the good news.
That's good. I mean, still shipping valuable stuff.
So awesome. So Sprint has been out there for a while.
People have been using it a lot.
And recently you wrote a new book called click, which I just read, which is very exciting.
At first I read it and I was like, click, is it like clicking on stuff?
And then I got to the first page and it was like, no, let's, how do we build products to actually click with people and find the right problem and the right solution, which I think is so important.
what made you want to follow up Sprint with this book?
I had that moment in 2009 of realizing there's a gap here.
There's something missing with the way we start projects.
I worked at Google up until 2012, worked at Google Ventures from 2012 to 2017.
Wrote the Sprint book, came out in 2021.
I had left Google and my co -author on Sprint actually, and I, and our friend Eli Bleack Goldman, and we started a venture fund of our own called Character Capital.
And we started to have this experience of being the general partners, as well as the design partners who are working with the founders.
So at Google Ventures, we were design partners, we were working with founders, but now we're working with folks as the investors, and it gave us the opportunity to have a lot more conversations with founders, especially in the earliest days of their companies.
Precede founders who are really just getting going.
And we started to realize that there was another gap.
The design sprint works fantastic for a situation where you know the problem that you're trying to solve.
You have a strong opinion about the world and you say, okay, we need to get that prototype into customers hands.
See how they react.
When you put this solution, we need to find a form for it and then test it as quickly as we can.
And the design sprint lets you do that in a week and it's great.
But there was a gap before that, and every founder has a view on the world.
They have an opinion, a conviction.
That's why they started a company, but that conviction is often not crystallized into a hypothesis that you can then clearly test in the design sprint.
And so we started to create a method to help founders with that part with what's the minimum number of steps we can get to set them up for the best possible experiments.
Our motivation is we're investing in these companies, we want them to become successful, we want to do everything we can to help them find product to market fit.
But we also want to do it as fast as possible.
Because we know time is of the essence for them, we don't want to waste any of their time with workshops that aren't necessary.
So we narrowed this thing down to just a few hours.
And we called it a foundation sprint.
And then I had this same feeling that I'd had before writing the Sprint book, which was gosh, this thing's working really well.
We were doing it time after time and it just seemed to be helping founders so much that it felt like time to write another book about another process.
So with the foundation sprint, you talk a little bit about the sequence of how you set up in the book.
Can you explain how that works?
Yeah, definitely. So the foundation sprint is a two -day activity.
It's about 10 hours spread across two days.
And the first thing we do is called the basics.
It's defining the basics of the problem that you're trying to solve, the customer who you're trying to solve it for, listing off your top competitors, and also thinking about what your advantage is and then getting really specific about it.
What insight do we have that other people don't have?
What capability do we have that we're gonna rely upon to deliver this?
What's our motivation?
Often motivation is a thing that helps to deliver outstanding products that separate themselves from the alternatives.
So the basics are things that everybody knows but usually are not crisply defined.
So we just spend a couple hours at the beginning defining those, making the basics really crisp.
So that's the first half of day one.
Second half of day one is all about differentiation and figuring out what is it that's going to make our solution stand out from the way people are doing it today or the other alternatives that are on the market.
And we want to spend enough time on that, that we get really crisp about what's going to matter to customers in our belief, in our opinion.
This is all still our best guess.
On the second day of the foundation sprint, we spend a few hours thinking about the approach. So listing off all of the approaches we've thought of already that we might take and then going through an activity that we call magic lenses to choose the one that we're going to try first. And at the end, you combine those things, the basics, the differentiation and the approach and together, they form what we call a founding hypothesis.
This is the essence of what we believe to be true, what must be true in order for our product to find product market fit in order for it to succeed with customers.
And that founding hypothesis is the perfect setup then for running design sprints.
So the, your foundation sprint basically leads into your design sprints is what you're saying?
Exactly. Yeah. Okay.
It's like one, one train car connecting right into the next.
Cool. And I see this, I do see this as a big issue for a lot of even product people out there, and founders.
So like you're talking about, I guess one of my questions back to you because you us to find this in your foundation sprint.
In your hypothesis, who is Qlik for?
Who's your target audience?
That's a good question.
Have I thought that through?
Qlik is written primarily to founders.
We're talking to founders because that's who John and I talk to every day in our work.
But it's my belief that product folks, designers, engineers, marketers, leaders inside larger organizations will really benefit from this way of thinking that is derived from what a startup needs to do to survive.
I've worked in large companies.
I've worked now with hundreds of startups at different stages, but for me, the most fun part is working with those really early stage startups where they're in survival mode.
They've got to find product market fit in order for the company to actually live.
And the clarity you have about what needs to happen there is amazing.
If you can bring some of that clarity, that urgency to a larger organization where you have already a large audience, you have already a brand, you have the ability to build bigger things that might have a broader reach, I think it's an incredibly powerful way of working.
So I'm hopeful. And we wrote the book with founders in mind, but also with the idea in mind that a product manager at a large company should be able to take this and apply it to exactly what they're doing.
Yeah, when I was reading through it, I definitely saw like a lot of synergies there that product people should know as well.
And one of the parts that I really love that you honed in on is a differentiation piece.
And when I look at even internally in companies, a lot of product visions or sometimes company visions, I'm like, you're a very large company.
This should probably be a little more worked out here, but they don't have the differentiation piece.
It doesn't talk about what you were trying to connect with the capabilities and the insights that we have. Can you explain to people how you think about differentiation and what kind of model they should step through to get to that point?
Yeah, differentiation to me for a long time was just a kind of MBA word that didn't mean anything to me.
And we've all seen slides, there's a two by two slide and the thing we're talking about is in the top right.
And there maybe there's some other products or companies in the top right, usually differentiation is something that if a founder thinks about it in a pitch deck, they're talking about the technology or the market opportunity.
And sometimes you'll see them at the very end when people start to think about marketing, the product's already done.
Our insight from working with startups for a decade plus now is that you've gotta think about differentiation from the beginning moment the inception of your project, in the end differentiation is the only thing that will matter to whether your product succeeds or not because we all have limited energy in our lives to consider new things and if you're going to consider a new product if you're going to bring a new thing into your life and try it out whether that's a new feature on a thing that you already use or whether that's something brand new that you pick up it's got to be dramatically better
than what you're doing before, or our brains just aren't going to want to spend the calories to even think about it, let alone take the risk and the time to investigate it and start trying it out.
So differentiation is huge.
It's the only thing that matters.
It's something that I think every product person, every founder, they ought to be thinking about it from the moment they start the project, defining what they believe to be true, the differentiation they believe will matter to their customers, and then prove that to your as fast as you can before you commit to building because what often happens is we have a sense of this technology could be interesting, we build it.
And then at the very end, we're saying, oh gosh how do we convince people to try it?
What's different about this?
And if you're doing that at the end you have to be very lucky to succeed.
And I think, Melissa, you're absolutely right that you see a lot of large companies delivering products and it's not clear that the differentiation has been fought through.
It feels very much like at the last second, we're just trying to develop a story around this.
The product should start with the story.
Yeah. I see when people are writing like their product vision statements, which I think is similar sometimes with the format that I see to your founding hypothesis, we'll get to the, unlike these types of competitors and it's just lackluster.
Sometimes it's, oh, we'll be simpler and we're like, okay, but what do you mean by simpler?
What's that actually going to be?
And what I like about in the book is you this little part where you have these matrices.
And you're showing like competitors on the different axes and like how it lines up in the four quadrants.
And then you're trying to teach people how to change the way that you think about the value around it.
Can you explain a little bit about how you can take a product, maybe look at it and be like this differentiation is a little lackluster and what can drive you to think about it in a different way.
The thing that we do in the foundation sprints with teams with for us, it's usually the founding teams. But this might be the leaders on your project.
Is to start off and say, okay, well, here's a list of classic differentiators, fast to slow, the continuum scales from fast to slow, a scale from free to expensive, a scale from integrated to siloed and so on.
Some about 10 or 12 classic things that people generally understand their ways that products have differentiated themselves in the past from the old way of doing things.
And let's start off by we've identified your competitors earlier in the day and the basics.
Let's start off by taking a really honest assessment about where can we be relative to those competitors on that scale.
And when teams do this, they usually find that maybe there's one or two where they differentiate a lot on there.
But often they'll say, we need to go deeper, we need to find a differentiator that's particular to us because what we're doing is a little more specific, maybe a little more sophisticated.
And then they'll spend some time listing out their own differentiator.
So what's the, what is the thing that we believe to really matter to our customers that the other products don't do that we can do and we can deliver on.
And I think that when you're primed by what's the competition and you've been really realistic about how tough the competition is and you're primed with your insight and your motivation and your capability, it's a perfect moment to say, okay, this is the thing that we believe will really be true.
And then we get specific and we'll chart out, okay, let's go competitor by competitor.
You choose one of these differentiators, let's go competitor by competitor and compare where we think they are on a scale.
And often what seems at first blush, like, yeah, we can win on that.
When you really get honest and you're thinking about it, you say, oh no, I don't know that's true.
Now, all of this stuff about differentiation that we do in a foundation sprint, again, it's to create a hypothesis.
So a hypothesis is just a prediction about what we think will happen in a design sprint, we're going to build a prototype.
We're going to put it head to head against those competitors and watch what happens when customers are choosing when they're shopping between their options.
And that's when you really find out does that differentiation matter?
Can you deliver on that differentiation?
Have you figured out the right form of your product that actually carries that story through.
And that's when it gets really interesting.
Then you start to see the score card where you're like, is it different enough on that axis on that axis?
And that's when we look for whether the product clicks.
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.
When you're setting up your hypothesis on there too, I see a lot of teams struggle with this in product management, especially, and probably founders as well, but you always have that, do we go out and do customer research and then write the foundation's hypothesis?
Or are we writing it and then doing customer research at the time?
I feel like people get into the mechanics of this start to get confused about what order they do things in.
How do you describe the way that you do customer research and develop that hypothesis?
Is it before? Is it after?
It's during. I like to start with people where they are.
And teams. I want to start with the teams, the founders, the leaders, where they are.
Sometimes that means they've already done research. They've already been talking to customers.
They've had conversations.
They've started to form some insights from those conversations.
or they've been in this industry for a long time, selling things, they have ideas already.
Sometimes that means they're just going off of hunches but regardless of where you are, I think the easiest way to get great results for any team is to form a hypothesis, that's the foundation sprint, then run a design sprint where you say, okay, we're gonna turn that hypothesis into a specific prototype.
this is what we think it will look like.
And then you have conversations with customers where you're showing them something they can react to.
So in those conversations with customers, we're going to do a little bit of discovery.
We're going to ask them about how they solve this problem today.
What do they use? What goes on in their life?
And we're going to ask them to shop between their current option and one or two or three prototypes that we've made.
And another competitor perhaps that we know is really strong.
And I just think that kind of research is A, it's easier to conduct, you have a framework, so if you're not already an expert researcher, you can conduct an interview like that and get pretty good results.
Expert researchers are always gonna get more out of these kinds of things, but an amateur like me can get pretty good results from that because of the framework of having the prototypes and the alternatives.
And the other thing is that if you have a lot of people on your team, or even a few, it's a lot easier to get them deeply involved in the research process if it's a prototype that they took part in building, if it's an expression of their hypothesis, rather than, we know you're already thinking something but I went off and did a bunch of research and now here's my report.
It's hard to get that to break through.
It's a lot different when you're watching this thing you've been working on and you just want to know did it work or not?
So I know for a lot of folks that feels like putting the cart before the horse, but I just think it's a more versatile, more honest way to start off a project and it's not to say that other kinds of research beforehand aren't valuable, they certainly are, but it's just to say not every team can do that well, not every team even if they can do it well will listen and absorb it but this method does get absorbed, it is durable and resilient to less than great researchers like me conducting the interviews.
And I think that's pretty powerful in the foundation sprint.
You also talk about this concept of magic lenses that made me pretty excited because I think there's a lot of overlap with how product people are trying to think about their commercial lens and the viability of stuff.
Can you tell us a little bit about what those lenses are and how you use them?
Yeah, absolutely. So I'll describe the problem first. This is a problem of which I've been a big contributor to this problem.
So, it's pitching your own idea, and having one framework for what matters most, and being really locked into that.
And then giving your teammates a sales pitch for your view of the world.
And I have to admit, I will instantly fall into this trap in any conversation.
I'm doing it right now, right?
I'm giving you my sales pitch for my view of the world, about how people should start projects and why they should read my book.
And I'm very invested in that.
I've been thinking about this book my way, and I've been thinking about the world my way.
And I really want to convince you, Melissa, and everybody who's listening, that they ought to do it that way.
To a lesser extent, or to an equal extent, we get invested in our own ideas when we're trying to solve a problem in building a product.
And every meeting, every conversation usually has some element of this.
Everybody's got their perspective and they want to communicate it to the rest of the team.
And we don't do this because we're all jerks.
We do it because we want the best outcome We want to make sure that the things that we see and we know that other folks on the team may not, the perspectives that we have, want to make sure that they get expressed in a way that the team can understand them and make the best decision.
So nobody's setting out to manipulate the playing field.
But what happens is just having a verbal conversation about our options is inadequate.
We're going to hear more from people who are more comfortable giving their sales pitch, people who are extroverted, people who have been on the team, you'll have a certain role on the team.
We're going to hear more from them, and we're going to hear less, from other folks.
And we're also going to be limited by who's on the team and in the room at that moment.
So it would be lovely if, whenever we made a big decision about our product direction, if we had a team of advisors who saw the world from different perspectives and could give us their take.
So it'd be wonderful to have somebody who was this customer product visionary and would say, look, this is what matters most to the customer, let's make sure to make our decision based on the customer, that's really important.
It'll also be great to have another person at the table, who's the business expert and is just like, we have got to figure out how we make a sustainable business out of this, we must consider the long -term value to the customer and how large a market there is, it'd be great to have somebody focused on growth it'd be great to have somebody focused on pragmatically, can we build this thing what's the fastest, cheapest thing that we can and actually build and get in people's hands right away.
And there are other perspectives that you ought to have, but the thing is on most teams and most decision -making situations, we don't hear all of those perspectives.
And even if we don't hear them all at once, and even if we did hear all of them at once, it's like brain overload, like even just talking about it, it's like a lot, right?
And so to try to weigh all of this stuff, it's more than our working memory can tolerate.
So Magic Lenses is a visual trick to make those different ways of looking at a question and a decision between multiple options.
It's a way of making them visual.
And we just use two -by -two charts and we have a chart for the customer lens, a chart for the money lens, the pragmatic lens, the growth lens, the differentiation lens.
And then we think about, okay, are there specific lenses that are really important in this example?
That's going to help the founders help the decision makers see different ways of looking at the problem.
And usually when we have a bunch of different options, often there's one that's strong on many lenses or often there's one lens where when you go through all of them, you're like these are all important, but the one that matters the most to us, it's this one.
So it's a way to make difficult decisions a lot faster while still being thorough.
I like the concept of it too.
Like you talk a lot about things that resonate with me.
Going across biases, the way you laid on the book, I think it's really cool because you could see all these options like across from each other, it's like a mapping exercise for your team so you can actually evaluate it.
When do you think of those advisors?
Are you thinking that there are other team members?
Like when we think of product teams, we'll have an engineering leader usually that works with us, maybe a marketing person, are those people that would be on your team or are we going out and sourcing people outside our team?
It can be both of those.
So as we go through and make a chart for each of these, and so specifically, this happens on day two of the foundation sprint, we'll make a list of the options for that.
What are the approaches we could take to this project?
Not the specific details of the solution, not, oh, the button should be here, but that should be blue.
But what's the sort of approach?
Are we building a plugin for another company's software or are we building software of our own, and it's a chat based interface or are we building an app, whatever.
Like the broad approach, we're weighing the broad approach that we are going to take as a business and we're going to map out as we go through lens by lens.
It's wonderful if there's a person on the team who can be in charge of each lens.
So we can say, all right, Melissa, you're our business expert.
So you're going to tell us which of these you think has the most long -term value potential, which one has the largest potential audience.
And we're going to rely on you to score these and plot each option on those on that chart.
And then when we get to the marketing lens, well, maybe we'll ask the marketer to be in charge of that one.
But sometimes those folks aren't on the team and occasionally, a startup will bring in, founders will bring in a ringer.
They'll bring in a friend of theirs who has a particular expertise, and then that person would be in charge of it.
But honestly, sometimes you just have to go with what you've got and even going through and saying, okay, let's try to put on the hat of that person.
And they're not in the room, but let's imagine that there was somebody who was just standing on the table, beating their fist against the wall saying, we have got to grow.
We've got to grow. What do we think they might do as they rank these?
For startup founders, and I think it's true for product managers, they're wearing a lot of hats all the time.
And when that person who's a dedicated expert in that domain isn't available, you can usually rely on another leader to say, okay, I can take my best guess and it's going to help inform the decision.
Yeah. I like the fact that it just points it out.
It like makes you actually think about that topic as well.
Even if it's not your expertise, you're like, oh, I do have to consider marketing.
Like that's an important part.
Totally, yeah. And if you were having a conversation with me about something, I would get stuck on one lens and I'm doing this, all of these methods because there are problems that I've had to myself and I need a framework to remind me to be a bit more diligent and a bit more thorough before committing myself to weeks or months or years of work on potentially the wrong direction.
Yeah, for sure. When you're talking a lot about the concepts with this and design sprint, I'm sure some people are thinking like, Hey, this sounds a little bit like lean startup.
Where do you see the difference or the similarities between the two different frameworks?
Yeah. I would say it's mostly similarities, but with some valuable differences.
The similarity is in the philosophy, and the philosophy of the Lain startup and the philosophy that we think is the right one for folks who are starting out is to experiment.
To not assume that your prediction about the world is going to be true, but to run as many loops, we call them tiny loops, from your head to your customers as possible before you commit.
Because even in the world of AI, tools which obviously are allowing people to build much, much faster.
It's really important.
It's paramount. And it always has been, but I guess it's even more true now that you're building something that matters to customers.
That's different from the alternatives.
That's worthwhile. And running those experiments is the way you get there.
In the lean startup, people are often thinking of it's a minimum viable product is going to be our experiment.
and that's a smart idea to not build every possible thing you could, but build the thing that solves a problem in a meaningful way for the customer.
And it's the most important part that you can get out there and people will start using and paying money for spending their time on, that's great.
The challenge is often that getting to a minimum viable product, even though that's faster than building everything, still takes a long time.
And it's a long time to wait to find out if you're on the right track.
So I'd see this as a compatible philosophy.
We're just saying run those first sets of experiments over the course of the first weeks of the project and experiment every week.
So the foundation sprint is forming your hypothesis.
And then we run design sprints with our startups to get them thinking about, is that prototype working?
Is the hypothesis true?
And if it's not yet, is that because our solution isn't right yet?
Or is it because our hypothesis is a little off And so we'll see teams making adjustments on both sides of the ledger.
The prototype needs to be improved or changed or altered in some way, and or our hypothesis is a bit off.
We need to go after a different kind of differentiation.
We need to go after a slightly different customer.
And figuring that stuff out as quickly as you can in this one -on -one prototype phase, sets you up to do a much better job with your MVP, which in turn sets you up for that long term, the full product success.
Yeah, I see a lot of people gravitate to trying to over engineer a lot of MVPs or experiments, right?
Because they get that word product stuck in their head instead of thinking about it as an experiment.
But what I do like about your frameworks and what I try to encourage product people to do too, is I don't think there's something wrong with time boxing stuff once you get to a certain area.
But there's like this one thing I see people do, which I think is not the right concept.
And I'm trying to like back into this and I worked with So many organizations you'd be like, okay, we're going to have everybody sprint back to back throughout the quarter.
But the first week of the quarter is the design sprint or it's a discovery sprint.
And these take one week and you like figure out what you're going to do, and then you spend the rest of the time building it.
How do you react to that?
Let me put it out there.
I haven't seen that before.
And then how do you think about baking in the discovery and design sprints and stuff into cadences that are ongoing?
Clearing the first week of the quarter to design the thing before you start, it's certainly better than other things I've seen and experienced, which is like, we're just building all the time and try to catch up and figure out the product and bolt it onto what's already being built, because we can't have the engineers pause.
God forbid they should stop building.
And that's the genesis of a lot of mediocre products that nobody cares about.
We had to build something.
But a week is often not enough it's it happens that in one week you nail it and you run that test on friday of that week and customers love it it clicks to to do a book plug at the same time but like it happens sometimes it's not most of the time most of the time we see it take two to three sprints before something clicks and sometimes it won't even after you'll hit three and you'll be like okay now we're really sure that wasn't the right direction we're going to need to pivot and do a couple more.
But in 90 % of cases, if a team has a good idea as an expert team, they'll usually get there by the second or third sprint.
They'll start to see, yeah, we're feeling really good about this.
Let's start to use the prototype as the source of truth and start engineering a working product based on that prototype.
If you clear three weeks at the beginning of your quarter to run a foundation sprint, to run two to three design sprints, and you get done sooner, Like nobody's going to complain that they have extra time to build the thing.
But that's a hard switch for folks to make when so much of the way organizations work has been to optimize engineering.
And it's been that way for decades, everybody's head has been, and gosh, the engineers' time is so valuable.
We've got to optimize every second out of them.
I have seen how difficult it is for teams to change that way of working.
I hope that the pressure from AI and the fact that it allows us to build faster will encourage people to look at these, what may feel like a radical shift of clearing three weeks to get the product right because so often that engineering rush ends up just being months and years of building the wrong thing and the three weeks it would have taken to get it right in the beginning, it's a bargain when you actually put it on a scale.
I have a little illustration in the book.
It was just my sort of back of the napkin drawing of what it looks like If you're spending a year on something and what three weeks look like next to a year, a year is 52 weeks and most projects take a year or more.
Three next to 52, it's like nothing.
Yeah, anyway, I could go on and on, but I'm offering a bit more time at the beginning of a project decision.
Yeah, and I think it's great that you clear that up too, because I think sometimes people take stuff super literally and you're like, oh, you can do a foundation sprint in a week and or in like in a design sprint and they'll be like, oh, that's all you need.
Right, that's it. Totally.
Ship it next. And I hope people like understand that you might come out and realize that you're building the wrong thing.
Yeah, and I'm in a tight spot.
I'm always trying to pitch to people that look, this is really fast. It's not going to take you forever to do it, but I also want them to do it right.
And so the truth is, you take that three weeks or that month at the beginning and you're going to be in a great situation.
I also know that for teams for whom that's just, they're like, look the way the realities of my organization, I'm not there yet.
I don't have the sway yet to make that change.
If you run the foundation sprint, you will be better off than if you didn't.
If you have clarity around this as our hypothesis, if nothing else, having that hypothesis and showing it to people within the organization again and again, it makes it really clear the risk.
The hypothesis shows the risk.
So we believe that if we create this solution for this customer, it's going to be different in this way and it's going to matter enough to them they're going to choose it over and you list the competition.
That's scary to see spelled out.
And the problem is we rarely spell that out in such simple terms. I think people will see that.
And hopefully they will want to run tests.
Yeah, which is a good point.
And I think if you is true, if you have a leak, it's better than nothing.
So use it wisely. Yeah, totally.
For in the book too.
You have a ton of key studies of companies in here that you've worked with.
What's an example of one of them that you've worked with using the foundation sprint that Kind of change your perspective on where they started.
Yeah. We were arranging a time to have this call and you sent me a link using Reclaim and Reclaim is a calendar AI tool that helps to give you a little bit more focused time.
Hopefully I hope it's working for you in that way.
And so, you could have used all kinds of tools to set up your scheduling links.
Why did you choose Reclaim over Calendly, for example?
Like the 800 -pound gorilla.
I think I had Calendly.
So I had Calendly for a very long time.
And then what was happening is I had to go into my calendar and just be like, not these times.
Like I need time to actually work.
And what was cool about Reclaim is I could plug in like some habits or put my to -do list into it and it would block me off time.
And then it would show people all the available times around it.
Whereas Calendly, it was just like, oh, it's every day from nine to five and it's only in this section.
And it was, I had, I was responsible for going in and blocking off or making sure my calendar didn't get too full and I could actually like complete work.
So I thought Reclaim was cool because.
I could, I'm like, Oh, I would like time to go to the gym.
I would like time to go do this.
I would, I need to like write that proposal and it would just automatically find the best spot on my calendar.
And then when I woke up that day and looked at it, I was like, Oh, that's what I'm going to do today.
And I just went and did it.
Okay, cool. So that was a great, that was a great Reclaim testimonial.
So we're investors in Reclaim at our venture for our character capital.
So that was perfect.
But to rewind back to when Reclaim was building that feature, we ran a foundation sprint beforehand and they had some of the product already working and this notion that you create your priorities and it creates blocks on your calendar to help you with those priorities.
And it's something that a lot of individuals were using.
Reclaim to make their business sustainable we're trying to figure out, okay, can we figure out something that's gonna really help, not just individuals, but teams?
Because especially if you're working in a larger organization, so much of how your calendar is structured is dependent upon how your team works together.
And also can we make something that's so valuable that people will pay for it?
Because that's what's gonna make this a sustainable business for the long run.
And so we ran a foundation sprint and we were doing magic lenses, and they came in with a bunch of different approaches they might take to this challenge of one of the things we should build to really solve this problem well for delivering on this promise of protecting your time.
And the leading candidate they came in with was this concept called team analytics.
And so they were smart engineers who started the company and they're thinking about how much you can see about the way you work from analyzing your calendar, and what if you could analyze the way the whole team worked and deliver people some reports on that.
And it sounded really interesting, but they decided to do the foundation sprint and consider multiple approaches.
So they listed off other approaches they had thought of.
And one of those was no meeting days for the team and how do we make it so it's easier to create, no meeting days that work for everybody.
And one of those was scheduling links, which seemed at this time, this is a few years ago, it seemed people can just use Calendly.
Like it feels like it's a hard place to compete.
And so, we should list it, but it was like the, it was the runt of the litter when they listed all the options off.
So they start doing magic lenses and looking through the lens of growth, looking through the lens of which approach solves the customer problem in the best way.
And what's the most pragmatic approach for us in terms of speed to delivery is something that's high value to people.
And that smart scheduling length, sticky note kept appearing in the top right of every one of these two by two charts.
And so by the end of that foundation sprint, they said, It's clear that the thing we should try first is the smart scheduling lanes, we should run a design sprint to see what that would look like.
Because, hey, you know what actually that delivers on our unique differentiation, which is as you described it, we're going to start with what you care about and try to give you time for what you care about.
And this just turns out to be a really nice currency for doing that, these scheduling links.
And so that was their framework.
And they ended up running through a bunch of the features that scored well through these multiple lenses.
And in particular for them, there was this lens of what has the most potential revenue.
So that's one axis on the chart.
And what cures the most customer pain?
And if we do something that does both of those things, it's gonna be valuable to people cause they're willing to pay money for it.
It's gonna solve their problem.
It's gonna be something that's unique to us.
and they ended up growing and growing and growing after that and they were acquired by Dropbox not too long ago.
So anyway, I was thrilled when I saw the Reclaim link for you because that set up perfectly that case study but that's an example of how it looks in real life.
So cool. And I love the real life examples that you have in this book.
Jake, it's been so good talking to you.
If people want to buy Click, where can they go?
They should go to the clickbook .com if you want to get some bonus materials that'll help you run a foundation sprint you can get some bonus materials right away once you've ordered the book on the clickbook .com.
You can also, it's available everywhere.
So if you're on a Kindle or if you like audio books or whatever, you'll be able to get it through all of the normal methods.
And you can also check out character .vc if you're a founder and you're interested in learning more about working with us and running foundation sprints or design sprints directly from the source, but you can do it on your own.
It's just fun to do it with us.
it does sound like a lot of fun.
Thank you so much, Jake.
We will be putting all of those links at our show notes at ProductThinkingPodcast .com for our listeners.
So if you go to ProductThinkingPodcast .com, find Jake's episode, you'll see links to all of those things.
Thank you for listening to the Product Thinking Podcast. We'll be back next week with another amazing guest, and in the meantime, if you have any questions for me, go to DearMelissa .com and let me know what they are.
We'll see you next time.
