Transcription
All righty, thanks everyone. Uh, we're live! Dan, thank you for coming. Uh, we're really excited to kick off PM Learning Week with this discussion on product strategy.
Before we get into it, Dan, we're really thrilled to have you here. Dan's a best-selling author, a trainer, a consultant. Uh, before that, why don't we start with you telling us a little bit about yourself and how you got into this?
Thanks so much for having me! I'm excited to be here with all the folks at Google.
Yeah, so my background—luckily, my parents got me a computer when I was young, so I coded in like BASIC and assembly. You know, I was an electrical engineering major, and then my first job out of college was actually designing nuclear submarines, which was a cool job in the Navy. It's kind of like NASA for submarines—nuclear-powered submarines. It was awesome! I had a lot of responsibility.
After doing that, they kind of paid for school, so I had to do five years doing that, which was a great five years. I wanted to go to business school, and so that's what brought me out here to the Bay Area to go to business school at Stanford.
At school, I was trying to figure out what I wanted to do after graduation because I had only worked in the Navy. I started hearing about this relatively new career—product management. The more I learned about it, the more I thought, "That sounds perfect!" Because you're not actually doing the coding or engineering, but you're working with them. You're sitting between customers and the dev folks.
So I asked everybody, "Hey, where's the best place to learn product management?" Because I'd never done it. At the time, everyone pretty much unanimously said Intuit was one of the top companies. You know, there was Microsoft and Yahoo as well, but basically, Intuit was the one.
I got fortunate to get a job at Intuit, just, you know, buildings were there. And funny, back when I was there, I think Google had two buildings behind us—Epsilon and Pi, I think. Anyway, it was funny.
So I worked on the QuickBooks team. Did you ever wander into the Google campus by mistake?
No, no. It was kind of like you couldn't easily get over there. It was in the parking lot behind it, so I was just like, "Oh, look at what are those guys doing over there?" You know? And now, of course, your campus is way bigger than Intuit. It's hilarious!
But it was a great place to learn product management, product development, and marketing. I kind of got promoted and worked on different products there. After doing that for five years, I wanted to take what I learned and apply it at startups.
So I went to a couple of startups, helped a friend with a startup, and I was head of product at a couple of startups. After the second web startup that I did, I was like, "Okay, the web's here to stay. I'm a technical person; I just don't know how to code this web stuff." So let me just go rip off the Band-Aid and buckle down.
I went and took HTML, CSS, JavaScript, PHP, Unix, Apache, Photoshop. I was like, "Let's just get this done!" And that's kind of how I stumbled into being a consultant.
I got an offer to be head of product at a startup, and they were like, "Hey, we want to make you VP of product." I was like, "I love what you guys are doing; I'd love to join you, but I'm literally taking 20 hours a week of classes. Can we work out some part-time deal?" So that's how I became, you know, everyone hears a lot about fractional CPO today. I did that back in 2005 before we had a name for it.
Yeah, before anyone was even using CPO, it was like VP of product. So I did that, and then I did it for another company. I'm like, "This is actually pretty fun," because one of the side effects was it accelerated my learning. I was working with more than one company at a time.
I worked with Box—some of the unicorns I worked with were Box in 2007, so usually post-Series A startups that didn't have a head of product. I got to work very closely with the Box team in the early days. Then One Medical Group is another one, and then Medallia is another one in the B2B space.
So anyway, along the way, I got into actually when Facebook came out with their platform. It was the summer of 2007 when they announced their new platform for apps. BJ Fogg, a professor at Stanford, quickly scrambled and said, "We're going to do a Facebook app development class." Like, it was literally then, right?
One of his co-professors, an assistant professor, knew that I had worked at Friendster as head of product management, and I had done viral growth and covered product management. They asked, "Hey, can you come in and give a talk on PM and viral growth?" I was like, "Sure!" So it was the first time I ever created slides—in 2007 or 2006, something like that.
And then I just kind of spoke at conferences, and I was consulting. Actually, Google's partly the reason my book came about. Ken Norton at Google Ventures invited me to give a talk at Google Ventures, kind of like a setting like this. That talk got on YouTube, and then the editor saw that talk and pinged me out of the blue and said, "Hey, we thought about writing a book."
So anyway, thanks to Google for helping that!
I didn't know Ken was part of that!
Oh yeah, Ken was part of it!
And then since the book came out, I basically have switched more into training. Also, in the last several years, PM has just exploded.
Yep.
So there are all these PMs, and there are not a lot of training opportunities. I do a lot of private training, a lot of digital transformation for companies as well. So that's kind of how I spend my time.
The last thing that I do is almost 11 years ago, because there was not much community when I was coming up in product management, I started a Meetup group called Lean Product Meetup, where each month we host a speaker. It's actually added to it.
During COVID, it was virtual, but now it's back, so we do hybrid events. Each month, I hold—I’ve had Ken speak there, Marty Cagan has spoken there—all the top speakers have spoken.
So anyway, awesome! And Product Leader Summit too, which you know about, is a once-a-year event.
So yeah, I'm just all about sharing best practices in product management.
I thank you for that! I think a lot of people here also enjoy what you do online, so thank you for doing that.
Yeah, all right! With that, let's get into our topic for the day—product strategy.
Now, I think as PMs, we all sort of think an important part of our job is defining the strategy for our products. Given that, why is it so hard to see good product strategy? Why do we see it so rarely?
It's a great question! It's a great question. And since we have product people here in the room and online, I would be remiss if I didn't share one of the most closely guarded PM secrets that are out there—the PM motto.
Do people here know the PM motto? Does anyone here know the PM motto?
Did you know it yet?
Okay, it's a bit like Spider-Man's motto. Do people know Spider-Man's motto?
Really? No Marvel fans at Google?
With great power...
Yeah, that's right! With great power!
See, Spider-Man's motto—everybody knows that one. The PM motto is similar; it's just a little different. It's "With great responsibility comes great power." Because we are responsible for product success and product strategy, but no one reports to us, right?
So we have to, like, as Ken used to say, "bring the donuts for the engineers," right? How do you bribe and control and plead and get resources?
Anyway, I just wanted to put that out there. But back to your question, I think there are a few reasons.
One is a lot of teams don't even aspire to. Yep, they're so stuck in tactical execution, whether it's, you know, this sprint or this month or this quarter. It's perceived as a luxury to kind of pull your head up and think longer term, right?
So that's one. The other thing I think is that people don't have a framework. So even if you're like, "Okay, I'm game to do one. I'm going to carve out time in my schedule to create a product strategy," they don't have a framework to apply.
So I'm going to share with you a framework. We're going to solve that problem today. I'm going to share with you a simple, easy framework that you can use with your product and share a couple of examples.
So those are kind of the two biggest reasons that I see. But I would love also to, you know, hear what you guys think.
When you hear about everything, I think it's a ill-defined term—strategy. I've been reading a lot of strategy books lately. None of them are product strategy books; they're business strategy books.
And strategy basically is this word that can mean anything to anybody, right? People like mission, vision, value, strategy.
So I'm curious here, what would you say when you hear "product strategy"? What comes to mind? Like, what kind of aspects or terms come to mind?
Would you say, you know, it's going to be interactive, but it is?
Yeah, let's say no wrong answer. What do y'all think?
If you had like a junior PM on your team, what would you say?
You got a series of concerted investments that you make across different areas that are in service of solving a common problem, leading to a goal that you could measure.
Awesome! Wordy, but good!
Yeah, it's okay. It's okay. Well, I thought that that's a good one.
So for me, these are kind of the key points. It's like your plan for how you're going to win, right? So strategy implies there's some competition or some goals, as you were saying, that we're trying to accomplish.
One of the major criticisms in the books that I was using is like a lot of times people say what their goals are, but they don't say how they're going to get their goals. Like, what are the decisions that we need to make?
At the end of the day, I think it's decision-making. A lot of times in the PM world, we admonish people, like, "Make sure you're customer-centric. You got to be customer-centric." And I agree with that, right?
Intuit was one of the few companies that successfully fended off Microsoft because they tried to take us out of business too, like they did with Netscape and WordPerfect. But we were so customer-focused and close to customers.
But I do think this is where it's important to take into account the competitive landscape when you're doing your product strategy so you can get clear on the differentiation. And we'll be talking more about that.
The other thing I touched on quickly is long-term versus short-term. For me, this is the key, right? If you're like, "Yeah, we're doing a strategy for next month," I don't think that's a strategy. Or next quarter.
Now, conversely, you can go, "Yeah, we're doing a 50-year strategy." You can go too far, right? It's like, "Well, that's probably going to be invalid."
And then finally, my favorite definition of strategy is what are you saying no to? Because if you're saying yes to every stakeholder and every request, I would argue you're not being strategic.
And this is where I like to share Steve Jobs' quote about focus, where he says people think focus means saying yes to the thing you're focusing on. But that's not what it means at all. It means saying no to the hundred other good ideas that there are, right?
Innovation is saying no to a thousand things. And I just paraphrase it. For me, strategy means saying no.
And look, it's easy to say no to dumb or bad ideas. That's not the hard part, right? But he even says a hundred other good ideas. He's acknowledging we have way more good ideas than we have time to do, right? That's basically it.
So yeah, given all of this, though, right? Like, I always wonder, how do you—so given all this advice, right? Like, let's say you're a PM. You have this zone of short-term versus long-term. How do I say no to things?
Right? What advice do you give people? Like, how should you approach this?
By the way, I think Google's great as an example. I bring it up all the time, right? We all know the 70-20-10, yeah, right?
So just to be really clear, my parsing of it is 70% of resources and investments go into, you know, the core business this year, like in the next 12 months, whatever.
I think about it as an MBA from a finance standpoint. We expect those 70% resources to deliver results in the next 12 months.
Then we have 20% that is like expected to build, plant the seeds now for things that are going to generate revenue post-12 months. And they have 10% for like moonshots—just roll the dice, experimentation.
That is awesome! And those last two categories are frankly that long-term part. Many of the companies I work with, they're like 95-5—95% short-term, maybe 5% beyond 12 months, right?
Especially if you're a public company, right? Or honestly, some of them are like 99-1. You know, it's kind of—they don't even have the luxury of that moonshot thing, right?
So some of the advice I like to give is one—and this will be for people that are familiar with my book—is to ground your strategy in customer problems or needs, right?
We all kind of see feature checklists that the sales team might be showing, like you're comparing feature checklists. And it's really not about copying other features; it's really about getting back to what our customer needs and problems.
So that's one of the key things. The other thing is to get clear on your time frame when you're doing a strategy. I run these workshops, and if I tell them, "Hey, we're going to do the strategy for three years versus one versus five," you get different answers, right?
Because back to your thing, I do this case study for Airbnb where we pretend we're the founders, and people come up with this grandiose strategy. I'm like, "Okay, you have four people at your startup. How many months of runway does a typical startup have?"
"Oh, you know, about 12-18 months."
"Yeah, okay. How are you going to achieve all the things you just said? Can you do that in 18 months?"
And they go, "Oh, we can't really do that in 18 months," right? So it's got to—that's where you kind of ground in the resources, like you were saying.
So real quick about the customer needs and problems. I just want to quickly—I've been talking about this idea of problem space since the 2000s. Who's familiar with problem space here? People heard this term?
Cool! So I'm excited that you see it more and more. But I want to explain the difference between problem space and solution space because it's really critical for strategy, right?
So problem space—and they're kind of like two sides of the same coin—but problem space is basically a customer problem, need, or benefit that the product should address.
Sometimes people get tripped up in the product world. We get really picky about our language. Is it a need? Is it a want? Is it a job to be done? Is it a pain? Is it a user story? What? They're all the same thing, right?
They're all just kind of like, "What value is going to be created for the user?" And the template we all know—this is, you know, I ask people what you know the agile template, right?
"As a blank type of customer, I want to be able to do blank so I can enjoy blank benefit." Most people know that, right?
And that, as that essence of the problem space, is that. So, why would a customer care about this? What would be the value for them?
In contrast, solution space is a specific implementation or design to meet the need. And the reason I bring this up is because far too often, teams go rushing into solution space.
Like, "Hey, we should build this feature!"
Yep!
"Hey, we should do this!" Right?
You know, so over here is the problem space. It's like, "Okay, what are we trying to solve?" So you're going to map between the two, but you want to start in problem space.
So one of the top reasons I like to point out why products fail—you hear these statistics like over 80% of products fail—is because they never were clear on the problem. They jump straight to solution space, and that's where the risk got taken.
Like, we assume that, "I thought if we built this cool thing, you know, it would be—people would love it." And they just see it's cool, and they like, "If you build it, they will come," kind of a thing, right?
So anyway, you want to ground your strategy in problem space. Just to kind of be, you know, have more detailed talks online, but this is an example of a problem space definition, what I call for TurboTax.
So it only has two levels. The top-level things are what we call benefit ladders—like improve my confidence, save time, save money.
So TurboTax, most people probably familiar with it. Most people use it around April. I did a six-month extension, so I just used it, so it's fresh off my mind. You know, March—I used it in March.
It's good, right? I was talking to the TurboTax product manager, and because it's so easy and convenient to file, the time of when people file has been moving closer to the deadline.
But anyway, it's all about doing your own taxes, right? So three high-level benefits: improve my confidence, save time, and save money.
And then there are child benefits to those, right? So anyway, the interesting thing is when you have a clear definition of your problem space, almost any idea the team comes up with is just another way to make people feel more confident about their taxes, another way to save them time on their taxes, another way to save them money, right?
Every once in a while, you add a new ladder or swim lane to your strategy or roadmap, which is exciting, but there's plenty to be mined here.
So you want to anchor your strategy in this. That's basically the main—so those are two things there: pick your time frame and start with problems as the high-level advice that I have.
Yeah, I do think in Google in particular, sometimes we get so excited by the technology, we start in solution space.
And so I do think it's a reminder for all the PMs here, right? Like, that is something to sort of keep in mind. Does that sound familiar to this group?
Lots of nodding heads!
All right! And by the way, the message is not, "Hey, don't ever think about solutions." That obviously is—we need to get to solutions, right?
And in fact, the Venn diagram of problems and solutions—like, what can technology do? But always tie it back to what problem can it solve, right?
That's basically—we just want to get clear on the problem and then brainstorm solution ideas, right?
And if you find yourself on a future team and someone says, "I think we should do feature X," that hopefully a little yellow flag will go off in your head.
Like, "Hey, they just proposed a solution." That's fine! We're not going to shame them. We're just going to be like, "Oh, hey, can you help? I hear you saying we should build feature X. Can you help me understand how's that going to benefit the customer? How is that going to create value for the customer?"
To get them to hopefully be more explicit about whatever problem that is—a great tip for your next exec meeting in general!
All right, with that, as we approach these, what are some frameworks that you know you use, that you recommend we use, to think about?
I'm going to share with you a simple, easy-to-use framework, right?
And it started—so one thing I didn't mention in my bio is before I moved out here to go to business school at Stanford, I got a master's in industrial engineering at night.
And that was super cool! It's kind of like a mini MBA. I learned operations research, Markov chains, queuing theory—it was super cool! And stats—I learned a lot of statistics, which is really important these days.
But one of the classes I took in quality, they explained the Kano model. And so for me, that's kind of one of the foundations I'm going to use to—and then I'll show you the product.
So the two things are the Kano model, which I'll explain, and then how you use that in a simple product strategy grid to get clear on your product strategy.
And so my goal, as always with my talks, is as soon as you leave this room or this webinar, you can go and say, "Cool! I'm going to go apply the Kano model and build my own product strategy grid." You can do that like as soon as you get on with this talk.
That's what I want to do—to set you up with those specific tools.
So the Kano model came out of Professor Kano from Japan. It came out of like the automotive manufacturing movement, where Japanese cars were higher quality than U.S. cars.
And so it was like a way to think about product quality. And it's interesting because it talks about customer needs and satisfaction.
So I don't have time to get into my importance versus satisfaction framework, but I love it because it resonates with that.
So let me explain it real quick. The Kano model has two axes. The horizontal x-axis is for whatever need we're talking about. You can refer back to that TurboTax example—saving time on your taxes, saving money on your taxes, feeling confident, getting a better search result, creating a document more quickly—whatever that customer need is.
How fully is the product meeting the need? On the left side, it doesn't meet it at all. You can think about a 0% all the way to the right side, 100%, right?
So it's always a function—if I'm a geek like that, it's a function of the need. Everything's a function of the need, right? So that's the x-axis.
The y-axis is, okay, as a function of how well the product meets the need, how much user satisfaction or dissatisfaction results is created by that, basically.
Now, if this seems kind of complicated, the cool thing about the Kano model is it's really a categorization framework. Once you've decided—once you've agreed on your problems-based definition, you've got a list of customer problems.
Now we're just going to categorize them. And there are three useful categories—there are a couple others, but they're kind of irrelevant.
The first and easiest to get your head around is performance benefit or feature. And the way to read this is left to right. As a product meets the need more and more, it creates more and more customer satisfaction or value, right?
So more is better, less is worse. If we were in—you know, Apple just came out with M4 chips, right? Or the new iMac came out today, right?
So say that chip outperformed the other chips by 20%. Then we clearly would be outperforming by 20%, creating that much more value, right?
So the way you know you're talking about performance benefit is you can quantify it somehow. You know, our search is X percent faster; it's Y percent more relevant—whatever it is, right?
People can achieve their tasks at 10% better productivity. That's the idea.
Another one is, say, like, say we're shopping for a car. I was shopping for a car, and I saw two cars. They looked about the same, but like one car—all the specs were the same on the sheet, the price was the same, I liked the way they looked about the same—but one car had twice the miles per gallon of the other car.
All other things being equal, I'd pick that car, right? So performance—more is better, less is worse. And that's frankly where most of the competition happens in your product strategy.
You should be thinking about how can I outperform the competition, right?
The second category is a must-have benefit or feature. Now, must-have, I know, is a term that can get thrown around loosely by key stakeholders.
"We must have an account! We must have this feature!" That's not the definition of a must-have. A must-have in the Kano model is actually—let's start at the right.
Let's assume for a minute the product fully 100% meets the must-have need. It doesn't actually make the customer happy, right? They're expecting it to be there.
The way it works is as you fail to meet the need, it makes them increasingly unhappy. That's the Kano model definition of a true must-have, right?
So for example, if you were doing something that required fintech or something that required secure transactions, and you had the right kind of secure transactions or cryptography, they wouldn't be long, "Yay! My bank stuff is secure transactions! Great!"
They expect that from a financial thing, right? Or if you're in health tech and you have HIPAA, no customer is going to be like, "Wow, you have HIPAA! Cool! I'm going to sign up for that!"
Right? So those are the kind of—it's kind of like those must-have things. It's not about, "Well, our competitors have it, so we have to have it."
Right? That would be more of a performance matching kind of thing, right?
So again, if we go back to cars, say I went in looking for a new car, went to the showroom, saw some car I thought looked great, price was great, I looked at the spec sheet sticker on the window, everything looks great.
But then I peek inside, and for some reason, this car doesn't have any seat belts. I wouldn't buy the car despite all the other amazing stuff because it doesn't have seat belts, right?
But if car A has five seat belts and car B has 100 seat belts, I don't say car B is 20 times better, right? Once you have one seat belt per person, you tap that out, right?
So that's the must-haves. And you don't compete on must-haves. You just have to have them. You cannot compete on them.
One thing I see teams make mistakes on, more at startups or not always, but is, "We are behind schedule. We underestimated the scope. We said we were going to launch this on November 1st, so we'll just cut features. We'll just launch the MVP with the must-haves."
This tells you right here you're not going to create any customer value. No customer is going to do, right?
And then, because of those timing pressures, you launch it, and then it doesn't do well. They go, "See, this didn't work! All MVP didn't work out! Let's go back to Waterfall!"
And the last category is delighters, also called wow features. Now, on the left side, if you don't have a delighter, it doesn't cause a problem because no one's expecting it to be there.
But if you have a delighter, it can create a lot of positive customer satisfaction, a lot of value, right?
So sticking with cars—not today, but when the first cars came out with GPS navigation built in, right? Years ago, that was a delighter.
When we can say, "What problem did it solve?" The problem it solved is how to figure out how to drive to where you want to go. Before that, you would use a map, or you'd ask for directions, or you'd try to wing it.
You know, and then now with the new GPS, you just put in where you're going. It fundamentally made it way easier to get from point A to point B.
But over time, so it was a delighter, right? But over time, more and more cars had GPS navigation built in, and TomTom and Garmin came out with their units.
In fact, all the cars still have it built in, but nobody uses it. We all use Google Maps on our phone, right? Because like, it's way better, right?
So it's not a static picture; it's a dynamic picture where the needs and features migrate over time. So that yesterday's delighters become today's performance, become tomorrow's must-haves.
And the pace with which that evolution happens just depends on the level of innovation and competition in your space.
So why am I telling you this? All you need to take away from this is, hey, there are three categories of customer problems or needs: there are must-haves, performance, and delighters.
You don't compete on must-haves. We're mainly going to compete on performance, and if we can come up with some unique delighters, that's great.
And what you'll find is time and again—I'm going to share a couple of examples—if you have one clear outperforming, you're outperforming your competitor on a really important dimension or attribute, plus sprinkle in a little delighter, that is enough to create enough delta customer value that you're going to take market share and you're going to be the product leader.
So we'll share some examples of that.
So now that you know these three categories, the second framework where it all comes together is what I call the product strategy grid.
Okay, so all we're going to do is just a table grid where we list—and I've kept it generic, and we'll talk about some specific examples—you list one per row for your category, for your product category.
What are the must-have benefits? What are the performance benefits? And what are the delighter benefits? That's step one, right?
The other thing, part of step one, is what time frame are we doing? Is this going to be a three-year project strategy, one year, two years, five years? Because that's important, right?
Then what you do is you create a column for each of your key competitors. You know, I'm showing two competitors here—A and B. And you could have, you know, you don't want to have 20; it's probably a little busy.
But you can have several, and then a column for your product. By the way, when we say competitor, a lot of times companies will be like—or product teams will be like, "Hey, our competitors are this other tech product."
But sometimes it could be Excel, or it could be like duct tape and Band-Aids or bubble gum. Like, you know, it's like really—how are people getting that need met?
So it's kind of like a broader view of that. And then you call it for your product.
Then the next thing you do is you score how good a job is each competitor doing on each of these benefits. And honestly, low, medium, high is usually adequate.
You know, if it's a performance benefit and you want to put in like, you know, CPU gigahertz or something, great! If you want to put the number in, by all means, put the number in.
Or search result time, or if you have some search quality, you know, relevance, something like that, by all means, you can put the number in.
But high, medium, low—as long as the ratings make sense across the row, that's what matters the most, right?
Now, you'll see I use yes or no for must-haves. It's kind of like you can use high, medium, low, or you can just use yes or no.
And usually for delighters, you can also just use yes or no.
So now you want to get to this point, and now imagine this was our product. What should our product strategy be?
And what you're trying to find is what row, especially a performance row, can we be the best at? That's really what you're looking at, right?
And so if you look at this, this is a common strategy. It's okay, well, competitor A is best at performance benefit one, so it might be hard to beat them.
Competitor B is the high performance benefit two, so unless we can go higher than them, but they're both medium performance benefit three, so that's ownable.
Now, whether we can own or not, I don't know, but at least theoretically, that's something where you could come in at high, right?
Or you could convince yourself why you're going to be higher than the other people, right? So given this backdrop, we might go with the product strategy like this.
Of course, we're going to have the must-haves. We're going to try—we're not going to try to be better than competitor A on performance benefit one. We're going to be medium.
We're going to say no, like Steve Jobs, to performance benefit two, and we're going to try to be the best on performance benefit three, right?
The other two competitors are medium. Maybe we've identified a market segment that really values that benefit, right?
Or maybe we have some specific solution space ideas how we can deliver higher levels of value or satisfaction on that dimension than the competitors, right?
That's where the tech comes into play. And then we have an idea—competitor A had their delighter benefit; we have an idea for our own delighter, right?
The whole point of doing this exercise is to come up with what's called your unique differentiators, which is what performance benefit—and usually it's just one—are you going to be the best on, and any unique delighters that you're going to have, right?
And if you keep going down the lean product process from my book, we want to get clarity on this because now when you get to this point, you can say, "Great! Now let's brainstorm all the solution space future ideas for how we're going to deliver high performance on benefit three and all the solution space ideas we have for how we're going to deliver delighter benefit two."
And then we'll spec out an MVP. Hopefully, we'll prototype it, and we'll get feedback because this is a hypothesis at this point.
Hopefully, it's informed by research, but the kind of the rub meets a row when you have that prototype of your value prop of your product strategy, and you test it, and you get validation.
"Oh yeah, people really do see that we're delivering higher performance on three and the delighter." Then you can go code that thing confidently, and you know if you build it, it's going to deliver on that.
So anyway, that's the framework, right? The Kano model has the categorization, and then you just create this—you can create this simple grid.
I've kept it relatively simple. Sometimes you can double-click; you might have an overall performance benefit. You might have, you know, children of that. It can end up being a longer, you know, spreadsheet.
But anyway, I like what you said about—there's a hypothesis, but you need to prove it out to yourselves and then sort of convince yourself before sort of—and that's part of the strategy as well, right?
Are there examples that you know you feel like, "Okay, they applied this, and this worked"? Like, are there ones that you like?
I do, and I'm going to share them with you. I feel like a product archaeologist when I look for these examples, right?
Because you don't know after the fact, like, while you got all these product teams and companies, are they just throwing spaghetti at the wall, and some of them got lucky and it stuck or not? You know, so hindsight can be—oh yeah, they were geniuses; they knew what they were doing the whole time, right?
Sometimes not like that. The stories get a lot better.
Oh god, oh yeah!
So what I love is this—it's funny because what happens is a pattern is after a startup has been successful, sometimes the founders will be like, "I'm just going to post our Series A pitch deck so everybody can see what—yeah, like, ha! Remember when we were little? We didn't know what we were doing; we were unsuccessful! Ha! Check out this pitch deck!"
Right? So it's kind of—and so I second anybody does that, I go looking through the slides to be like, "Is there anything that gives me the raw data to try to recreate a product strategy?"
Because of course, they're not going to have it in exactly a product strategy format, but I'm like, "Is the thinking there or not?"
And so one of the examples that I think is like chef's kiss A+ is Instagram.
Okay, so Instagram—but not this Instagram, right? We have to get in Hot Tub Time Machine and go back to 2010 when this was Instagram.
Because let me tell you the story of Instagram. So when they launched in 2010, they were a mobile photo-sharing app. They were not the first to market; it was already a crowded category with plenty of other mobile finishing apps.
But what happened? After they launched, they got tons of users. They quickly became number one, and they haven't really looked back, right?
Now, I would argue anytime you see a new product enter a crowded market, crowded category, and become number one and take off like a rocket ship, you must be able to figure out what was it in the product strategy grid that they have to have outperformed the other people somehow and/or have some unique delighters, right?
So what I want to do with this group is try to see if we can recreate that. So not Instagram today, but when it came out in 2010, how did it outperform the other photo-sharing apps?
What are some things that it did outperform or delight? Like, if anybody here was an early Instagram user, I know they've had a lot of features since then, but what do people—what are some ideas people have?
Simplicity!
Simplicity, okay! What was the other one?
Likes!
Okay, I think the other folks had social likes as well, and simplicity is a good one. I think, you know, any other unique things they had?
The filters!
That's exactly right!
Yeah, right? So if you now—we kind of take it for granted, but when it first came out, part of why it took off was like, "You're like, how did his photo look so good? What did you do?"
Right? You know, wow! You know?
And so back to this solution space problem space, let me ask you this: are filters a solution or a problem?
It's a solution!
That's fine! It's totally fine!
So then I go, "Okay, as an early Instagram user, why were filters valuable to you?"
What would the answer to that be?
Yeah, great! Yeah, it could make my photos look better, make my little photos look more creative, make my photos look more professional—a lot of different nuanced ways of basically saying, like, an umbrella statement of make my photos look better, right?
Right!
So the benefit is make my photos look better, supported by the solution features.
Now, when it came out—when it came out, was it a must-have? When filters came out, were they must-have, performance, or delighter?
Or a delighter! Because nobody else had it, right?
You know, it's funny. I give this talk, and I like, "Yeah, I love the sepia filter! That was my favorite one!" You know?
Like, "Okay, cool!"
Right? So yeah, so that's basically it.
But remember the thing—what if we were to launch a photo-sharing app today in 2024? Would it have to have filters?
Yeah! Unless you were doing some cool retro thing, it would be kicked out of the—it'd be laughed out of the app store, right?
So they started out as a delighter in 2010, but then they quickly became a must-have.
So that's that evolution over time, right? People can copy your features.
So totally! So we got—and I think that was a big differentiator for them.
The other things are a little more subtle. So that's a delighter.
So we got the delighter; we're looking for performance benefit, which is something you can quantify—something quantifiable about the product or user experience of early Instagram compared to the other social mobile photo-sharing apps.
Any thoughts people have? It's kind of related to simplicity; it's a little more detailed than that.
Any thoughts people have?
What's that?
It was a quick share!
That's right!
So the way that these apps work, you know, you'd launch the app, it would have the embedded camera, you line up your shot, you take your shot, and then you can do whatever—filter, tagging, you know, whatever you wanted.
And then you would click share or upload, and then it would upload. And back then, we had like, you know, slow 3G going on, and so it took like five to eight seconds for that photo to upload to the server, right?
So if you took a stopwatch on all the other apps and you just timed it, it would be five to eight seconds. But when you did it on the Instagram app, it would be two or three seconds faster than the other apps.
Now, we have some technical folks in the room. You probably say, "Wait a minute, Dan! The apps are running on the same hardware with the same photo, so the photo file size is identical because it's that—they're using the same bandwidth, either 3G or Wi-Fi, so that can't be the difference."
Do they have some crazy compression thing that we don't know about? No, they have the same Weissman score as everybody else.
So it's like, okay, same file size, same bandwidth, same compression. How the heck can they break the laws of computer science and physics and get this file there so much faster?
Guess what? It had nothing to do with that stuff. It had to do with the UX team came up with it.
What the UX design team realized is, "Hey, 99%—95% of the time, people upload the photo, so why are we waiting for them to do all their things until their finger hits the button?"
The second they take the photo, start uploading that sucker in the background! And if they delete it, we'll delete it later. We'll figure it out. If they don't upload it, we'll figure it out later.
So that—and so that's like, whoa! It just seemed faster, right?
So that exactly—that was their clever trick.
And, you know, they talked about—luckily for me, they talked about it in some of their UX talks that they were giving a couple of years later.
So yeah, and that is a performance benefit because everyone else is five to eight seconds, and these guys are two to three seconds faster.
The interesting thing too about performance benefit is the more your user uses your product, the more they get, right?
Think about a Google search. If you're saving me, you know, two seconds or something on finding my answers or whatever kind of information product you're working on, you're saving me two seconds on every query.
If I'm doing 20, if I'm doing 50 queries, you just saved me a hundred seconds. If I'm a lightweight user, you save—so it's kind of the power—the power users get more value out of it too, right?
So it's very powerful!
Cool! So we got the different—the delighter, the filters, right? Make my photos look better, supported by filters.
We got the performance benefit—upload my photos quickly with this little UX hack. And there's one other thing they did—a little more subtle—to make your photos look good.
People—square aspect ratio!
Right! You got two out of three!
That's right!
So that's exactly right!
What I remember is, after like, you know, typical thing, like your third or fourth friend says, "You got to check out Instagram!" I'm like, "Okay, I'll check it out."
Pull it up, and it's cropping my photo to a square. I'm like, "Who gave you the right to crop my photo?"
I felt a little upset, right?
So like, why are they doing this?
Right? The reason they're doing it is when you take a photo on a phone, it's a rectangle. So when you take a photo, it can be a tall portrait photo, or it can be a wide landscape photo.
Either way, the photo is going to look good, especially with the filters. The problem comes in when you try to combine the different aspect ratio rectangles into a single fixed pixel width feed.
Maybe these are 100% zoom, and these have to be shrunk to fit in the same width. They don't want to have this like different zoom ratios of different photos.
So let's just avoid all that! We'll make everything square!
That's why they basically made it square.
So it's a more subtle way they made your photos look good—not individually, but in a feed.
Cool! So great job, everybody!
We got it right!
Here's how I would recreate—remember I had the problem space, solution space? This is how I would recreate, right?
Make my photos look good, largely supported by filters and also the square aspect ratio, and post my photos quickly, supported by the photo upload UX hack, right?
That's kind of the problem space, solution space mapping that I would come up with, right?
Now let's go ahead and create the grid—the product strategy grid for these guys, right?
So we have must-haves, performance, delighters. We have all the other first-gen photo-sharing apps. We have Instagram.
We don't even talk about the must-haves. Obviously, if we're a photo-sharing app, you got to let me share my photos with my friends, my network. That's what this is all about.
And like things and all that jazz. The performance benefit—post my photos quickly, supported by the photo upload UX hack.
Everyone else is low and slow, and we're higher and faster, right?
And then the delighters—making my photos look good, supported by filters.
Great! Show! Nobody else has that, but we do! It's our special sauce!
So that is their grid! That's how Dan Olson explains that phenomenon of Instagram launching a V1 photo-sharing app into a crowded category.
Why the heck did they take the lead? And go—that's why they did it!
This is it, right?
Now, of course, I don't expect them to have created it in this table format, but I have the close—one of the closest things that I can—luckily for me, when the UX design team was talking about that hack that they do, they shared their company tagline at the time, which was "Fast, beautiful photos sharing."
Now, this is just four words, but it's very powerful!
They packed their whole value prop grid—the whole product strategy grid is packed in. They have their must-have—hey, we're a photo-sharing app.
They have their performance—hey, we're faster than everybody else. Upload faster, maybe launches faster, maybe other functions run faster.
And we're more beautiful—make your photos look more beautiful with the filters and the square aspect ratio, right?
And that's the power! You can imagine this is very powerful also for internal use in the teams, right?
You know, I'm on the fast team. What are we doing to make the thing faster? I'm on the beautiful team. Yeah, we have these 20 filters today. What are we doing next?
I'm on the sharing team. You know, what are we doing? How else do we want people to share their thing, right?
So that's an example. Hopefully, that's a clear, powerful example.
So again, that's like an A+ from them.
The other thing, by the way, people are like, "Look, how do you know they just didn't get lucky, Dan? They were just throwing stuff against the wall, and all the photo-sharing apps—"
I know because one, they shared this, and two, because that actually wasn't their first app. They pivoted into that, and they were very—if you—there's a book about Instagram. If you listen to it, they were very honest with themselves, which also doesn't happen a lot.
Like, they're like, "They had a broader social networking app called Bourbon that wasn't doing well."
And they looked themselves in the mirror and they said, "This is not the kind of user growth and engagement we're hoping. What are we going to do?"
And like, "We got to pivot!"
Like, "Okay, cool!"
What they did is they said, "What is it that people are using and like about Bourbon?"
And the answer was photo sharing. But they didn't just stop there. They said, "Great!"
They looked at the category and they said, "There's already a bunch of other photo-sharing apps. How are we going to be better and different than them?"
And that's what led them, I think, specifically down to these things, which is a very clear example.
So anyway, hopefully, it's a clear example.
The last one, real quick, and then we'll open up for questions, is Uber.
So again, one of the Uber founders, 10 years or 11 years after it started, it's like, "Let's share our Series A deck."
And I was like, "Great!" I went looking through that deck to see if I can find the raw material.
There are a lot of slides, but there's one slide that had the raw material.
So I'm going to get your help to do it. So you know, back then it was called UberCab, not Uber. It wasn't all the variety of cars that we have now.
It was just that Mercedes black sedan was the car. They billed themselves as the next generation service.
Apple people—they don't worry, Blackberry people in the audience. We—they had you covered. That's just how old I think.
Overnight successes—we forget how old they really were!
I forgot about that!
I know the crack, right?
So I went digging through their slides, and they had a lot of slides, and I found the money slide.
This is their slide. This is a copy-paste of their slide, right? And they called it user benefits.
Okay, so let's go through this. In order to do the product strategy grid, the first thing we needed to do is identify who are the competitors.
So who are the competitors that they list?
Yeah, limo services and taxis!
Yeah, so there's—so basically, limo services and taxis are synonyms, and cabs and taxis are synonyms.
So say, "Hey, we got these two categories of competitors—taxis and cabs and limo services."
Right? Cool! So that's their competitors. They're very clear on the slide about their competitors.
And then what customer problems or benefits do they call out on the slide that we see?
There's a lot, right? They have a lot of words focused on that, right?
And it took me, after presenting this a few times, to realize this is actually a very deliberately structured slide.
The first two bullet points address what are the problems with the cabs. The next two bullet points address what are the problems with the limos, right?
And then they have a break, and then they have a summary that synthesizes it all together, right?
"We're going to be faster and cheaper than a limo, but nicer and safer than a taxi cab."
So that—and sometimes when I teach these workshops, I get a little anal about the grammar.
A good problem space statement starts with verbs, like "save money" or "save time" or whatever.
A good performance—a good product strategy that talks about how you outperform someone is going to be a comparative adjective, like "faster," "cheaper," "nicer," "safer."
Right? That could be their slogan! They could have been walking around V1, you know, "Faster, cheaper, nicer, safer! What are we doing?"
Right? So that's what they do.
So this, again, has the raw material we need to create it. So we can create the performance benefits, and I'll just put them in Dan speak, starting with the verb, right?
So faster—what does that mean?
Let me quickly get a ride.
Cheaper—save me money.
Nicer—give me a nicer ride experience, right?
Feel—make safer—make me feel safe.
That's how I would say it, prob.
And then we can score the competition, right?
And hopefully, that makes sense. You know, basically, car services take longer—not now. There are certain parts of the world that you just go out and hail, like in, you know, Manhattan or London.
But barring those, you kind of have to call ahead. So even a taxi takes a little while, but car services that have even more lead time, they're obviously a nicer experience and safer, right?
So we can color code each competitor.
And then Uber comes along, and it's interesting because nowadays it's cheaper than a taxi often, but that wasn't their original thing.
They're basically saying, "Hey, we're going to give you this limo-like service in this nice black Mercedes sedan, but you're going to get it quickly. It's going to be nice. You're going to be safe. You know, it's going to be cheaper than a limo, but not necessarily cheaper than a cab."
Does that make sense?
So what I typically tell people is, "Gosh, you're lucky to outperform on one." These guys had three!
This is super rare to see this, but it's because there's other talk that talk about it.
It's because it was like a monopolistic industry that—because it was monopolistic, you had to have a medallion. They didn't really—it's kind of like the cable company back in the day or the phone company.
Like, "We're a monopoly; we don't care about what customers say," right?
So they lost—they got decoupled from customer value over time.
So that's why they were, you know—and there's a big disruptive innovation with mobile and geo and GPS.
That's why they were able to do three at a time.
And then, you know, if we zoom out, we didn't even talk about the must-haves. Obviously, take me where I want to go is a must-have.
And then I think the delighters are really important too, which were on that slide, is like, "Hey, I can book without having to call."
You know, we all know sometimes dealing with—get a busy signal, they don't answer, the person's rude.
And the last thing is, "Is the car coming or not?"
You know, I used to live in San Francisco. Yeah, a cab will be there in 10 minutes. 70% of the time, it would show up, but then it wouldn't sometimes, right?
So anyway, I think that is how I—so again, I think another excellent example from that one slide.
It's very clear they were very deliberate. How are we going to be better than, you know, than cabs and limos?
So those are the two examples that I like to share with people that hopefully you can relate to as a consumer.
Those are great examples!
Yeah, it's really hard to find these artifacts. The other one is Airbnb, and they weren't as crystal clear as Uber and Instagram were, but that's another one.
So yeah, so with that, I just want to thank everybody!