David Lieb on Bump, Google Photos and Product Judgment

David Lieb trained as an engineer and worked at Texas Instruments before business school. In his first week there, exchanging phone numbers with classmates felt unnecessarily cumbersome, so he began a side project to make it easier on the newly opened iPhone App Store.

The app became Bump. Lieb initially hoped it might earn enough to cover school expenses, but usage exceeded expectations. He and his cofounders kept working, entered Y Combinator and ultimately did not return to school. After several pivots, the company focused on photo sharing and was acquired by Google.

A startup teaches ownership, Lieb says, because the founders must initially write code, design, market and handle press themselves. Generalists can connect those functions in a small team, whereas a large organization has specialists for nearly every problem.

Stebbings says he finds it hard to let go of founder-led work. Lieb agrees delegation eventually matters but thinks many founders hand over essential jobs too early. He suggests waiting until the founder understands the product and customer deeply and the work consumes time needed for other important priorities.

Asked how a founder knows there is product-market fit, Lieb gives a demanding heuristic: if it is unclear, the company probably does not yet have it. He looks for demand so strong that the team spends its time serving customers and keeping up, while acknowledging that early resonance with a small group can be a useful signal.

Product-market fit can disappear, he adds, because customer needs, technology and alternatives change. His standard is a rule of thumb, not a precise metric that applies identically to every business.

Why sell Bump? Lieb says the company needed more funding and the founders were unsure that raising it was the right choice for the team or investors. At the same time, they saw a growing problem: people were taking far more phone photos than they knew how to store, back up or organize.

At Google, he says the central decision behind Google Photos was a clear mission to be a home for people's memories. The team explicitly chose not to build a social network or a broad creative photo editor. That boundary guided product decisions and helped people decide whether the team was right for them.

Some colleagues from the Google+ team wanted to build social products and moved elsewhere; others joined because they wanted to work on the memories problem. Lieb argues that continually reinforcing a mission helps a team make coherent choices. This is his account of the product's development, not an independent comparison with every other team.

He says he had left Google the previous week after nine years. In the prior year he had been diagnosed with leukemia and spent a year receiving chemotherapy; his team continued operating during his absence. Seeing that it could work without him, alongside a frightening hospital experience, led him to reconsider how he wanted to spend his time.

Lieb says he wanted to return to working with early-stage founders and was joining Y Combinator. His description of illness is a personal experience, not medical guidance. The interview was published in 2022, so his employment and health comments refer to that period.

Is product more art or science? Lieb says it depends but, in his opinion, great products often come from a small group that cares deeply about a customer and the details. Experiments are useful, he argues, but they cannot replace the judgment and empathy involved in deciding what to build.

Stebbings asks whether founders who personally experienced a problem have an advantage over detached analysts. Lieb says analytical methods can limit both large mistakes and unexpected wins. He believes intuition can lead to unusual opportunities but also wider downside; this is his framework, not a demonstrated law of product development.

He suggests that experienced founders may avoid unconventional ideas because they know the game's norms, while naive founders sometimes pursue them. What should remain rational, he says, is the effort to understand whether a real person has a meaningful problem.

Lieb compares intuition to a sophisticated model trained on experience. His practical advice is to put more inputs into it: learn about customers, try experiments and then use judgment about what to do next. The comparison is a metaphor for experience, not a literal technical equivalence between human thought and machine learning.

The balance between speed and polish depends on context. Google Photos could expect substantial attention at launch and asked people to trust it with irreplaceable memories, so the team invested months in a fast, reliable photo grid, including difficult network conditions.

By contrast, Lieb says Bump's first version was poorly designed and embarrasses him in retrospect, but shipping it produced learning. A small startup may rationally accept rough edges, while an established company launching a trust-sensitive product may need a higher initial bar.

Stebbings asks how to avoid overreacting to the loudest users. Lieb says first consider whether the people providing feedback represent the future audience. Then listen for the reason behind what they say rather than automatically implementing their proposed solution.

He recommends asking when a problem last occurred, what the person did without the product and why the issue matters. Those questions reveal the surrounding life and context that a narrow reaction to a screen can miss. He wants the team to understand the person, not just collect feature requests.

Data is valuable for seeing patterns, but Lieb dislikes relying only on aggregates such as total daily users or comments. He prefers measures that illuminate individual behavior, especially retention of cohorts of users who began at the same time.

A cohort retention curve asks how many of an initial group keep using a product over successive periods. He looks for a curve that eventually levels off, while noting that the relevant interval may be daily, weekly or annual depending on the product.

Stebbings asks whether obviously unqualified users should be excluded. Lieb says a cohort may be defined using a meaningful qualification step, and an initial drop can be expected. The important question is whether people who understand and need the product continue to use it over time.

He says many founders never examine a retention curve at all, and admits that he made the same mistake at Bump when an investor asked about it. His advice is to understand the metric before a fundraising meeting, not merely assume the answer is good.

For Google Photos, he considered daily or weekly activity more revealing than a monthly active-user total, because the intended use was frequent. A monthly aggregate can include people who opened the app once for an accidental or incidental reason and do not necessarily value it.

At Bump, he recalls 150 million installs and many sessions lasting less than a second. The team realized some people accidentally tapped Bump's blue icon when they meant to open Facebook. He estimates that about 20% of observed usage was accidental in that context; the anecdote illustrates why an aggregate can mislead, not a general rate for apps.

Stebbings asks what retention percentage is good. Lieb says there is no single answer: a curve that levels off at 5% might be valuable if retained users return at an appropriate interval and the activity is valuable to both them and the business. He uses Airbnb as an illustrative recollection, without presenting its actual cohort data.

Numbers show what happened, not necessarily why. Lieb warns against making a roadmap directly from a graph: an unusual pattern should prompt investigation and conversations with users. In the Bump example, understanding accidental taps required interpreting the behavior behind the short sessions.

The host asks whether people from major technology companies are too far from customers for early startups. Lieb says some are excellent generalists, while others have relied on a network of specialists and have never had to own the whole problem. He cautions against treating a prestigious employer's name as proof either way.

A large company may have an expert for every issue, but that can leave no one feeling personally responsible for the product's holistic success. Lieb credits his startup experience with making him comfortable collecting advice and ultimately owning decisions himself.

To create a culture of product obsession, he says a leader must actually care about the customer and the details rather than perform enthusiasm. He recalls showing engineers slow-motion recordings of glitches in the Google Photos grid, signaling that people could raise concerns about quality before launch.

An early product team may be only one person, he says, and hiring a large team immediately after a seed round can be premature. For an early-stage product hire, he values ambition and a willingness to handle a broad range of problems alongside reasonable ability.

To assess product judgment, he suggests asking candidates what products they love or dislike and, more importantly, why. He wants to hear whether they can reason from a user's problem to an explanation of the experience rather than offer a rehearsed list of features.

Lieb says he hired a product leader too early at Bump. The company had growth in headline usage but had not solved how users or another party would pay for the product. He realized he had delegated the company's most important unresolved problem while still wanting to lead product himself; he and the hire parted ways.

At a later stage, he recommends hiring for skills complementary to the founder's rather than duplicating the founder's strengths. At Google Photos he sought a product leader who could fill gaps in his own abilities; a founder planning to leave may instead need someone who can lead the whole function.

Stebbings worries about product executives who add process without product vision. Lieb agrees that tenure and the size of a previously managed team are insufficient on their own. He still values strong operators at scale, provided someone on the team supplies product craft and vision; that person need not hold the chief product officer title.

In his experience, some of the strongest Google Photos product managers came from unrelated backgrounds. He attributes their performance to ambition, willingness to understand customers and persistence. That is his experience and interpretation, not evidence that domain experience is generally harmful.

He describes two core product skills: deeply understanding users and crafting feasible solutions. The first requires approaching people and accepting rejection; the second requires enough knowledge of engineering and design to distinguish an achievable solution from something not currently possible.

Lieb says his engineering background helped him push for quality at Google even though he did not personally write Bump's code. He could understand technical discussions and challenge the team when he believed a better implementation was possible.

For a very small startup, a product review may simply be a conversation with the person sitting nearby. In a larger team, he prefers reviews organized around a specific proposal or decision rather than recurring presentations for their own sake.

The responsible product manager can circulate a concise document and ask for focused feedback asynchronously. Then the relevant design, engineering, product and other leads can use a meeting to debate unresolved questions instead of rereading the document aloud.

Asked how to make people comfortable speaking, Lieb says he tries to behave authentically and reduce the sense that important people in the room cannot be challenged. He believes a team loses valuable information if junior participants are afraid to express concerns.

Video meetings can give everyone an equal-sized square and let some people collect thoughts in a document, he says, but they can also remove informal conversation. During the pandemic he sometimes joined meetings five to seven minutes late so colleagues would talk to one another first; that was his technique, not a general requirement.

He thinks the common failure in product reviews is spending group time on material that could have been read beforehand. He prefers debate over the important unresolved question, even when it becomes heated, to a room of people merely agreeing with the leader.

After a decision, he wants one directly responsible individual for each action and a clear deadline. Shared participation is useful, but diffuse ownership can leave nobody accountable for resolving obstacles and getting the work done.

Angel investing taught him that successful companies can work in very different ways. He looks for founders with determination and the ability to persuade the right people to join and customers to listen. His angel investments create a financial interest in the companies he discusses.

He recalls meeting Flexport founder Ryan Petersen at a wedding and making a small early angel investment because he believed Petersen would compete fiercely. Lieb says Flexport might become his best investment by multiple but explicitly notes that the result is uncertain until cash is returned; he describes it as one of his smallest checks.

He generally keeps later angel check sizes reasonably consistent because it is difficult to know in advance which company will succeed. Stebbings notes that acting on unconventional ideas may be harder in a venture fund. Both are discussing investment approaches, not promising returns.

When the host questions whether technical founders have conventional charisma, Lieb says credibility depends on the audience. A developer-tools founder may persuade engineers through a different kind of credibility than a polished public speaker; the relevant test is whether the founder can attract the right team and customers.

Asked whether Google fired him twice, Lieb clarifies that he was asked to leave a team twice, not fired from Google. He says he resisted an internal decision to keep photos tied to a social-network direction and sought support from people with access to senior leadership. His account is his recollection of that internal dispute.

He says he no longer feels the same need to prove Bump was worthwhile or that he can build a product people love. Starting at Y Combinator brings a different uncertainty: his angel investments have not all concluded, and he does not yet know how well he will select early-stage companies over decades.

He admires product leader Kevin Weil, advises new leaders to get into the details quickly and argues that product managers should take broader responsibility for design, engineering and analytics. His aim is stronger ownership rather than an excessively narrow job description.

For a product strategy he admires, he cites Tesla's published master plan as an example of articulating a sequence of conditions that could create a large outcome. That is his assessment of the plan, not verification that every part was achieved. The interview ends with both speakers thanking each other.