Today's episode is with David Lieb, the Director of Google Photos and former founder/CEO of Bump. He unpacks the underpinnings of Google Photos' success and walks us through how product builders can focus on solving real problems. From how annual planning and org design evolve with scale, to what makes for an exceptional product leader, David shares plenty of insights for leaders at every startup stage.
David Lieb: [00:00:00] We tried to just probe on all the possible dimensions that might matter to these people in these specific moments that they were facing. It's hard to ask people for generalized answers, like, Hey, tell me about your life. What are some of your pain points in your life? Nobody's going to give you a good answer to that problem.
They'll tell you about macro problems that they've got, but nothing you can actually go solve. But if you try to dig into very specific questions that they'll be like, well, that's a very precise question you're asking me. I can actually tell you the answer. If you ask enough of those, you can paint a picture that I think ultimately lets you understand deeply that person's life and therefore have a good chance of solving the problems that they're facing.
Brett Berson: [00:00:45] Welcome to. In-depth a new show that surfaces tactical advice, founders and startup leaders need to grow their teams, their companies, and themselves. I'm Brett Berson, a partner at first round. And we're a venture capital firm that helps startups, like notion, roadblocks, Uber, and square tackle company building firsts through over 400 interviews on the review.
We've shared standout company, building advice, the kind that comes from those willing to skip the talking points and go deeper into not just what to do, but how to do it with our new podcast. In-depth you can listen into these deeper conversations every single week. Learn more and subscribe email@example.com
for today's episode of in-depth, I'm really excited to be joined by David Lieb. David is the director of Google photos, and he arrived at Google in 2013 via its acquisition of his startup bump. You might remember bump. It was an app in the early days of the iPhone that allowed people to share contact info by physically bumping their phones together.
It was a really big hit bump was downloaded 150 million times. Hit number two in the app store and was even featured in an apple commercial. But as David describes in our interview, the journey wasn't always up into the right user acquisition was through the roof, but retention was a real problem spot when they distilled down what power users loved about the app David and his co-founder realized they'd been building the wrong product, unfortunately, attempts to course correct with their second app flopped running out of runway.
He and his co-founder decided to sell to Google. It was their unreleased third app that formed the basis of the design of Google photos, which launched in 2015 and passed the billion user mark only four years later in 2019. In our conversation, David sketches out the consumer product building journey from zero to a billion in a ton of detail, we unpack the decision to sell to Google and their initial struggles to find their footing in the Google plus org, including the lessons he learned on convincing stakeholders inside of a big company.
And as David puts it, he got fired from the team twice by ruffling the wrong feathers. I really loved all the product insights in this episode, especially around how they uncovered this problem in the photo sharing space. We hear a lot about the importance of talking to users, but David gets super tactical here from the questions they ask and user interviews to the techniques they use to sip through conflicting feedback.
And for more of his thoughts, be sure to read his article in the first round review on the dangers of cognitive overhead and product building. We'll put a link in the show notes. There are some really great stories of scaling in here from how a random Google photos feature in an early release became the bedrock for the product's recent redesign to why he writes a state of the union style address during the annual planning process.
David also shares why he looks for credible confidence when hiring as well as how his thoughts on product org structure have evolved and what he thinks makes for an exceptional product leader. It's a great listen for product builders, of course, but I think there are also so many interesting insights on building from scratch for all types of leaders.
I hope you enjoy this episode. And now my conversation with David. All right, David. Thanks so much for joining us. My pleasure. So a place that I wanted to start was talking about the underpinnings of Google photo success, something that you came in and created and got off the ground. And I think when you look across large cap tech, it's very rare that a company with an existing core product or some adjacent product launches, something from scratch that gets to massive scale and becomes another pillar of the business.
I think the dominant way that that happens is they acquire something. Or the one thing is just the one thing kind of forever, maybe in like the eBay use case. And so I'm curious why you think. It worked or what are the underpinnings that made it work, maybe other than what people tend to talk about, which is, you know, company X hires someone entrepreneurial and just leaves them alone and then it works.
Is there more to that story?
David Lieb: [00:05:14] Yeah, it's a great question. You mentioned the build in-house versus acquire the two paths. Interestingly, Google photos is kind of both of those paths because they did acquire our startup bump and it was very clear. We had built a prototype of a product in the photo management and sharing space that we were really excited about.
That was certainly an area that we wanted to go build on at Google. But at the same time, Google had internally built a lot of great technology and some interesting product interactions in the Google plus product. And so when we came in, we were able to graft on to a. Portion of that Google plus team, and then eventually sliver off and create our own team to go build Google photos.
So it was both of those things to answer the question about the underpinnings. Why was Google photos successful? I think it's a combination of a lot of things that have to line up for any product really first and foremost is it's got to solve a problem. That's real for real people. And I think for us at the time, this was 2013, so it's kind of a long time ago.
Now we had the advantage working at the startup that we were on the cutting edge of mobile. Y'all had iPhones. We were all using our I-phones probably 10 times more than normal people were at the time. And I think we just got a few insights into how the world was going to go, that other people didn't yet have.
So my example is I was taking a lot of photos to test bump, cause you could share photos with bumps. And I found that I had all these photos on my iPhone and my iPhone kept running out of space. And so I, every month I had plugged my iPhone to my Mac book and drag the photos over and organize them and I just realized, oh yeah, Everybody's going to have this problem soon, but I'm the only one really having it now.
So that was some of the unique insight that allowed us to get excited about this problem. So I think you've got to have the real solution to a real problem, which I think we did, but you also have to have a bunch of other things to make it successful. You've got to have the ability to acquire a team, to go build it with you.
You've got to have a way to get funding somehow, to go hire those people and build it. You've got to have distribution, like, how are you going to actually get the word out about this product? How are you going to mechanically find ways for users to get the product? And then ultimately you've got to have a way to turn it into a business model that can sustain itself.
At some level in the long run, when we were getting acquired, we were very excited about building this product and we really wanted to bring it to the world. And we had a few options and looking at those options, it was very clear to me, at least that Google was the place that would allow us to do this in the best way, the product aligned.
Very well with the core mission of the company to organize the world's information and make it universally accessible and useful. You think about photos, that's like exactly what we are doing, but just on a personal level, instead of a public level, you look at the DNA of the company. Like what types of people work at Google versus some of the other companies that we could have gone to.
And it was just like a perfect match for the stuff that we care about. You look at the brand of the company, who will you trust to store all of your life's most personal memories? And the answer was very clear on that one, that it's a very limited set of companies that you might trust. So I think all those things have to line up.
And I think we were just fortunate Google photos, that we were able to line them up in a timeframe that made sense that allowed us to build this product and grow it in the way that we did. How did
Brett Berson: [00:08:24] work in terms of you get acquired? And there was alignment around you're going to launch this, what happened organizationally, that made it work and.
Short-term long-term success metrics. How does that tie into the level of funding that I guess you ultimately get in milestones, which I'm sure has grown exponentially over time, but what are the mechanics or mechanisms once you
David Lieb: [00:08:48] joined? Yeah, kind of laugh because the way it should have gone down, we had a little brief interruption, which was super stressful to me and almost made the whole thing fall apart.
We showed this prototype to some folks at Google and it was very clear like, oh, this should be the Google photos product. And we should put it on our operating system on Android and we should build it for iOS. This is great. So there's very clear strategic alignment, the individual people, the leaders that we would be working for, it was very clear.
Everybody was very happy and we shake hands on the deal. The lawyers go and paper the deal up. And before the lawyers finished papering, the deal get a little notification like, Hey, by the way, there was a little reorg at Google. So there's this other person you're going to report to. That's different than the person you thought.
And I was like, oh, that's. That's interesting. And it turns out it was a massive reorg. They basically moved where we were going to be into this Google plus organization. And the mission of that Google plus organization at the time was very different than the mission that we had in our head. The product that we wanted to build did not align at all in core philosophy with where that team wanted to go at the time.
So. The first nine months of time at Google was very stressful for me. I felt a major bait and switch, and also it was just really hard to get anything done. I would show people here's what we want to build. And everybody around me would say like, well, but that doesn't make any sense for Google. Plus why would we build that?
And I had to be really stubborn, I guess, is the simple way to put it. I had to just stick to my guns and say, no, I'm pretty sure this product is going to be a winner and I'm not going to take no for an answer. So if you guys are telling me no, I'm going to go talk to some other people around the company.
And that in combination with luckily the person that we did report to in the Google plus team, he got it. He saw the vision, it's this guy named Neil. So we were able to use his organizational credibility to at least not get killed right away. And then I think over time, a few things were shifting and we persisted.
We just didn't take no for an answer. And ultimately the whole Google plus mission fell apart. And there we were with a product that was ready to be built. It was clear, everybody in the world was going to want it. And then we were let off to the races to go build it.
Brett Berson: [00:10:54] Execution standpoint. Do you pitch here's the product, here's what we're doing and get funded for some period of time with some head count and it's done almost like you would have a board meeting at a startup or the dynamic is quite different.
David Lieb: [00:11:07] It approximates that, but it's not as clean as that. It's a much less longer process. There's not single meeting where it's decided in. There are people at the company that own head count and they have to decide how they utilize that headcount in pursuit of which products or missions. And yeah, we had to convince people that, Hey, you should take, I think at the time, like at the beginning of the project, I think it was something like a hundred or 120 people.
You should apply them to build this product instead of building these other things. That was a massive change. Yeah, we had to convince them to do it. And I think that was pretty hard. Let alone the massive org shifts and the personalities involved. It was quite a interesting time. But the thing that really pulled it through to be honest is that we just decided, okay, even though you're telling us, we can't really build this thing right now, instead of we have to work on Google plus, we're going to just design it anyway, on the side, I remember very clearly in those very early days, the lead designer, and I would just escape our desks and go to a different floor in our building at Google.
And we would just spend like entire days designing the product. And so by the end of the first three or four months that our team was at Google, we had the full thing written down. I wrote a product spec that exists today at Google and it's 50 pages long it's every single possible detail about the product.
We were just so excited. And so believing in what this could be, that we just decided to do it. And so there was one. Moment. I do remember very clearly that I would say is one of the shifting points there probably too. I'll tell about these stories. One was getting the buy-in of the immediate Google plus team.
And so through some machination, we got the chance to present our idea to the all hands meeting of Google plus. And I knew that this was a pretty important meeting because I knew the leaders. It might not necessarily agree, but if I could get all the engineers in the room to say, oh, actually I want that product we'd have a lot better shot.
So we didn't obviously have anything built yet, but this designer and I won, we basically prototype the whole product in a series of screenshots. And instead of presenting it on a projector in this conference room, I went and got a big 80 inch LCD TV and I turned it on its side. So it was a portrait mode.
So it kind of looked like an iPhone. And we faked this demo where we were really just clicking through slides that we had pre-prepared. But at the same time that we would click, I would touch this fake giant touch screen iPhone with my hand in front of the building, in front of the group. So it looked like I was actually using.
The app on a giant iPhone. And I think that demo alone really made a big difference because it let everybody in the room see, oh, I see what they're talking about. Now. This is like a real product. I can see myself using that. So I think that was a pretty monumental shift. And again, you're like really at a big company like Google a transformational moment is that they decided to take a TV and turn it into portrait mode and fake a touchscreen demo on it.
Is that really how it works with these big companies? And the answer is, yes, these companies aren't as like sophisticated and mature, as you might think they are on the outside Ching
Brett Berson: [00:14:01] on this. But I assume from time to time, you have friends that reach out to you that maybe you were at Google or Amazon or Facebook, or what have you.
They have a vision for a product and they don't quite have buy-in. And they're asking maybe your perspective on how to do it. Are there other things that you would suggest or lessons that you've learned? One of the things I'm hearing is you saying, make it real, don't talk for 30 seconds about this idea, put the effort and kind of go above and beyond to crystallize the vision is maybe one piece, but I'm curious if there's anything else that comes.
David Lieb: [00:14:32] think another one that we took for granted was alignment with the core mission of the company. Had we been pitching something that I didn't think was obviously within the scope of the company mission? I think that would have been a lot harder. That's not to say that everybody around us immediately understood that, but it was there and it was real.
And so it was easy to actually explain, this is a product that Google should build. It's within our scope. It's not like proposing some massive change for the company. It's just another product that really fulfills our mission. I think that's a thing that people should think about. And if you don't see that alignment, you either need to find it or you need to change the idea in some form.
So that's one, I think the other one. Which again I took for granted is just really confidence that you're right, that users or customers or whomever your, your stakeholder is that they really are going to want this product. That the problem that it solves is real for them and tangible enough that you're going to be able to convince them to want to use it.
I do think that is another thing that people, especially product managers tend to take for granted, they think in their head, oh yeah, this is a great product. Everybody's going to want it. But then when you go out and talk to real customers and say, Hey, tell me about your day. You don't actually find that the problem is large enough for them to care.
That's like a very common failure mode, especially for startups where you have this clever idea. And you're like, oh, this would be a great product. And then you don't understand that people's lives are busy and your product has to be solving such a real pain point for them to actually give any amount of notice to it.
So I think that's the thing that people take for granted as well. So those are two things, especially inside a big company that you got to make sure you have, right.
Brett Berson: [00:16:10] Before we move on to an adjacent topic, anything around the people side, if ultimately you have to get an executive to fund this thing or back this thing, there's this managing up element of for him or her, what do they care about?
What are their incentives in the organization? Is there anything you've learned or picked up around
David Lieb: [00:16:28] that? It's a great observation. Honestly, I don't know if I did this very well with Google photos. My strategy was more just people headed and wait for those people to get kicked out. And it was successful.
I think by chance, I think the better way to do it would be to see how this thing that you want to get done helps that executive or that leader or that decision maker achieve the objectives that they've got. Even if they aren't quite aligned. In hindsight, what I think would have probably worked quite well is gotten those leaders to the point where they admit, okay, Google plus is not going to work for its original stated goal, but I can save.
Your face by taking this product, which is a clear derivative of the original Google plus vision and make that successful. That can be your win. I think that approach probably would have worked, but we honestly didn't approach it that way. You know, honestly, I got fired from the team twice through this process because I ruffled the wrong feathers and I had to call in some favors to get reinstated
Brett Berson: [00:17:24] that first nine months.
Does it shape the way that you think about leading your org? Right, because there's a young David that has this idea for this new feature or product. Then maybe it's easy for you to squash as an educated you or change the way you behave in
David Lieb: [00:17:39] some way. Absolutely. One very tangible thing is I very much value bringing people into the team either via acquisition or via other means where they have a different.
Perspective or a different background and the rest of us, because that was what I experienced. And I saw the, in my opinion, the immense value of having somebody who believed other things than what the rest of the team believed and putting them in a position where they can actually say it in hindsight, if I'm ever running a very large company, I think acquisitions.
Specifically, because they bring people in, in a way that they are able to speak their mind without risk of financial repercussions. I think it's actually very valuable because they'll actually speak the truth. The fact that I knew when I was at Google, well, if they fire me from Google, they'll have to accelerate my vesting.
So I'll get my money and I can just move on with my life because I knew that I was able to push way harder, I think, than people who were on the traditional Google career path, where if they pissed off their manager, it was going to be a big problem for them. So that's one learning. And I think it applies not just to acquisitions, but also to who you hire and also deliberately hiring people who disagree with your vision or have different ideas.
I can think of one example of a guy that we hired. And he just had a very different opinion on what we should build in the sharing part of the Google photos product. And he and I butted heads for a year on it. And he eventually left the team and we eventually built some stuff, but now three or four years later, I realized, oh, a lot of the stuff he was saying was kind of right.
And a lot of the things I was pushing back on were kind of right. And it's actually really great for our team that that debate happened. Do you think
Brett Berson: [00:19:16] it was a mistake for him
David Lieb: [00:19:16] to leave the team? No, I don't. We weren't going to build exactly the thing that he wanted and he was very much like me where he wanted to build the thing he wanted to build.
And it probably would not have been a great fit in that way, but he remains a close friend and I'm actually very happy that he pushed in the ways that he did. And it wasn't comfortable at the time for either of us. But I think for Google and for the team, it was really beneficial.
Brett Berson: [00:19:38] If I was sort of sit and watch you interview someone or potentially assess if you're going to Aqua hire, hire a team, and you're trying to assess this right amount of disagreeableness is like one dimension, but it might just be different worldview, different preferences, different ideas.
What are you looking for? Or, or how are you assessing that? And, and to your point, there's also some extreme where I would assume that there's some philosophies or values. If there's not alignment, it's just going to be a nightmare. If somebody philosophically disagrees with your stance on privacy or something, that's going to turn into something where you're just smacking your head against the wall every day.
And so is there a way you think about this questions you're asking or something you're looking for?
David Lieb: [00:20:18] It's a great question. There's a set of non-negotiables. I would classify those as values. You've got to make sure that your values are aligned and values are trade offs about what you care about and what you choose to sacrifice in order to get those things.
This is something I learned from Todd Jackson, actually. And as part of that, the next level up is mission alignment. Why do we want to build the things that we're building? Why do we come to work every day? What's the essence of what we want to accomplish in the world. I think that needs to be quite aligned as well.
Otherwise things are going to not work very well, but after that, you actually do want some cacophony in your symphony, right? You want some discord. And so two of the things that I look for when I'm talking to somebody, number one is I want to see confidence. I want them to have an opinion. I want them to have a worldview about what the world looks like and what products or things should we change to make our.
Product or service successful in that world. And that confidence can come from many different sources. It can come from talking to users. It can come from doing research. It can come from building things and learning and iterating, but I want to see people that have confidence, but number two, paired with that confidence is it's gotta be credible confidence and often you'll see one and not the other.
And that's a danger zone for me. I hate to see people who are really confident about something, but it's not actually backed up by a credible set of learnings for me to believe that it's real and vice versa. I often see people who have a lot of learnings, but don't really know what they want to do with them.
They don't have a confident plan of what to build. So I think confidence plus credibility is a really good formula for people who will push the envelope in your approach.
Brett Berson: [00:21:55] What's an example of the types of questions you're asking to elicit
David Lieb: [00:22:00] that maybe what we should do, let's say you own Google photos tomorrow.
What would you change? Sometimes they're flummoxed by that question. They're like, whoa, I don't mean a lot of it's good. That means that they don't actually have strong opinions, which I think are less useful. So I put them in those hypothetical situations and I asked, tell me what you would do. You're in charge.
Do it, tell me what you do the confidence bit. I get at by poking up their answers. And I say, oh, interesting. Why do you believe that? Why are you so confident about that? And the dangerous people to hire are the people who can't articulate, why they're confident, but they're really confident. That's a very dangerous position to be in.
It doesn't make for good interactions on a team. I think. So I just try to poke and I just keep going one level deeper, one level deeper. Oh, why did you do that? And, oh, you said you tried that in that product. What did you learn specifically that makes you feel that way? And you can kind of separate the bullshitters from the ones who actually have taken those learnings to heart and actually believe them shifting
Brett Berson: [00:22:55] gears a little bit back to product and product strategy.
Do you think this product could have been successful as a standalone business outside of Google? Or it was the unique combination of the product insight you had combined with either Google technology, resources, distribution that ultimately made it the success that it is. This
David Lieb: [00:23:15] was question that we literally contemplated because we had built bump.
We were getting towards the end of our series B runway. We had built a photo sharing app next, and then we built this prototype. We called it photo roll, which is basically like the cheap non-technical version of Google photos. And we had this app, we were about to launch it on the app store. This was summer of 2013, and we had to make the literal decision of, do we go try to raise some more money and pivot the company to this and try to make it successful?
Or should we sell and go build it inside somebody else's company and. We decided at the time, even though we believe this product is going to work, it's real, we looked at what we would need to do to make it really successful and what we would need to build, what people we would need to hire, how much money we would need to offer some free storage at the beginning to get people, to use it and think about a business model.
And it was just so beyond the realm of possibility, at least at the time, it was like, oh, we would need to raise another a hundred million dollars to get it to any reasonable scale that we just decided that's not going to be the best path forward in today's world. Could you do it if Google photos didn't exist today?
I think it would be hard if you look at the. Amount of energy that went into the Google photos product beyond just the product that we built. It was built on years, like decades of research around face grouping and face recognition, decades of research around object identification and classification and search technologies.
I tell the story of like, yeah, we got acquired in the fall of 2013 and then we launched it in spring of 2015. So it was, took us like 18 months to build this product. And then it ramped up to a billion users in four years. It feels like it was a really fast thing and something we built quickly. But the truth of it is that people at Google had been building this product.
They didn't know it, but they had been building the backbone of this product for more than a decade. So I think it would have been very difficult to do this at a company that didn't take a very long-term view. And also I think had related projects where they could invest real resources in solving some of these core underlying problems that we could then cherry pick and used for a really great product just
Brett Berson: [00:25:27] briefly.
But what did the experience building bomp teach you about building great
David Lieb: [00:25:34] products? Well, we learned the lesson of retention and talking to your users. Bump was a fascinating story. The long and short of it is bump was one of the most popular initial iPhone apps that existed. I think we were number three in the U S overall after two or three years of the app store.
So we were super popular, 150 million people downloaded the product when there were only 300 million iPhones at the time, something like that we've had huge penetration, but it was one of these products where it was so cool that our user acquisition was just through the roof and people used it, but they didn't use it frequently enough for us to figure out eventually a business model that would work for it.
And. We didn't really realize that problem until far too late, because all the numbers were going up. We had these dashboards and it was our first go of ever building a real product. We were straight out of school. We didn't really know what we were doing. And we would refresh the dashboards every day and it's like, oh wow.
An extra 3 million people used bump yesterday. Then the day before. Awesome high fives. But in truth, we were getting a bunch of people to try it and then keep it on their phone, but they didn't really use it that much afterwards. And so we kind of learned the hard way. One day, those graphs slowed down and then they started to go down and we were like, whoa, but what happened?
Where are the hot startup? Why, why is this happening? And it forced us to really understand the data and think about cohort retention. And we realized, oh wow, we're kind of screwed. This isn't going to work. And that was the point where we had to learn the second lesson, which is what do you do when you don't know what to do?
And. The answer for at least consumer products is go talk to people and ask them what's going on, how they use their products. Why do they like your product? Why do they not like your products? The single most transformational day of my career was a day at bump. When we realized, okay, this isn't going to work, what should we do?
And we decided let's get the email and phone numbers of the top 100 users of bump in the world. And we're just going to send them emails and text messages and ask them if they'd be willing to talk to us. And so for an entire day, my co-founder Jake and I got into a conference room at Bob and we just called every one of those people who were willing to talk to us.
And I think we talked to like 15 or 20 of them in that Monday. What
Brett Berson: [00:27:42] did you ask them on the call? You pick up the call and you say what to elicit this
David Lieb: [00:27:46] feedback. We had emailed them and we said, Hey, we're Jake and Dave were the founders of bump. You're one of the top users of bump. We want to understand why you like it, why you use it.
And so by having those conversations, what we learned is that the people who really loved bump and used it the most were using it for a completely different reason than what we had designed. So what they were using it for was to share photos with their spouse or their close friends and family of the moments of their life.
And they didn't have a better way to do it because SMS would compress the photos, emailing the photos was cumbersome to do. They just want it to give the files to the other person so they could keep those photos as part of their photo library. And there wasn't really an answer. This was before any other real solution to this problem.
And so we walked out of the conference room that night and we were like, Oh, wow. We've been building the wrong product to solve this problem. And so that got us onto this track literally the next day we said, okay, what if we were trying to solve that problem that those people talked about? We certainly wouldn't design it in the way that bump is designed.
If you thought about the bump interaction, where you had to stop what you're doing, pull out your phone, both had to open up the bump app. You then literally had to touch the other person. It's almost the most friction that you could have designed into that product flow to solve that problem. So we said, okay, well, what if we solved it in the best way possible?
And that got us on this multi-year journey to build the best photo sharing tools for that type of photo sharing, and that eventually led to photo roll and then eventually led to Google photos.
Brett Berson: [00:29:14] How did that experience influence the way that you think about the idea of creating 10 X better products?
Versus what I think of is like rounding rough edge products. And I'm not sure if you kind of see the world in that way at all, but I tend to find that the general advice is you need to build something 10 X better. And I actually think there's a bunch of examples of, you know, depending on how you define 10 X, better of product folks, just looking at all the rough, annoying things about a given product or the way that somebody wants to do that.
And you Polish those rough edges off, and you can have something that really connects with people in some way.
David Lieb: [00:29:48] Yeah, it's an interesting way to put it. I kind of believe both. I do believe that you can find these 10 X solutions by first looking at what are the little minor annoyances, what are the little things that make you do a double-take in your day?
And when you dig into those though, I think you will find that they are. At least symptoms of bigger problems that you can then go solve. So this photo-sharing problem. If I think about it, people were telling us, yeah, I'm using your product a lot because I want to share photos with my husband of the kid's soccer practice.
And the small Polish is like, oh, we can make that eight traction better for you. We can make it easier for you to select those photos and send them to that person. But the bigger idea that I think that was a small symptom of his. Why did you want to share that photo in the first place? Why did your husband want a separate copy of that photo?
And the answer is he felt that it was part of his photo library, part of his life's record. And I think that is the much bigger idea that now of course we are pursuing with Google photos, but it started with asking the question of why do you care about getting the photos of that kid's soccer practice?
What are you going to do with them? I think that technique of find a little annoyance or a little rough edge, as you say, and then pull on it and see where it leads. You often, it will lead you to a much bigger problem space that actually is a 10 X better product and something that you can build and get a lot of people to use.
So you're kind
Brett Berson: [00:31:13] of getting at this, but there's kind of consensus wisdom to talk to users. And there's also the interesting thing that there's a category advice that everybody knows, but nobody does. And I actually think talking to users may be one of those things. You know, another one is, if you think you should fire somebody, you should probably fire them, but nobody does that.
So there's a category of these things, but if you were to teach somebody how to do that, well, Is there anything you would. Coach somebody to do to really get the signal or the insight versus just go talk and say, what do you think
David Lieb: [00:31:41] of our product? The big insights come from trying to understand the motivations behind their beliefs or their actions.
You hear this a lot to ask why a lot, right? Ask why five times. Right? You hear that a lot. But I think it really comes down to that in these interviews that we did that day with bump users. We really tried to understand. All right. So you use bump last week to share some photos. Do you remember why you wanted to do it at that moment?
Why did you need to do it right then? Or why did you care about the resolution of the photos or what were the photos of, and why was that meaningful to you in your life? We tried to just probe on all the possible dimensions that might matter to these people in these specific moments that they were facing.
It's hard to ask people for generalized answers, like, Hey, tell me about your life. What are some of your pain points in your life? Nobody's going to give you a good answer to that problem. They'll tell you about macro problems that they've got, but nothing you can actually go solve. But if you try to dig into very specific questions that they'll be like, well, that's a very precise question you're asking me.
I can actually tell you the answer. I don't know what you're going to do with it, but I'll tell you the answer. If you ask enough of those, you can paint a picture that I think ultimately lets you understand deeply that person's life and therefore have a good chance of solving the problems that they're facing sort of a
Brett Berson: [00:32:57] slight tangent.
Why do you think there aren't fewer successful standalone consumer products given that it seems like a lot of your worldview is grounded in deeply understanding users and translating that into product. I would assume that there's an infinite amount of problems that users have. So you would think that there would be a heck of a lot more or at least I think there would be a lot more standalone products than there are.
David Lieb: [00:33:21] I think there's a set of reasons that there aren't more that are around the actual products themselves. And then there's a set of reasons that are around the execution thereof, right? So I think there's probably like 20 really important consumer products that could exist today that have failed because they haven't gotten right things like how to position their product in the market, how to get distribution, the stuff that you sometimes take for granted, especially at big companies like Google, you tend to not think about these things.
So that's one set of causes of death. But the other one that I think is more fundamental is that human beings have a limited bandwidth of attention and understanding in their lives. And it would be very unreasonable. I think if on a given day I used a hundred different products in my life because what does that mean?
It means that I have to. Switching to some other use case, every, I don't know you can do the math, but like every few minutes in my day, I'm going to be interacting with some new product. And I just don't think we're capable of that as humans. I think we like to focus, we get pretty in-depth in things. And so I don't think the world can accommodate too many different products.
So I think what that leads you to is that there's. A set of fundamental human needs or behaviors. And they'll probably will be like a constellation of products that each serve some of those fundamental needs. So there's a need for communication. And so we have a few winners in the communication space that everybody uses.
And there's nothing else, even though, yeah. There's probably some better messaging app that I could be using with my wife. That would be a better interaction, but I don't have space for that in my brain. I use iMessage and I use that for everybody. So I'm just going to use that. I think the same thing in the photo space, and this is actually one of the insights we had.
We built this app called flock, which was the first attempt to solve that problem that we learned the day that we talked to all those users. We tried to build a product that would help them with that photo sharing problem. And what we learned is. Even though people loved it. And the people that we got to use, it said it was great.
And they used it with their friends and family. We couldn't get it to grow. And the reason we talked to those people, we said, why didn't you get more of your friends to use this product? And they said, ah, nobody wants to download yet another photo sharing app. It was to the point. We heard that so often that we just like, remember that acronym yet another photo sharing app.
We don't want to build it. . And so to us, that really led us to this notion of building a single comprehensive product when it comes to your private photo library and that turned into Google photos. So I think you can often have some degree of success by building the piece of the fundamental product, but eventually if you're really successful, you can kind of figure out what that fundamental big thing is that will fully solve that zone of a human's needs.
And then you're in a really great place. And then you can build out all those solutions.
Brett Berson: [00:36:07] How does that fit in with the role of defaults. Let's say you're an iPhone user and you have your default by cloud slash photos experience. Does that matter when you think about a user using Google photos on an iPhone, or you're going back to the same principles and it doesn't really matter.
David Lieb: [00:36:23] Oh, for sure. This is now a go to market question. You've got your product. You've built it now. How do you go to market in different places for different types of users and, yeah, it's a hugely different problem when there is a credible default photo app on a device versus when there isn't a credible default photo app and we can get the user to choose Google photos.
Instead it changes. The go to market plan, like how do you communicate the product to people? Why do you tell them it's valuable to them? How do you help them get onboarded and start using it? It also sometimes actually changes what the product needs to be on that platform. As an example, for Google photos, apple has done a pretty good job of copying us over the last four or five years.
And I would say their product. I don't think it's as good as ours, but I think it's good enough that a lot of people will look at the two and be like, yeah, they're kind of the same. So we have to position our product now in a way that satisfies some unsatisfied need for them. If they're going to really decide that it's better.
And we think we have a few vectors that we can really Excel at that apple probably won't or will choose not to. And that's how we're starting to think about our go to market plan. You also mentioned
Brett Berson: [00:37:26] that there's 20 large scale. Potential products that haven't been built or where I think you said built in the wrong way.
Can you give one example that comes to
David Lieb: [00:37:36] mind as a new parent, as we talked about earlier, before we got on the podcast here, and one of the things I'm finding is that my time I'm now realizing my time is very limited and it's definitely my most precious commodity, but there's really like if you look at normal people, there are no tools that help you best utilize the time that you've got in your life.
Thinking about how you want to spend it. Maybe the most. Powerful executives in the world have the chance to have somebody looking at their calendar and asking them questions. Like, do you really want to spend time on these things? Wouldn't you rather go home and see your family, but most people don't. I think that could be like a very high leverage product to build.
And one that would be incredibly valuable to humanity, but it's not built. It doesn't exist. And I think the reason is nobody's figured out the wedge to get a set of people interested enough in that problem. And then have it turn into something that can be fundamental enough that you actually will go to every day.
So probably the best bet is for somebody to try to do that in a calendar product or in a, some sort of operating system that you're touching on a very frequent basis, but nobody's done it. It's I think in 10 or 20 years, somebody is going to solve that problem somehow. You've got it.
Brett Berson: [00:38:44] Yeah. That's a great example.
Flipping back to something we were talking about a minute ago when you're getting started and going zero to one with a product. You talk to users, you organize the feedback and you start building. I would assume that as you start to grow and relatively early on, you have different types of users trying to do different types of things with different types of problems.
And it can almost get mind. Bendingly complicated to really figure out. Where to spend time and you can also kind of get into that crowdsource like a zillion different ideas in Lou's real product strategy and intentionality. I think it would be great to talk a little bit about how you approach that maybe through the different chapters of building this product.
Because I assume every day you get a DM from somebody in Albania. Who's a professional photographer and trying to connect is like a camera to this and that. And can you solve this? And that's probably not a problem we're solving, maybe it is, but you also have to institutionalize it across a large engineering and product org.
And so curious how you think about that.
David Lieb: [00:39:50] This is kind of like the apple notion of saying no is the way to be successful. You have to say no to almost everything. If you want to do anything really well, I totally agree with it. And it was definitely a big problem that we faced when we were building Google photos.
And I think that that. Technique you have to use is to think about who is the canonical user that we're building this product for w with the knowledge that like, of course, there's a distribution of users of all different backgrounds and all different needs, but we're going to pick this one canonical user and we're going to build a product for that person.
I think that is a really important thing to do. You got to pick some customer that you're saying like, this is who we're building for. And so, so this feature requests that I'm getting, is that a thing that's important for that user or not? The other tactic is we operated in the early days of Google photos out of a very strict thing that we call it a stack rank of features.
So it started with myself and Juan just writing down, like, alright, what are we going to build first? What's the most important thing to build. And so we literally have a list of if there's no other feature in Google photos, but this feature, what does that feature? And it was that all your photos appear in one view, right?
Uh, and then we said, okay, what's the next most important feature? And we made this list and what's great about that. Formulation is you can. Ingest anybody's idea. Anybody has some crazy idea or some off the wall feature requests. You can say. Interesting idea, where do you think it should sit on this stack rank of features and what that forces people well to do is to admit that their pet project might not be more important than the things that are on the top of that list.
And so it's a helpful way just like organizationally to get people to realize. We can't do everything. You've got to tell me where you think it should be on this list. And if we disagree about it, at least we have a way to talk about it. We can say, well, I think it's not as important as this feature.
Here's why, so tactically, that's a way to do it. But yeah, man, when we were building Google photos, first of all, Google has a very open product culture where you know what all these other teams are building. We dog food stuff super early with Google photos. Also, we. Already had a photo product in Picasa that Google had acquired, I think in 2005.
So there were a bunch of people who used Picasa. They knew that we were going to eventually replace Picasa with Google photos. And so I had all sorts of people emailing us, saying, I really love this obscure feature of Picasa. And I can't imagine you're going to delete it from Google photos. How could you, and we had to just withstand that for months and years, really?
And it happens to this day. Of course, we get these emails from Googlers. We get these emails from folks who use Google photos. You just have to stay true to like, who is that customer we're building for? And what's the best use of art resources to better the product for that person today. And if it's not your feature, we're not going to build it.
Sorry. And you just got to have the confidence in yourself to make those calls. How often do you
Brett Berson: [00:42:36] find the thing that you think is the most important thing doesn't turn out to be? And then the inverse of that, something that seems less important. Really strikes a chord and becomes a foundational part of the product.
Is that fairly rare or if it's more frequent, how does that inform. The way that you ultimately are using your judgment to decide what you're going to build and whatever
David Lieb: [00:43:00] I was about to say that it doesn't happen all that often. But I think the more precise answer is that it happens, but on a longer timescale than you're able to really perceive.
So let me give you an example. So when we first launched Google photos, we had one little random feature that we decided to slip into the first release. It was this on this day feature where we showed you photos from one year ago, today, or two years ago today. And it was kind of a side feature. It appeared in like a little feed.
So it wasn't a clear focus of the product and we just put it in there and I thought it was cool. And some people would like it, but it wouldn't be that big of a deal. But over time, I think what we learned is that we just kept hearing from people about how they really loved that feature and how they wished it did more.
And why doesn't it think about this and what if it could do that? And fast forward, I guess it took three years for us to start to realize like, Oh, the reason those people really love that feature is that it's a small slice of this bigger idea, which is remembering your life nostalgia. It's a super powerful thing.
And what if we built a product that was actually focused on that? What if we built a feature that was really focused on that? And that's a thing that we launched now, I guess, 18 months ago, which we call memories. It's that set of tiles at the very top of Google photos, which try to help you just remember your own life in a really lightweight, low time consumption way.
And it's one of our most popular features. It went from zero to something like 250 million users in three months or something crazy. So that's an example of something that we didn't deliberately set out to build, but by observing people's reactions over a very long time scale, we started to realize, oh, there's actually something here that we didn't quite understand.
Often these insights are there and they're slapping you in the face, but it takes a long time for them to become real enough that you'll actually see them. So, what does
Brett Berson: [00:44:55] observation teach you? Is it, you ultimately need a portfolio of product bets with different levels of conviction because sometimes you'll kind of start pulling on a thread that leads you somewhere.
David Lieb: [00:45:07] Yeah. I think that's one of the learnings don't discount ideas you think might be too small or not appealing to a large enough group of people. If you're able to build them in a way that. Does it upend all the rest of your plans? It's probably good to go out on a limb and try a few things. So I think that's one learning.
I think another learning is to not judge any particular feature on face value. If you looked at the stats on that feature, right? They probably would have been pretty good, but it wasn't something that would have screamed. You should like dedicate a team of 50 people to build this product. It's going to be a winner.
We would not have had that learning from there, but by having an, a product long enough for people to start to like understand it and use it and start to tell us why they love it and things that they wanted from it. I think that allowed us to get the conviction to really go deep on it in a subsequent year in the product
Brett Berson: [00:46:01] and early on the stack rank process for product prioritization.
What does planning and execution look like on the product today? And now that you're a large team and are at
David Lieb: [00:46:11] scale. Yeah. It's not a single stack rank anymore. I was the main PM on the product for some period of time. And there was just a point where an exac or some VP at Google would email and say, Hey, I really think you should build this feature.
And it got to the point where I couldn't even make an argument about why or why not. That was a good idea because that stack rank had gotten so broad. Who am I to say, whether it's importing from that, like a camera is more or less important than being able to delete a photo, uh, easily on a Samsung phone?
I don't know. And so when we reached that level of scale and I think it happened, I'm trying to remember. It probably happened when we got to like. Five or six or 7:00 PM rooms and maybe a full engineering team of 200 people, something like that, where it just became clear. We've got to figure out a way to scale this in a different way.
So we can still move really quickly and have individual owners of stuff. But not be bottlenecked by any one individual at the top, we did this approach. I think a lot of companies do it basically called squads. I think there's a blog post out there by Spotify about this, where you kind of just charge your team into a bunch of little teams and each team can own their domain, have their own stack, rank, execute how they want to within the parameters that the overall organization sets.
And so we moved to that model for a long time, and I would say it really succeeded in the goal of letting the team move really fast and operate really quickly. But at some point, those squads get so large that you need to flip it again and go back to like a functional team where you have a PM team and a design team and an engineering team within one of those squads.
And then when those each get big enough, you want to divide those backups. So my opinion on org structure has basically evolved to, as your team grows, you're going to flip from functional to ownership based org structure. Repeatedly. And you're just going to tessellate it down as you go. So can you explain it
Brett Berson: [00:48:04] in different ways, sort of the two models that you ping pong
David Lieb: [00:48:06] back and forth?
Sure. I think a very traditional model or how you organize the team is functional. Right? You have a team of product managers. You have a team of designers. You have a team of engineers, perhaps you had a front end engineering team and a back end engineering team, right? When those teams get. To some sufficient size.
You do specialization. You say, Hey, Joe, you're in charge of the onboarding experience. Okay. And you three designers, you're part of Joe's team. You guys work on that. And Susie, you're now in charge of the sharing flow, you and these engineers and these designers, you own that you've now subdivided your functional team.
And at some point it becomes an organizational nightmare for any one individual to kind of orchestrate the priority and the actions across those different subdivisions. And so you decide to flip your model and go to a, what I would call a squad or ownership based model, a vertical model, where now there's a team and it consists of product managers, designers, and engineers, and it's dedicated to one of those functions.
So the onboarding team or the sharing team, and the beauty of that is each of those teams can move really fast. They don't have to talk to each other as frequently, and it's much more like a constellation of startups. So that sounds really great. But then. As the team size continues to grow. You now have five product managers in the sharing space, right.
And you have to decide, okay, well, how are we going to organize these people? And you flip back to a functional organization where there's like a team of product managers and a team of designers and a team of engineers. And then it works pretty well for awhile, but it just keeps flipping back and forth, right?
But it's a functional organization
Brett Berson: [00:49:39] inside of that area of product ownership,
David Lieb: [00:49:42] correct. Within each of those groups, you're now have functional organization. And then when those teams get even bigger, the functional organizations get so large that you then need to subdivide once more. And so now that one squad has turned into like five squads.
In my theory of organizational development is that that is inevitable and you shouldn't be debating which one is better than the other, which I think is a lot of the debate that I see around the world. And instead you should be debating, where are we on that growth curve? And are we ready to do the next switch yet?
Because it's inevitable. You're going to switch. You just got to decide when to do it. What are
Brett Berson: [00:50:18] the indications that you have to flip from one modality to another
David Lieb: [00:50:21] things like really difficult challenges of deciding what things should be prioritized versus others PM's who are saying, like, I can't convince these people, that this thing is important.
I don't understand why they don't understand this. You see these pieces of evidence that tell you that basically the group of individuals you've tasked with this problem, the problem is now larger than their mental space can't afford. And it's not a knock on their mental space. It's just like humans can only hold a certain amount of things in their brain at once and do it well.
And when you reach that saturation point it's time for some sort of subdivision to happen, a related
Brett Berson: [00:50:55] topic, what's the rhythm of the organization or the annual cadence. Is there a way that you approach planning and internal communications on a quarterly annual? What are the building blocks?
David Lieb: [00:51:07] We do an annual planning process where we try to get the big strategy topics off the table and make sure we're all aligned on where we're going.
And then we kind of ask each team to figure out like, all right, given this strategy where we want to go next year, what are you guys thinking? What do you want to build? And that process we do at an annual basis, but then we revisit it every quarter. And one other thing that we do, which I really like is we try to do both tops down and bottoms up brainstorming about what to do.
And we try to just keep it really simple where some of us on the leadership team, we just do a really simple exercise every year where we just write down on a piece of paper, what are the top four or five or six things you think we got to get right next year that are most important. And we each write that down and we'll end up with a list of, I don't know, 12 things because we all have different ideas.
And we push that down to the teams. We say, Hey, while you guys are doing your planning, you guys are the experts in your area. Not us. Here are the things that we naively think are important. So put it on your list. And if you disagree, tell us why. Or if there are things that you think we should have put on our list that we didn't, we'd love to hear it and understand those.
And often we're wrong. Often it's a misalignment in priority or strategy, and it's really good to iron those problems out early on
Brett Berson: [00:52:18] a similar topic. Is there anything else around the way that you. Run the annual planning process that you think is particularly useful or something that you like about that, or is there any more granular detail in terms of, if I was watching that process every year, what it actually looks
David Lieb: [00:52:34] like or what I would say it's changed a lot in the last three or four years as the team has gotten bigger, as we've gotten more mature.
Let me describe the time that I thought it was most interesting from a learning perspective for others when it was like, what I would describe as like very raw, very unrefined. And so in those days, what we would do is we have a leadership team of 10 or so people, we would literally just rent a house somewhere and we'd go to that house for like a weekend.
And for the first night we just tried to talk about. How things are going, what's going well, what's going badly. And we'd have a bunch of debate from people saying, oh, I think this is going really well. And someone else would say what you think that's going well, that's going so poorly. And here's why. And then the next day we regroup fresh perspectives and we try to talk about what is most important to get right next year?
What outcomes do we want to achieve in the next year? And then finally the last phase would be alright, well, what projects do we need to do in order to achieve those outcomes? And we kind of brainstorm all of that when we did it that way, it was like very human and very raw. And we literally would just sit around in like a circle in some house and debate each other, which I really loved.
And I think it's a great way to do it. If your team size can accommodate that these days, the team is bigger. We're scaled to many different locations. It's not easy for us to do it that way. We do it more in docs and side decks and emails and things like that. But I think that approach, which is basically the three phase approach of.
Taking stock on where you are progress towards your mission. We usually have a canonical document that we publish to the team, which is like our annual plan or like what we want to do in 2021, for example. And I always write a little section at the beginning that I call progress towards our mission. And it's kind of like the state of the union address of like, what have we done?
Well, how have we succeeded in getting towards our mission and where are we still lacking? Where do we need to pursue more in the coming year? I always write that. So that's the first phase of that debate. And then the next phase is cool. How will we know if we've achieved the outcomes we want, which is an outcome focused approach.
And then the last piece, which is the most debatable and the most fun in my opinion is cool. What are we going to do about it? What projects should we do? What should we prioritize? What should we not prioritize? How should we change this project? And that's where it merges into actual product development, where you decide what to build.
Brett Berson: [00:54:52] There's a little bit wanting to spend the last part of our time together, talking about hiring and managing and developing product talent. And so I'm curious at the highest order bit, when you think about the product folks on your team, who you think are truly exceptional, what are they doing or what makes them exceptional?
David Lieb: [00:55:11] Great question. What are the commonalities across these people? One is attention to detail. And or ability to go really deep into problems. This is the thing that I'm a big stickler on. I think that the thing that kills a leader or a product person's ability to actually operate over time is that it get too high in the stack and they lose connection to the product or to the customer.
This was the thing, actually, when I joined Google, the thing that scared me the most about looking at the people above me, when I first joined, seeing how much they wanted to make the decisions and how informed they were about the world, around them, either the customers or the technologies or the product.
And I was just like, wow, this is dangerous. And so like vowed never to let that happen. Even if I become one of those people one day, I want to make sure that I understand the customer really deeply. So I think that is a common thread across the people on our team who are really good. I think another one is.
For lack of a better word, like the ability to inspire others, you can be successful as a product builder, to some extent, if it's just you having to build a thing with a small group of people, but at some point you have to convince people who disagree with you. And I think that skill of inspiring a team to go take on some new challenge that seems either really hard or is different than what they thought they wanted to build.
I think that is another super important skill. There's a set of sub components of being inspirational and they include having a lot of confidence, being a great communicator, having empathy for your audience and understanding like how might you convince them of your point of view given where you understand them to be.
But I think that idea of being inspirational is really important as well. Maybe a third one. Is, and it's kind of connected to being in the details, but it's being really clear credible about how you can build products. There's a set of, I'll just say PMs at Google who really understand their engineering counterparts, or really understand their design counterparts and could explain to me why it's going to be hard to build that feature or why this design solution is really challenging.
And I think the best product builders. Understand what the capabilities of either the tech or the design stack are, and they can then modify their plans to make sure that they build a great product. The PMs who are less effective are the ones who have some great idea in their head. And then they come to me and complain like, yeah, but the engineering team, you know, they don't think they can build it in this timeframe.
And I just, I hear that and I'm like, oh wow, you've done a poor job of figuring out how to build this solution for the customer. You need to go understand engineering more than you do. So I think those are a few of the most important things to make a product builder really effective. The inverse of what we were
Brett Berson: [00:57:59] just talking about.
When you think about great product leadership, is there other things that you think are really important or when you're at your best you're behaving or doing something in a certain way, and that the way that you think about great. Product leadership.
David Lieb: [00:58:18] The only thought that really comes to mind here is being really focused on why you're trying to solve some problem and making sure that you're not solving a related, but way less important problem.
And it happens at the product building phase, like what should we design here? But it also happens at the strategy level for a team and just making sure that you're always pretty confident and clear with everybody around you about why you're doing what you're doing. That's the place where I see product leaders fall short often is where they are going through the motions.
You're like doing all the things that it looks like you should be doing, but you can't crisply articulate. Why what's your strategy here? What's your goal? Who are you solving this for? What is your motivation for the company? But I'm going to happen to myself as well. But the way I detect it is if I ever see somebody who I would describe as they are doing what.
An actor would do. If the actor was told to act like a product leader, they're doing that right now. That means you're in that bad, dangerous zone. That's what I try to look out for. And I look out for it in myself as well, but I think that's the one area that I see things go south. And so the solution is just to make sure you're always really credible and crisp about the most important aspect, which is why are you doing this?
Brett Berson: [00:59:36] That's super interesting. Are there other mental exercises or frameworks similar to what you were just mentioning with what an actor would do sort of in this situation? Are there other little thought exercises like that, that you tend to use on some regular frequency or maybe questions you ask yourself that you find useful?
David Lieb: [00:59:55] Another thing I often think about is how excited do I feel about what we're doing right now? It's a quick little simple barometer check. And if the answer is ever it's okay, it seems like it's the right thing to do. We'll go do that. That's like a big danger zone for me, because it means that for some reason, I'm not excited about what we're doing and either it's my problem, and I need to fix something or it's a problem in what we're building and we just don't realize it.
And we're kind of going through the motions. I'll just give this person a little anecdote. Like towards the end of last year, we had a big year. We did this big redesign. We did this big pricing announcement where we are going to be changing the pricing structure of Google photos going forward, which is really important.
We believe for the future of the product. And toward the end of the year, we were doing our annual planning looking forward to the year and it felt a lot like, yeah, continue the plan from last year. That's our plan. Our plan is to continue and. There were just a handful of days where I was like, ah, this isn't right to me, it doesn't feel like it's connected in the right way.
I'm not excited about what we'll go do next year as a result. And so I kind of stepped back and I, I talked about this, like state of the union thing. I tried to write it from the perspective of a very forward-looking like, why is now like a really critical moment in our team's time? And I didn't have the answer yet, but by forcing myself to do that, I wove in a few threads that we had been pulling on for a few years.
And we formulated this new formulation of kind of some. Old ideas, I guess, but doing that got me from the point of like, okay, we're going to just keep doing what we're doing next year to now how I feel about what we're doing this year, where I'm very excited about how this is the beginning of the next big phase of our product.
And so I would just encourage people to use that mental model. Like if you're ever having a string of days where you're like, yeah, what we're doing is okay, but it's not that exciting to me right now. Use that as a check to yourself and often you can go fix it, then that example.
Brett Berson: [01:01:51] Was the unlock a meaningful change in what you're doing this year?
Or was it rearchitecting the narrative or the way in which you were describing it? Yeah,
David Lieb: [01:02:02] a little of both. So I can give a little bit more detail. So I describe Google photos in a few acts or phases, right? So the first act of Google photos was to build a credible file solution, a place for you to put your photos and videos.
It was very media file centric thing. And we had automatic organization. We had search, we had some of these things, but primarily it was like, I need a place to put all these things that doesn't run out of space. The second act, which was. Uniquely unlocked by success in the first act was this notion of nostalgia, right?
We call it the stall GIA machine. That's what we say internally. And it was, again, I told the story, it was this realization that, oh, wow. That little feature that we had, it seems really powerful. What if we like go really deep on that and build something great. And that's kind of the phase that I would say we're in or finishing up right now or in the middle of is this phase of making Google photos, a really great place to relive your memories.
And so this last summer I spent a bunch of times this was right at the beginning of the quarantine. I was kind of holed up alone and didn't see any, a bunch of people. So I was going deep thinking philosophically of like, what is the next act? What are we really building? If we succeed in this nostalgia machine, what is uniquely unlocked that we could go tackle next, which is a much bigger problem.
And where I landed was this idea of building each person's life record. And so it's a simple phrase, but I think it's pretty deep, you know, We all live our lives. We do our things. We go on podcasts, we send emails, we have kids, we go to soccer games and at the end of the day, we're going to die. And when we look back, I think the stuff that really matters is the stuff that we've chosen to keep in that life record.
But today we rely mostly on this very fallible meat brain to remember the stuff that was important. And it's really, really poor, especially when you get old, your meat brain starts to fall apart. So. What if we could build for each human being a record of their lives that they can use to reflect on, to bring meaning, to pass along to others around them.
And so we started pulling on that thread and realizing the success that we've had in that file system thing and the success that we've had in that nostalgia machine idea, it uniquely sets us up to go tackle this way, bigger problem. And so that was like the backdrop that made me say, like this year 20, 21, we got to start.
Building the building blocks of what that life record thing is going to be in 10 years. And so that took a year where it felt like, and this is the narrative piece where it felt like, yeah, we're just kind of continuing the tracks that we're on. It's great work, but I'm not that pumped about it and turned it into, if we do a few things differently, what we will actually be doing in 2021 is beginning to build the bedrock upon which every human being's life record is going to lie for the next 10 or 20 or 30 years.
And that got me and some others pretty excited
Brett Berson: [01:04:50] on the theme of nostalgia. I thought we could end on just a couple of questions that maybe are a bit nostalgic for you. And the first one was, I think that you started your career at Texas instruments for, and not for like six months for many years. Yep.
That's right. It's fairly atypical to have a consumer product leader that went from zero to a billion users, plus start a decent chunk of their career at a company like Texas instruments. So I'm curious. What that experience taught you, if anything that is still a part of the way that you behave or think,
David Lieb: [01:05:24] or your worldviews.
Yeah. Wow. It's fascinating. You might ask, why did you work at Texas instruments? And the answer very simply is I grew up in Dallas and when I got my first internship after whatever it was sophomore year in college, I was away at school the whole year and I was homesick and I wanted to go home. And so I needed to find like a job at home.
So that's why I went to Texas instruments and I ended up doing four internships in a row there. And then after I did my master's, I decided to go back and work there full time. So it's just, it's fascinating how some seemingly large portions of my career, it was decided because I was homesick. So that's just an aside.
What did I learn at Texas instruments that is applicable here? I think, I mean, the number one thing is. You know, I was an engineer at TEI and worked on some really fascinating technologies that are very applicable to my work now. But the thing I learned was that I really had a yearning or a desire to be involved in not just the tech piece or the science piece, but also the end user or the customer and understanding what do we need to build?
How do we package this together in a way that's really useful for them. And ultimately, that's why I decided to leave Tia. That's why I went to business school, hoping to learn those skills there. And then by chance, I had this idea for an iPhone app and dropped out of business school and actually learned those lessons, building the startup.
One other thing I remember from Texas instruments is the power of relationships with really, really great people. There are two people specifically that I met at Texas instruments. One of which became my co-founder at bump and like one of my closest friends and colleagues to this day. And the other is a guy that eventually did.
We got him to come to Google and he's just one of the most creative and talented engineers I've ever worked with. And just thinking about that guy, Andrew makes me want to be more creative and want to try to push the envelope a little bit more. So the learning is you'll come across these people in your career that are really phenomenal people, and you might meet them in a really weird context.
Yeah. We were both algorithm engineers at Texas instruments in Plano, Texas. Um, but those connections can be pretty deep and years later, like decades later, they can become your co-founder or they can become a key part of how you think about building products. And on
Brett Berson: [01:07:34] that related note, the question I actually wanted to end on is.
Who are the people that have helped you grow or change or find the next step function in your life and career. And maybe if you think of one, two or three of them, what did they unlock for you? Or what did you learn from them that was
David Lieb: [01:07:56] meaningful? The number one person is somebody I just mentioned, which is Andy Hybris.
My co-founder of bump. I call him my career coach, but he, you know, he was my co-founder, he's an engineering guy. He's a tech guy. But I think the thing that he's been able to do for me is just boil down a lot of the noise and a lot of the pomp and circumstance that exists around people's careers into just like a really simple engineering viewpoint.
Like, Hey, Dave, What do you want to build next, as opposed to what's the next step of your career? How do you get experienced in this area? Or he's able to just boil it down to a way that at least for me really resonates. So I think maybe I'll just like pivot the question slightly. I think people often look for mentors or people.
They can go have a career conversation with and get a lot of insight and value and walk away really happy. In my opinion, in my experience, a better way to do it. An easier way to do it is work with people who are really great. And in the trenches doing the job, working on stuff that you guys love, you'll find that they have an influence on you, which in hindsight is transformational, but you don't have to work for it.
You just have to go build fun stuff together and it happens. So that's what I would end on is people stress about their career and learning, and growth and all this stuff. And the simple hack is just go build. Things with great people and you'll find that you learn a whole lot great
Brett Berson: [01:09:20] place to end. Thank you for all of this time.
This was such a great
David Lieb: [01:09:24] conversation. Likewise. It was fun.