Andrew Chen Archives

The hardest part of any new product launch is the beginning, when it’s not quite working, and you’re iterating and molding the experience to fix it. It may be the hardest phase, but it’s also the most fun.

The Product Death Cycle
All of this was on my mind when I saw a great tweet from about a year ago, on the Product Death Cycle, when things go wrong. David Bland, a management consultant based in San Francisco, tweeted this diagram:

This is what I’m calling the Product Death Cycle
– @davidjbland

A year ago when I saw this, I retweeted this diagram right away, and a year later, it’s hit 1,400+ RTs overall. This diagram has resonated with a ton of people because sadly, we’ve seen this Product Death Cycle happen many times. We’ve maybe even fallen into it ourselves – it’s all too easy. I’ve written about this phase before, in After the Techcrunch bump: Life in the Trough of Sorrow.  As well as some thoughts and strategies related to getting to product/market fit sooner rather than later.

Let’s talk about each step of this cycle, why it happens, and present a list of questions/provocations that might allow us to escape.

1) No one uses our product
The natural state of any new product is that no one’s using it :) So that’s not a problem in itself. However, the way you react to this problem is what causes the Product Death Cycle.

2) Ask customers what features are missing
One of the big early mistakes is to be completely user-led rather than having a product vision. This manifests itself in asking users “What features are missing?”

Here are the problems with this approach:

• Users who love your product now may not represent the much larger market of non-users who’ve never experienced it. So the feedback you get might be skewed towards a niche group, and the features they suggest may not be mainstream
• User research is great for coming up with design problems, but you can’t expect users to come up with their own design solutions. That’s your job! They may be stuck in a certain paradigm and won’t have the tools/skills to come up with their own solutions. Faster horses and all that
• “What features are missing?” assumes that just adding more features will somehow fix the problem. But there are many, many other reasons why your product may not be working- maybe the pricing is wrong. Or it’s not being marketed well, the activation is broken, or the positioning sucks, etc.

Even the Simpsons know that slavishly listening to feature requests is a bad idea. Thus the episode about The Homer, a car that tried to appeal to everyone:

Instead of asking for what’s missing, instead the solution is to ask- what is the root cause of users not using the product? Where’s the fundamental bottleneck? In a world where 80% of daily active users are lost within 30 days, there’s a lot of reasons why users are bouncing before they even get into the “deep engagement features” you’ve built out. Asking engaged users what features they want won’t help much- instead you’ll likely get a laundry list of disorganized features that will push you towards your competitors.

One book recommendation on this topic: Harvard Business School professor Youngme Moon’s book on competitive differentiation precisely describes the process in which customer research quickly leads to muddled differentiation, it’s worth reading.

3) Build the missing features
The second jump in the Product Death Cycle is to take features that customers have suggested, and just build the missing features. However, this quickly falls into the Next Feature Fallacy, which is the mistaken belief that just adding one more new feature will suddenly make people want to use your whole product.

As I discussed in that essay, every product has an amazing dropoff of usage from when people first encounter it:

I’ve also published some real-life data at Losing 80% of mobile users is normal. The point is, most interaction with a product happens in the first few visits. That’s where you can ask the user to setup for long-term retention and to present the user with a magic moment. Building a bunch of “missing” features is unlikely to target the leakiest part of the user experience, which is in the onboarding. If the new features are meant to target the core experience, it’s important that they really improve the majority workflows within the UI, otherwise people won’t use them enough to change their engagement levels.

To break out of this part of the Product Death Cycle, ask yourself- is this enough of a change to influence the experience? Is it far enough “up the funnel” to impact the leakiest parts of the product experience? Is this just another cool feature that only a small % of users will experience?

Breaking out
The Product Death Cycle is tricky because it’s driven by the right intentions: Listen to customers and build what they want. People in the Product Death Cycle naturally believe that they are doing the right things, but good intentions don’t translate to good traction. Instead, ask “why?” over and over, to understand the root cause for lack of growth.

The response to these root causes should consist of a large toolkit of responses- maybe marketing: Pricing, positioning, distribution, PR, content marketing, etc. Maybe it has to do with the strategy: Going high-end instead of low-end. Building a utilitarian product instead of a network-based one, or vice versa. The point is, the solution should be tailored to the root cause, rather than to be explicitly driven by the desire of every product team to build more product.

Thanks again to David Bland for sharing the Product Death Cycle diagram with all of us.

Couple quick things that I wanted to batch up in a single post.

A quote from me in the Wall Street Journal today
First, there’s a quote from me in the Wall Street Journal today, for an article covering the opportunities/challenges of dating apps. I’ve been told the story will be on page B1 of the paper edition, but here’s the link for everyone who loves trees: The Dating Business: Love on the Rocks by Georgia Wells. The quote was pulled from a recent essay of mine on why investors are often skeptical of dating startups, which you can read: Why investors don’t fund dating.

Podcast interview with Codenewbies
Last week, I did a fun, casual interview with Codenewbies, a podcast targeted at people learning to code. In the interview, I talk about how taking a year of Computer Science in college, plus internships as a Software Engineer, helped me break into my first post-college job, at venture capital Mohr Davidow Ventures. And I also have a short story about the first real program I ever wrote, in GW-BASIC back in fifth grade, where I managed to blow up one of the Mac Plus computers in class.

Let’s meet up in person (San Francisco)
I’m kicking off a series of small-group gatherings to grab drinks/food in SF – something like ten people, in SOMA. If you’re based in the area, I’d love to catch up and meet. I plan to include friends/guests from top startups and tech companies in the Bay Area to join us- here’s how to register.

Follow me on Twitter
Just a reminder- if you’re not already following me, here I am: @andrewchen

Recent essays, if you missed them
Finally, I wanted to include a list of some of my recent essays in case you missed them. I’m pretty happy with how the last couple have turned out, so I hope you enjoy.

• New data shows losing 80% of mobile users is normal, and why the best apps do better
• The Next Feature Fallacy: The fallacy that the next new feature will suddenly make people use your product
• Why we should aim to build a forever company, not just a unicorn
• Photos of the women who programmed the ENIAC, wrote the code for Apollo 11, and designed the Mac
• Ten classic books that define tech

Thanks for reading!

Exclusive data on retention curves for mobile apps
In a recent essay covering the Next Feature Fallacy, I explained why shipping “just one more feature” doesn’t fix your product. The root cause is that the average app has pretty bad retention metrics. Today, I’m excited to share some real numbers on mobile retention. I’ve worked with mobile intelligence startup Quettra and it’s founder/CEO Ankit Jain (formerly head of search+discovery for Google Play) to put together some exclusive data/graphs on retention rates** based on anonymized datapoints from over 125M mobile phones.

Average retention for Google Play apps
The first graph shows a retention curve: The number of days that have passed since the initial install, and what % of those users are active on that particular day. As my readers know, this is often used in a sentence like “the D7 retention is 40%” meaning that seven days after the initial install, 40% of those users was active on that specific day.

The graph is pretty amazing to see:

Based on Quettra’s data, we can see that the average app loses 77% of its DAUs within the first 3 days after the install. Within 30 days, it’s lost 90% of DAUs. Within 90 days, it’s over 95%. Stunning. The other way to say this is that the average app mostly loses its entire userbase within a few months, which is why of the >1.5 million apps in the Google Play store, only a few thousand sustain meaningful traffic. (*Tabular data in the footnotes if you’re interested)

Ankit Jain, who collaborated with me on this essay, commented on this trend:

Users try out a lot of apps but decide which ones they want to ‘stop using’ within the first 3-7 days. For ‘decent’ apps, the majority of users retained for 7 days stick around much longer. The key to success is to get the users hooked during that critical first 3-7 day period.

This maps to my own experience, where I see that most of the leverage in improving these retention curves happen in how the product is described, the onboarding flow, and what triggers you set up to drive ongoing retention. This work is generally focused on the first days of usage, whereas the long-term numbers are hard to budge, no matter how many reminder emails you send.

Note that when we say that these DAUs are being “lost” it doesn’t mean that users are suddenly going completely inactive – they might just be using the app once per week, or a few times per month. Different apps have different usage patterns, as I’ve written about in What factors influence DAU/MAU? with data from Flurry. Just because you lose a Daily Active User doesn’t mean that you’re losing a Monthly Active User, yet because the two correlate, you can’t sustain the latter without the former.

How do the best apps perform? Much better.
The second graph we’ll discuss is a comparison of retention curves based on Google Play ranking. The data shows that there is a very clear and direct correlation:

The top apps have higher D1 retention rates, and end with much stronger absolute D30 numbers. However, interestingly enough, the falloff from D1 to D30 is about the same as all the other apps. Another way to say it is that users find the top apps immediately useful, use it repeatedly in the first week, and the drop off happens at about the same speed as the average apps. Fascinating.

Bending the curve happens via activation, not notification spam
To me, this is further validation that the best way to bend the retention curve is to target the first few days of usage, and in particular the first visit. That way, users set up themselves up for success. Although the data shown today relates to mobile apps, I’ve seen data for desktop clients and websites, and they all look the same. So whether you’re building a mobile app or something else, the same idea applies:

• For a blogging product, you might want users to pick a theme, a name, and write their first post, to get them invested.
• For a social service, you might want users to import their addressbook and connect to a few friends, to give them a strong feed experience and opt them into friend notifications
• For a SaaS analytics product, you might want users to put their JS tag on their site, so that you can start collecting data for them and sending digest emails
• For an enterprise collaboration product, you might want users to start up a new project and add a couple coworkers to get them started

Each of the scenarios above can have both a qualitative activation goal, as well as quantitive results to make sure it’s really happening. Whatever you do, sending a shitload of spammy email notifications with the subject line “We Miss You” is unlikely to bend the curve significantly.

I hate those, and you should too.

(Thanks again to Ankit Jain of Quettra for sharing this data and assisting me in developing this piece. More from them here, which examines app-by-app retention rates for messaging apps)

*Tabular data

**Methodology
Some notes on methodology below, shared by Quettra:

Quettra software, that currently resides on over 125M Android devices worldwide, collects install and usage statistics of every application present on the device. For this report, we examine five months of data starting from January 1, 2015.

Since we exclusively consider Android users in this study, we exclude Google apps (e.g. Gmail, YouTube, Maps, Hangouts, Google Play etc.) and other commonly pre-installed apps from our study to remove biases. We also only consider apps that have over 10,000 installs worldwide.

A note on privacy, which is very important to us: All data that we collected is anonymized, and no personally identifiable information is collected by any of our systems. From our understanding, this is the first time ubiquitous mobile application usage has been analyzed at such large scale. Quettra does not have a direct relationship with any of the apps or app developers mentioned in this report.

Ada Lovelace, an early computing pioneer, featured prominently in Walter Isaacson’s book The Innovators

Innovation is messy, and too easy to oversimplify
After finishing Walter Isaacson’s biography of Steve Jobs, I eagerly devoured his followup book, The Innovators. This book zooms out to focus not on an individual, but on the teams of collaborators and competitors who’ve driven technology forward, and the messiness of innovation. The stars of the story turn out to be the often unappreciated women who contributed to computing at key moments, and the book fittingly begins and ends with Ada Lovelace, an 19th century mathematician who defined the first algorithm and loops. I recommend the book, and here are the NYT and NPR write-ups which you can check out as well.

Isaacson’s book resonated with me because once you know how messy the success stories are, it’s obvious why the media always chooses to simplify things down to just a few characters with simple motivations. As a result, we know what kind of shoes that Steve Jobs wears, but forget the names of the people around him who worked for years to make the products we love.

The stories from the book have been floating around in my brain for a few months now, and coincided with two other pieces that went viral on Twitter/Facebook. First, there’s been some great photos of Margaret Hamilton who led the software development for Apollo 11 mission. Second, there was a discussion on Charlie Rose on the women who worked on the original Macintosh. I did some research and put together a few photos of these key pioneers from computing history. Seeing their faces and names help make them more real, and I wanted to share the photos along with some blurbs for context.

If you have more photos to send me, just tweet them at @andrewchen and I’ll continue to update this article.

Women of ENIAC
One of the most interesting backstories in Isaacson’s book is the fact that women mostly dominated software in the early years of computing. Programming seemed close to typing or clerical work, and so it was mostly driven by women:

Bartik was one of six female mathematicians who created programs for one of the world’s first fully electronic general-purpose computers. Isaacson says the men didn’t think it was an important job.

“Men were interested in building, the hardware,” says Isaacson, “doing the circuits, figuring out the machinery. And women were very good mathematicians back then.”

In the earliest days of computing, the US Army built the ENIAC, the first electronic general purpose computer in 1946. And women programmed it – but not the way we do now – it was driven by connecting electrical wires and using punch cards for data.

Left: Patsy Simmers, holding ENIAC board Next: Mrs. Gail Taylor, holding EDVAC board Next: Mrs. Milly Beck, holding ORDVAC board Right: Mrs. Norma Stec, holding BRLESC I board.

Left: Betty Jennings. Right: Frances Bilas

Jean Jennings (left), Marlyn Wescoff (center), and Ruth Lichterman program ENIAC at the University of Pennsylvania, circa 1946.

More photos here.

Margaret Hamilton and Apollo 11
Twitter has been circulating this amazing photo of Margaret Hamilton and printouts of the Apollo Guidance Computer source code. This is the code that was used in the Apollo 11 mission, you know, the one that took humankind to the moon. This is how Margaret describes it:

In this picture, I am standing next to listings of the actual Apollo Guidance Computer (AGC) source code. To clarify, there are no other kinds of printouts, like debugging printouts, or logs, or what have you, in the picture.

There are some nice articles about this photo on both Vox and Medium, which are worth reading.

Here it is, along with a few other photos of her during this time:

A side note to this that I found pretty nerdtastic is that the the guidance computer used something called “core rope memory” which was weaved together by an army of “little old ladies” in order to resist the harsh environment of space.

To resist the harsh rigors of space, NASA used something called core rope memory in the Apollo and Gemini missions of the 1960s and 70s. The memory consisted of ferrite cores connected together by wire. The cores were used as transformers, and acted as either a binary one or zero. The software was created by weaving together sequences of one and zero cores by hand. According to the documentary Moon Machines, engineers at the time nicknamed it LOL memory, an acronym for “little old lady,” after the women on the factory floor that wove the memory together.

Here’s what it looked like:

Susan Kare, Joanna Hoffman and the Mac
Megan Smith, the new chief technology officer of the United States, was on Charlie Rose recently and referenced the fact that the women who worked on the Macintosh were unfairly written out of the Steve Jobs movie – you can see the video excerpt of her speaking about it here. I tracked down the photo she was referring to, and wanted to share it below.

Macintosh team members: Row 1 (top): Rony Sebok, Susan Kare; Row 2: Andy Hertzfeld, Bill Atkinson, Owen Densmore; Row 3: Jerome Coonen, Bruce Horn, Steve Capps, Larry Kenyon; Row 4: Donn Denman, Tracy Kenyon, Patti Kenyon

On the top of the pyramid photo is Susan Kare, who was a designer on the original Mac and did all the typefaces and icons. Some of the most famous visuals, such as the happy mac, watch, etc., are all from her.

One cool thing to add to your office: Some signed/numbered prints of Susan’s most famous work. I have a couple – here’s the link to get your own.

Here’s a May 2014 talk. Susan Kare, Iconographer (EG8) from EG Conference on Vimeo.

Another key member of the original Mac team, Joanna Hoffman, isn’t in the pyramid photo but I was able to find a video of her talking about the Mac on YouTube, and embedded it below. Here’s the link if you can’t see the embed. She wasn’t in the Steve Jobs movie from Ashton Kutcher, but it looks like she will be played by Kate Winslet in the new Aaron Sorkin film coming out.

Here’s the video:

Bonus graph: Women majoring in Computer Science
Hope you enjoyed the photos. If you have more links/photos to include, please send them to me at @andrewchen.

As a final note, one of the most surprising facts from Isaacson’s book is that early computing had a high level of participation from women, but dropped off over time. I was curious when/why this happened, and later found an interesting article from NPR which includes a graph visualizing the % of computer science majors who are women over the last few decades.

The graph below is from the NPR article called When Women Stopped Coding – it’s worth reading. It speculates that women stopped majoring in Computer Science around the time that computers hit the home, in the early 80s. That’s when male college students often showed up with years of experience working with computers, and intro classes came with much higher expectations on experience with computers.

A few weeks ago, I read this tweet, and found myself nodding my head in vigorous agreement.

The Next Feature Fallacy: the fallacy that the next feature you add will suddenly make people want to use the entire product.

— Joshua Porter (@bokardo) May 14, 2015

For people who love to build product, when something’s not working, it’s tempting to simply build more product. It leads to the launch-fail-relaunch cycle that I alluded to in a previous essay, Mobile app startups are failing like it’s 1999. However, this rarely works, and when you look at the metrics, it’s obvious why.

The metrics behind the Next Feature Fallacy
Let’s go into the numbers. The reason why the Fallacy is true can be described by one simple diagram, which might be described as the most tragic curve in tech:

The above diagram shows the precipitous drop-off between initially attracting a user versus the difficulty of retaining them over the first month. Perhaps it reminds you of the diagram, popularized by Edward Tufte, of the destruction of the Napoleon’s Grande Armée during his disastrous invasion of Russia. The curve drops off fast- very fast. I’ve seen a lot of real data around this, and believe me, there are very few cases where things look pretty.

Some example metrics for a web app with average (but not great) numbers:

• 1000 users visit your homepage to check out your product
• 20% sign up
• 80% finish onboarding
• 40% visit the next day after signup
• 20% visit the next week after signup
• 10% visit after 30 days after signup
• After 30 days, 20 users (out of 1000!) are DAUs

This is pretty typical, and you can see the steep drop-off.

And yes, occasionally I’ve seen better numbers than this, for apps that have built a great brand, or are getting most of their traffic through high-conversion referrals. Or the D1/D7/D30 for certain categories, like messaging apps, are often 2-3X higher than what I’m publishing above. But in the main, everyone is a bit depressed about their numbers. I’ve written about the routine mediocrity of these metrics in more detail here: Why consumer product metrics are all terrible.

The vast majority of features won’t bend the curve
These metrics are terrible, and the Next Feature Fallacy strikes because it’s easy to build new features that don’t target the important parts. Two mistakes are often made when designing features meant to bend this engagement curve:

• Too few people will use the feature. In particular, that the features target engaged/retained users rather than non-users and new users
• Too little impact is made when they do engage. Especially the case when important/key functions are displayed like optional actions outside of the onboarding process.

These mistakes are made because there’s often the well-intentioned instinct to focus on features that drive deep engagement. Of course you need a strong baseline of engagement, but at its extreme, this turns misguided because features that aren’t often used can’t bend the curve. A “day 7 feature” will automatically be used less than an experience tied to onboarding, since the tragic curve above shows that fewer than 4% of visitors will end up seeing it.

Similarly, a product’s onboarding experience can be weak if there isn’t a strong opinion on the right way to use (and setup) the product. In the early Twitter days, you’d sign up and immediately be dropped onto a blank feed, and a text box to type in your status. While this might let you explore the product and do anything, ultimately this is a weaker design then asking you to follow a bunch of accounts, which is the current design. Understanding that Twitter is meant to be mostly used as a reader, potentially without tweeting much, is a deep insight and a strong opinion that has paid dividends for the product.

Another frame to think about is to make sure a new feature doesn’t assume deep engagement/investment in your product. Let’s introduce the concept of an engagement wall, which exists at the moment that your product asks the user to deeply invest in their product usage, where “behind the wall” means that the feature can only be experienced once the users buys into a product, and engages. An example might be a high-effort, low % action like posting a photo, creating a new project, or dropping files into a folder. In front of the wall means features that create value without much investment, such as browsing a feed, rating some photos, or clicking a link. If you build a bunch of amazing features that are behind the engagement wall, then chances are, only a small % of users will experience the benefits. Adding a bunch of these features won’t bend the curve.

How to pick the next feature
Picking the features that bend the curve requires a strong understanding of your user lifecycle.

First and foremost is maximizing the reach of your feature, so it impacts the most people. It’s a good rule of thumb that the best features often focus mostly on non-users and casual users, with the reason that there’s simply many more of them. A small increase in the front of the tragic curve can ripple down benefits to the rest of it. This means the landing page, onboarding sequence, and the initial out-of-box product experience are critical, and usually don’t get enough attention.

Similarly, it’s important to have deep insights on what users need to do to become activated, so that their first visit is set up properly. For social networks, getting them to follow/add friends is key, because that kicks off a number of loops that will bring them back later on. For a SaaS metrics app, it might be getting a JS tag onto the right pages. For a blog, it might be for them to pick a name, theme, and write the first post so they get invested. Isolating the minimum onboarding process lets you keep the initial steps high-conversion, yet set up their experience for success.

When a product is still early, when you’re searching for and building game-changing features, the resources those features eat through can be massive. The risk that your company takes in building them might be too high, and your team might overestimate the  probability that a feature will meet your expected growth goals for it. There is always a chance that the next feature will bend the curve, but it requires being smart, shrewd, and informed. Good luck.