Episode 220: Designing Products That Click with Jake Knapp

Join Melissa Perri on the latest episode of the Product Thinking Podcast as she chats with Jake Knapp, creator of Design Sprint at Google, and general partner at Character Capital. Known for for his seminal book “Sprint”, Jake discusses nuances from his latest book, "Click," and emphasizes the critical role differentiation plays in product success.

This episode dives into the importance of starting product ideation with a clear differentiation strategy, ensuring that by the time you're ready to launch, you're not just another face in the crowd. Learn how to apply Jake's insights to make your products stand out from the rest, using the Foundation Sprint.

Want to understand how to make your product unique in today's competitive market? Tune in for some practical takeaways from Jake's extensive experience helping startups and established companies refine their product strategies.

You’ll hear us talk about:

  • 5:53 - The Power of Differentiation

Jake explains why thinking about differentiation should be the starting point of any product project, and how it connects to finding product-market fit.

  • 16:48 - Foundation Sprint to Design Sprint

Jake walks through how a two-day foundation sprint can set the perfect stage for design sprints, helping teams define their hypotheses and move quickly from ideas to testable prototypes.

  • 35:53 - Lean Startup vs. Design Sprint

Explore the similarities and differences between Lean Startup and Design Sprint methodologies, and why rapid iteration and experimentation are key to product success.

Episode resources:

Other Resources:

Follow/Subscribe Now:
Facebook | Instagram | Twitter | LinkedIn

Episode Transcript:

[00:00:00] Jake: 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've just had this insight that. You could apply the notion of design to the way that we work.

[00:00:29] 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 the story.

[00:00:54] PreRoll: 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 find your way.

[00:01:22] Think like a great product leader. This is the product thinking podcast. Here's your host, Melissa Perri.

[00:01:32] Melissa Perri: 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.

[00:01:52] 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 QuickBook 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.

[00:02:07] This is a segment of the show where you can ask me any of your burning product management questions. Go to dear melissa.com and let me know what they are.

[00:02:14] Melissa: Today's episode is brought to you by Liveblocks, 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 co pilots 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 count on Liveblocks to drive engagement and growth in their products. Join them today and give your users an experience that turns them into daily active users.

[00:02:51] Sign up for a free account today at liveblocks. io.

[00:02:55] Melissa Perri: Here's this week's question.

Dear Melissa

---

[00:02:57] Melissa Perri: 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, right?

[00:03:09] Who's your audience and 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 'em together. You might also have a view for different dependencies between the different products.

[00:03:24] You might want to do a view as well for sales so that they understand what's coming up and the rest of the company, what's coming up and 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.

[00:03:39] Executives may be the head of product, and they probably wanna 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 gonna ladder up to making meaningful progress towards our business goals, and how can I show that in a view, right? What do we believe these different products are gonna do to contribute to those business goals, which I call strategic intent. 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 gonna 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 would call options, some people call it epics on the teams. We wanna go up a level into initiatives. And in the initiatives they need 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, feature ideas or bigger product ideas, and then relate 'em back up to the strategic intents.

[00:04:49] So you want something that's like a portfolio road mapping tool to help you do this. I'm an advisor for a company called Dragon Boat 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.

[00:05:06] So whatever tool you do decide to use. You wanna make sure that it's at a strategic level that's not at the road mapping 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?

[00:05:23] 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 gives them 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?

[00:05:40] 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 gonna give you the information that you want. Then you're gonna 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 gonna have different views for the rest of the organization, maybe cross teams interdependencies.

[00:06:10] 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 wanna make sure that you're giving the right people the right information. And remember, there is no one view to rule them all.

[00:06:26] 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.

[00:06:34] Hey Jake, welcome to the podcast.

[00:06:36] Jake: Hey Melissa. Thank you for having me.

[00:06:39] Melissa Perri: 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?

Finding the gap before building

---

[00:06:57] Jake: I'm gonna take you all like way, way back to me as a kid because I, there's a connection for me. I started off as a a computer nerd, I started off as a baby, but as I got older to be 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.

[00:07:42] And when I I grew up and started working in technology that drive to create something that people love has just always been there. So I worked at Microsoft for a few years in the early two thousands, and then went to work at Google in kind of mid two thousands. And I was a product designer. I was building products and leading projects like Microsoft Encarta, which was an encyclopedia on CD rom a 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 in a big organization, you can deliver something that's much more complex and you could reach a lot more people.

[00:08:30] 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.

[00:08:52] 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 in, it just wasn't, it just wasn't quite right. And so I had been working on this project there for, at Google for a couple years, a side project.

[00:09:13] 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 is 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.

[00:09:35] And so we're working on it, but we're, 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.

[00:09:59] 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.

[00:10:15] 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.

[00:10:33] 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've 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.

[00:10:53] 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 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 wanna share it with more people.

[00:11:10] And that led to the Sprint book. That's the long backstory from Baby to Sprint book of how that happened.

[00:11:17] Melissa Perri: 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 your, did you get to keep your team in Stockholm? Did you guys

[00:11:27] Jake: They're still there. Yeah, they're there. And it's my anxiety that says that they were maybe gonna get closed down in 2009. I don't know if that actually would've happened but they're still there. So that's the good news.

[00:11:39] Melissa Perri: That's good. That means shipping valuable stuff.

[00:11:41] Jake: Yeah. Yeah.

[00:11:42] Melissa Perri: 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.

[00:11:51] Jake: Yeah.

[00:11:51] Melissa Perri: 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, that's how do we build products that 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?

[00:12:10] Jake: 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 Blee-Goldman, we started a venture fund of our own called Character Capital, and we started to have this experience of being a 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.

[00:13:00] Pre-seed 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're, we need to get that prototype into customer's hands, see how they react.

[00:13:22] We need to 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.

[00:13:41] But that conviction is often not crystallized into a hypothesis that you can then clearly test in the design sprint. And so we start 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.

[00:14:03] We want them to become successful. We want to do everything we can to help them find product market fit, but we also wanna do it as fast as possible because we know time is of the essence for them. We don't wanna 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.

[00:14:24] 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.

Foundation sprint and why differentiation matters

---

[00:14:39] Melissa Perri: 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?

[00:14:47] Jake: Yeah, definitely. So the foundation spread 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.

[00:15:14] 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 the 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.

[00:15:35] So we just spend a couple hours at the beginning defining those, making the basics really crisp. So that's the first half a 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.

[00:15:55] And we want to spend enough time on that, that we get really crisp about. What's gonna 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 gonna try first.

[00:16:25] 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.

[00:16:42] And that founding hypothesis is the perfect setup then for running design sprints.

[00:16:48] Melissa Perri: So the, your foundation sprint basically leads into your design sprint, is what you're saying.

[00:16:53] Jake: Exactly. Yeah. It's like one, one train car connecting right into the next.

[00:16:57] Melissa Perri: 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 make us define this in your foundation sprint. In your hypothesis, who is click for? Who's your target audience?

[00:17:13] Jake: That's a good question. Have I thought that through? Click 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 would really benefit from this way of thinking that is derived from what a startup needs to do to survive.

[00:17:43] 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.

[00:18:06] 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.

[00:18:37] Melissa Perri: 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 hone in on is the differentiation piece. And when I look at even internally in companies, a lot of product visions or sometimes company visions, and I'm like, you're a very large company, this should probably be a little more worked out here. But they don't have that differentiation piece, it doesn't talk

[00:18:59] Jake: Yeah.

[00:19:00] Melissa Perri: what you were trying to connect with, like the capabilities and the insights that we have.

[00:19:03] Can you explain to people you think about differentiation and what kind of model they should step through to get to that point?

[00:19:11] Jake: Yeah. Differentiation to me for a long time was just a kind of MBA word that didn't mean anything to me. And I'd seen, 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.

[00:19:32] 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.

[00:20:03] 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 gonna 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 gotta be dramatically better than what you're doing before or our brains just aren't gonna wanna 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.

[00:20:42] 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 yourself as fast as you can before you commit to building.

[00:21:00] 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 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 the story.

[00:21:34] Melissa Perri: Yeah.

[00:21:34] I see when people are writing like their product fission statements, which I think is similar sometimes with the format that I see to your founding hypothesis,

[00:21:42] Jake: Yeah.

[00:21:42] Melissa Perri: We'll get to the unlike these types of competitors and it's just lackluster. Sometimes it's oh, we'll be simpler. You're like, okay, but what do you mean by simpler? What,

[00:21:51] Jake: Yeah.

[00:21:51] Melissa Perri: that actually gonna be? And what I like about in the book is you do 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.

[00:22:02] 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?

[00:22:18] Jake: The thing that we do in the foundation sprint 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, look, 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.

[00:22:41] Some about 10 or 12 classic things that people generally understand. There are 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.

[00:23:05] 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 all, 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.

[00:24:06] And often what seems at first blush like, yeah, we can win on that. When you really get honest. You're thinking about it. You say, oh no, I don't. 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 gonna 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, do, does that differentiation matter? Can you deliver on that differentiation?

[00:24:41] Have you figured out the right form of your product that actually carries that story through? And that's when it gets really interesting, you start to see the scorecard where you're like, are, is it different enough on that axis? On that axis? And that's when we look for whether the product clicks.

[00:24:58] Melissa Perri: 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.

[00:25:14] If you're ready to level up your strategy skills, head over to product institute.

When you're setting up your hypothesis on there too, I see a lot of teams struggle with this and 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 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.

[00:25:51] Jake: I like to start with people where they are, and teams. I wanna 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 gonna do a little bit of discovery. We're gonna ask them about. How they solve this problem today? What do they use?

What goes on in their life? And we're gonna 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.

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 are 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. 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.

[00:28:30] Melissa Perri: In the foundation sprint, you also talk about this concept of magic lenses. That made me

pretty

[00:28:35] Jake: Yeah.

[00:28:35] Melissa Perri: 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?

[00:28:47] Jake: 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. 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, right? I've been, I've been thinking about this.

Spoke 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 and we wanna make sure that the things that we see, and we know that other folks on the team may not have the perspectives that we have, we wanna 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 gonna hear more from them and we're gonna hear less from other folks. And we're also gonna 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, 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 actually build and get in people's hands right away? There are other perspectives that you ought to have. But the thing is, on most teams, in most decision making situations, we don't hear all of those perspectives.

And even if we don't hear 'em 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 gonna 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 'em, 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.

[00:32:37] Melissa Perri: I like the concept of it too. Like the, you talk a lot about things that resonate with me going across biases. The way you lay It on the book, I think it's really cool 'cause 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 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?

[00:33:04] Jake: 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 the, what are the approaches we could take to this project, not the specific details of the solution. Not oh, the button should be here, and 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 a software of our own and it's a chat based interface? Or are we building, an app with whatever, like the broad approach. We're weighing the broad approach that we are gonna take as a business, and we're going to map out as we go through lens by lens.

It's wonderful if the, there's a person on the team who can be in charge of each lens. So we can say, alright, Melissa, you're our business expert, so you're gonna tell us which of these you think has the most long-term value potential. Which one has the largest potential audience, and we're gonna rely on you to score these and plot each option on those, on that chart.

And then when we get to the, the marketing lens, when 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 ranked 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, to say, okay, I can take my best guess, and it's gonna help inform the decision.

[00:35:05] Melissa Perri: 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

[00:35:15] Jake: Totally.

[00:35:15] Melissa Perri: important part.

[00:35:16] Jake: 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 too, 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.

[00:35:40] Melissa Perri: Yeah. for sure. When you're talking a lot about the concepts with this in 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? I

[00:35:53] Jake: Yeah. I would say it's mostly similarities, but with some valuable differences. The similarity is in the philosophy and the philosophy of the Lean 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 gonna be true, but to run as many loops.

We call 'em 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 are 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? 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, or our, and or our hypothesis is 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.

[00:38:17] Melissa Perri: Yeah. I see a lot of people gravitate to trying to over-engineer a lot of MVPs or experiments,

[00:38:23] Jake: Yeah.

[00:38:23] Melissa Perri: they get that word product stuck in their head instead

[00:38:26] Jake: Yeah. Yeah,

[00:38:26] Melissa Perri: 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. And I worked with so many organizations who'd be like, okay, we're gonna 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 gonna do and then

[00:38:56] Jake: Yeah.

[00:38:56] Melissa Perri: the rest of the time building it. How do you react to that? Lemme put it out there. Have you seen that before? And then, how do you think about baking in the discovery and design sprints and stuff into cadences that are ongoing?

[00:39:08] Jake: 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 on to what's already being built. 'cause we can't have the engineers pause, God forbid

they

[00:39:27] Melissa Perri: Yeah.

[00:39:27] Jake: stop building.

And that's the genesis of a lot of mediocre products that nobody cares about. So we had to keep, 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 that 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 gonna need to pivot and do a couple more. But in 90% of cases, if a team has a, 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 gonna complain that they now 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 engineer's time is so valuable, we've gotta 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've 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 of, it's 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's, 52 weeks, and most projects take a year or more.

3 next to 52. It's like nothing. Yeah, I, anyway, I could go on and on, but I'm all for a bit more time at the beginning of a project decision.

[00:41:47] Melissa Perri: Yeah. And I think it, it's great that you clear that up too. 'cause I think sometimes people take stuff super literally and you're like,

[00:41:52] Jake: Yeah.

[00:41:52] Melissa Perri: a foundation sprint in a week

[00:41:54] Jake: Yeah,

[00:41:54] Melissa Perri: or, and like a, in a design sprint, and they'll be like, oh, that's all you need, right? That's it. That's

[00:41:58] Jake: totally.

[00:41:59] Melissa Perri: Ship it next

[00:42:00] Jake: Yeah.

[00:42:00] Melissa Perri: I hope people like understand that you might come out and realize that you're building the wrong thing.

[00:42:06] Jake: Yeah, and I'm, I'm in a tight spot. I'm always trying to pitch to people that, look, this is really fast. It's not gonna take you forever to do it, but I also want 'em to do it right. And so the truth is you take that three weeks or that month at the beginning, and you're gonna 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 is 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 gonna be different in this way, and it's going to matter enough to them that they're gonna 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 will hopefully they will want to run tests.

[00:43:12] Melissa Perri: Which is a good point, and I think if you, it is true. If you have a week, it's better than nothing. So use it wisely.

[00:43:18] Jake: Yeah, totally.

[00:43:19] Melissa Perri: 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 changed your perspective on where they started?

[00:43:30] Jake: 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 focus 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 of scheduling links.

[00:43:59] Melissa Perri: 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.

[00:44:08] Jake: Yeah. Yeah.

[00:44:09] Melissa Perri: 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 was just like, oh, it's every day from nine to five. And it's only in this, 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 am like, oh, I would like time to go to the gym. I would like time to go do this. I would, I, 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 gonna do today. And I just went and did it.

[00:44:48] Jake: Okay, cool. So that was a great, that was a great reclaim testimonial. So we're investors in reclaim at our venture firm, 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 were, 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, 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: what are 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, you know, really 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, 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 gosh, 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, something that's high value to people And it, that smart scheduling link, 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 links. 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 are gonna 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 through scheduling links. And so that was their, 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 from you because that's set up perfectly, that case study. But that's an example of how it looks in real life.

[00:48:26] Melissa Perri: 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 wanna buy Click, where can they go?

[00:48:33] Jake: They should go to the theclickbook.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 theclickbook.com. You can also, it's available everywhere, so if you're on a Kindle or if you like audiobooks 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.

[00:49:07] Melissa Perri: 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 dear melissa.com and let me know what they are. We'll see you next time.

Melissa Perri