16 September 2015 — We reflect on the experience of an early-stage mobile startup and its struggles in the “trough of sorrow”. During this phase, many teams make the classic mistake of adding the “next feature” in hopes to spark traction for the entire product. Instead, mobile startups should consider a “zoom-in” pivot, where a single feature becomes the whole product
In this article, we reflect on the experience of an early-stage mobile startup and its struggles in the “trough of sorrow”. This term was coined by Paul Graham, cofounder of Y-Combinator, to describe a challenging phase where companies typically struggle to find product-market fit. During this phase, many teams make the classic mistake of adding the “next feature” (and then the next and next) in hopes to spark traction for the entire product. Instead, mobile startups can consider a “zoom-in” pivot, where a single feature becomes the whole product. The most challenging part of this pivot is actually making the decision to execute it. To help facilitate this decision, we introduce three steps that can be taken already in the prelaunch phase. These can help technology companies to achieve better success in the launch, and to be better prepared to avoid feature creep also in later stages.
Most mobile app startups get stuck in the trough of sorrow
When the founder of a startup shuts down their business, it has become customary to write a “post-mortem” blog post to the startup community about what went wrong. CB Insights, a venture capital database, parsed through 101 of these notes and stated that the number-one reason for failure, cited by 42% of polled startups, was the lack of a real market need for their product.1
Achieving “product-market” fit is both difficult and extreme. Startups typically start with a launch, get press coverage and enjoy a brief period where people are interested in them. Shortly after, the novelty wears off and momentum slows down. When teams iterate their products and user traction is still weak, thoughts of failure creep into the team. This phase, nicknamed the “trough of sorrow” by Paul Graham is a seemingly never-ending phase where teams are pushed to iterate their products in hopes of achieving user traction (see Figure 1).2 Founders often make a critical mistake during this phase to simply add more “features” to their product – leading to a resource sink and using up the majority of their seed funding.
Figure 1: Paul Graham’s startup curve
One mobile app startup in Seoul (nicknamed Cre8 in this article to ensure privacy) faced a similar fate in the trough of sorrow. They launched a networking platform for artists and creative professionals and initially received positive reviews from local tech media. User signups were strong in the initial month but user retention indicated a deep problem. Data showed a steep drop-off of users one day after installation (D-1). The drop-off continued into D-7 and D-30. With retention rates this low, it was difficult to see how the active user base would grow to levels promised to its seed investors.
In efforts to limit churn and bend the D-1 retention rate, Cre8 team turned to its users for ideas on how to improve the product. The team got out of the office and conducted interviews with a handful of early heavy-users in the service as well as a focus group with graphic designers. One shared pain point among both groups was the lack of centralized information on creative jobs and freelance opportunities in Korea. After careful deliberation, the team internalized user feedback and developed an in-app feature that allowed peer-to-peer recruiting. The new feature was released with the second major update of the app, one year after launch. However, the feature had no impact on the D-1 retention rate. It remained exactly the same. The process was repeated again and the next version of the app included a marketplace feature that allowed users to buy-and-sell portfolio pieces as stock images. Likewise, this feature also failed to spark traction and within a year, the founder emailed a post-mortem reflection note.
Building the next feature won’t save your product
Building the “next feature” did not solve the retention problem for the Cre8 team. Was it a lack of great ideas, or a lack of bright minds? Andrew Chen, a SF-based tech writer, explains that teams too often fall into the trap of adding features to products which are broken at their core. He coins this as the “next feature fallacy” – a mentality among early-stage startups to add additional features in hopes that it will suddenly make people use their product.3
But why will the “next feature” typically fail to spark usage for the whole product? Andrew suggests two primary reasons: first, features are often developed for active users rather than the first-time user (or casual user). They are deeply embedded into the product and not included as part of the onboarding process for first-time users. If we compare the number of Cre8 users in the onboarding vs. D-3 phase, it is easy to see why embedded features do not impact the overall retention rate. It is only seen and experienced by a minority of active users. Second, too little impact is made when users do engage with the new feature – especially when the new feature is displayed as an optional action.3
Cre8’s P2P-recruiting feature was built with the right intentions – to deliver more value to the user. However, the feature was not experienced by the majority of the user base. Data from CrazyEgg, an analytics program which visualizes user clicks through a heat map, revealed the total number of clicks in the P2P recruiting sections to constitute only 5% of all clicks in the app. In hindsight, the team realized that a key reason for low usage was that the feature could only be experienced if the user had “friended” others in the network – an action which was not typically done by first-time users.
Zoom-in to spark traction
If Cre8 had made the P2P feature more accessible to first-time users, would this have shifted the needle on the overall retention rate? Probably not. However, if the new feature attracted a majority of the usage over other features within the app, it offers a strong hypothesis on how to re-shift the core offering of the product. When teams select a single feature of a product to become the whole product, we call this a “zoom-in pivot”.
A prime example of a “zoom-in pivot” is Instagram. Instagram started as Burbn, an app that let users check in at particular locations, make plans for future check-ins, earn points for hanging out with friends, and post pictures of the meet-ups. The product (shown in Figure 3) was a jumble of features that made it confusing to use. The user traction was slow and the CEO hired a programmer to analyze in-app data on how existing users were using Burbn. The data revealed that people were not actually using the core feature of “checking-in” at all. Instead, users were using the app’s photo-sharing features. At this point, the team decided to scrap all other features in Burbn and focused solely on simple-photo sharing.
Figure 3: Screenshot of Burbn4
Testing a “zoom in” pivot can be done by setting the default in-app navigation and the description of the product to the feature we are zooming into. The following tactics could be used to test in high-traffic zones of your app:3
• Changing the landing page where new/unregistered user arrive
• Taking users directly to the functionality after they sign-in or sign-up
• Using UI to channel users into the zoomed in feature
• Integrating the feature into the onboarding process
We would expect that the usage of the zoomed-in feature rises significantly, while the secondary features in the app go to zero. If this test is successful, picking the zoomed in feature should be easy. However, if the data shows that other vital metrics (for example, time spent on app, frequency of content sharing) for the app go down, we may continue iterating on the zoomed-in feature until it works. 3
Plan the pivot in the prelaunch
The decision for a “zoom-in” pivot (or any other pivot) is difficult and most companies fail to make it. Eric Ries, author of “Lean Startup” lists three primary causes for delays in the pivot decision: (1) the use of vanity metrics rather than hypotheses which support learning; (2) when the founder(s) have an unclear hypothesis and are unable to generate the learning required to know when to change and (3) fear that the startup will fail without a chance to prove itself.5 The decision on whether to pivot can be made easier by benchmarking user retention rates, tracking user behavior, and preparing the team on how to deal with feelings of failure.
The team should identify and benchmark relevant user retention metrics. The DAU/MAU, a ratio of Daily Active Users to Monthly Active Users, is a good measure for how “sticky” a product is. (A DAU/MAU ratio of 50% would mean that the average user of your app is using it 15 out of 30 days that month). As this ratio increases, it indicates that users are becoming more engaged with the product. The +3 day retention rate could also be tracked to gauge if users find real value in the product (this metric could be +1week or +1 month retention rate depending on the expected usage cycle of an average user). In the prelaunch stage, teams should benchmark the DAU, MAU and +X day retention metrics from competitors or other apps in their category. Note that competitor data may be hard to come by, so it may require looking at comps in a similar or equal product category.
In the prelaunch, teams should set up and customize mobile analytics tracking into their app in order to collect data and help validate hypotheses of the product. In the analytics platform, teams must enable “screen” and “event” tracking in order to see which content users are viewing the most and which buttons (features) they are clicking on. By placing event tags on all call-to-action buttons in the app, teams can see whether users are using the app as founders had originally intended for use.
A pivot will also demand emotional intelligence. During the prelaunch phase, founders should coach the team about the expected emotional highs and lows of the startup life cycle – with particular focus on the trough of sorrow. When the product fails to be a hit and user traction continues to be low, team members will feel that they have uniquely failed. Cofounders will fight with each other, key employees will leave and morale will be low. However, it should be explained that the trough of sorrow is unavoidable – Facebook, Twitter, Instagram, Yelp have all pivoted in their early phase to hit product-market fit and are continuing to pivot other areas of their business as they scale their business. While quitting or starting over with a new product may be an appealing thought, it doesn’t solve the product-market fit issue and teams will again face the same trough with a new product. Founders can reinforce their belief in the team’s ability to work through this process and more importantly support team members in generating and testing hypotheses.
Even after a startup reaches initial success, it must continue to pivot and test the scalability of different components of its business model. As such, pivots are a permanent fact of life for any growing business. Founders should plan early for their first pivot and coach their team in generating strategic hypothesis as well as dealing with emotions. With pivot planning, early stage startups can minimize their time in the trough of sorrow by becoming resilient in the face of mistakes and developing the agility to find another path.
1 Cbinsights.com,. ‘Venture Capital Database – CB Insights’. N.p., 2015. Web. 26 Aug. 2015.
2 Graham, Paul. ‘Paul Graham’. Paulgraham.com. N.p., 2015. Web. 26 Aug. 2015.
3 Chen, Andrew. ‘Essays On Tech, Growth, And Startups’. andrewchen. N.p., 2015. Web. 26 Aug. 2015.
4 http://blog.kissmetrics.com. N.p., 2015. Web. 26 Aug. 2015.
5 Ries, Eric. The Lean Startup. New York: Crown Business, 2011. Print.