I’ve currently working on Facebook’s NPE team building new products and we’ve launched a few of them publicly (eg, Tuned). Before Facebook, I built 0 to 1 products at Dropbox (eg, Dropbox Transfer) as well as building from scratch as the CEO of a start-up. I wanted to share some thoughts on 0 to 1 product development within established companies based on these experiences. Note: I am defining 0 to 1 products here as building totally from scratch, not adding new features to an existing product with a large active user base.
First, a few principles when building 0 to 1 products
(1) Trying to solve too many problems with your initial product is a recipe for not solving any problem well. New products should focus on being the best solution for a single problem/JTBD for a well-defined target customer.
- Customer and problem focus helps to clarify your GTM approach.
- Once you’ve nailed that initial job for your target customer, the product can expand to additional jobs and customers (eg, Facebook going from college -> high school -> everyone and from profile -> photos -> newsfeed).
(2) The team has to be passionate about solving the core user problem. There will be ups and downs in the journey to find product-market fit and, eventually, scale. A lack of intrinsic motivation will inevitably doom a team (see PG’s #18).
(3) Solutions to user problems should:
- Solve the articulated user problem as well as the underlying problem (ie, make sure you understand what the actual user problem is!)
- Be technically feasible, meaning shouldn’t create unnecessary technical complexity and can be completed in a reasonable timeframe with a reasonable number of engineers. For example, with Tuned we spent five months with 3.5 engineers (one joined the team halfway through the project), one designer and one PM to get to our first public release.
- Not introduce unnecessary product complexity. You want to continue to ensure an intuitive experience, even as you introduce more advanced features.
(4) A metrics-based iterative approach to software gets the best results. In particular, being rigorous about tracking the right metrics that ladder up to the user value you’re aiming to create. At Facebook, we have metrics for everything. And while for mature products, that can be a blessing, for new products it can be the kiss of death. Rather than considering a potpourri of metrics, 0 to 1 products should pick a clear hero metric (or two). In addition, it’s critical to:
- Set clear success metrics up front that track to driving user value
- Quantitatively test and validate (or disprove) underlying assumptions throughout the development process
- Seek constant feedback from target customers and be clear about our biases in interpreting that feedback (eg, confirmation bias)
- Continually re-evaluate metrics to make sure you’ve picked the right ones
Okay but how should one decide what opportunities to actually pursue?
Ideas for new products to solve customer pain points are everywhere. Figuring out where to allocate finite resources is challenging. Here is the framework I use to narrow down the plethora of options.
(1) Is this an opportunity to solve an acute user problem? Who is the first set of customers that would benefit from solving this problem? Your understanding of these customers should be tangible — who are they and how will you reach them?
(2) Are you in a position to solve this problem? Does the product solution build on top of your strengths? Is this a problem our target customers have on a regular basis (will users take advantage of our solution at least weekly if not daily)? If so, is the market large enough to be interesting to us?
- Note that some of the most innovative consumer products create new behaviors. As an alternative to this question, we also ask if we don’t know whether users will use it regularly, what other signals can we look to in order to build confidence? For example, while demand for 6 second looping videos or ephemeral photo sharing would have been hard to prove, trends like internet video becoming more ubiquitous or a backlash against public sharing were useful signals.
(3) Can you solve this problem in the next few years with the resources we have available?
(4) Can you win in the market given the competitive landscape?
(5) Is there a sustainable path to meaningful user growth and revenue?
Time to execute (remember, done is better than perfect)
Once you’ve defined your target customer problem you’re trying to solve and your success metrics, here’s a (non-exhaustive) approach to getting an initial product from an idea in your head to a working app on customers’ phones.
(1) Gather inputs
- Talk to customers -> current customers, churned customers, potential customers who use other solutions. Reading research prepared by someone else isn’t enough, the team needs to be in the weeds with customers.
- Competitors -> how are competitors solving this problem? What’s great about their solution? What is not so great?
- Market trends -> What are the market trends and what’s the key “insight” about where the market is heading?
- Team Brainstorm -> people across the company will have great ideas! Both because they use the product and because they talk to customers.
(2) Decide on ~3 solutions you’d want to test and write lightweight specs that articulate the solution and the associated cost to building (this process may rule out certain solutions based on the cost or the design or engineering complexity).
- Why multiple solutions? Research done at Stanford by Dan Schwartz found that prototyping multiple solutions in parallel led to better outcomes because teams weren’t attached to any particular solution.
(3) Build design prototypes for each and test with ~5 users. Why ~5 users? User research has found diminishing marginal returns after this number of population. Make sure that these users are part of your target customer set (as famously described in Sprint, by GV)
(4) Narrow to the best solution based on this feedback and update “winning” prototype -> test again with users.
(5) Write a detailed spec, incorporating product as well GTM. GTM is particularly important to define early on to allow for iteration cycles pre-launch.
(6) Build an engineering prototype, test with users at more scale (~1,000–10,000). Validate your assumptions with qual feedback from alpha users + quant metrics based on your success criteria outlined above.
(7) Incorporate feedback from eng prototype and build out beta and release to a limited test. Have clearly defined success metrics that will help you continue to build confidence along the way.
We’ve launched! Now what?
While each of my team’s products has specific target metrics laid out in a detailed learning plan, there are a few overarching signals I look for when deciding what we should continue to invest in post launch.
- Strong core action success as a proxy for users being able to use our apps in a way that would lead to value creation (eg, for a messaging app, did the user send and receive a message?). I have less well defined benchmarks here but would look for roughly double the retention goal below, so 30–40%+. Users coming into your product and completing the core action is a prerequisite to healthy retention.
- Healthy D28+ retention as a quantitative proxy for users getting value out of the app. Based on consumer app benchmarks, this is likely ~15–20%+. Targeting daily retention here because, ideally, we are building products that provide value daily. Note that in the early versions of a product strong core action success & healthy D14+ retention would justify continuing to invest and iterate.
- Qualitative feedback that shows users are passionate about the app. This feedback will come in both qual feedback (eg, longitudinal research like a diary study) and survey form (eg, Sean Ellis Score). Another effective method is building a community of early adopters around the product and centralizing their feedback in a FB Group or WhatsApp/Messenger thread.
- A clear path forward. Part of signing off on investing will require a clear plan with sound logic behind the resource ask and the go forward prioritization. Tactically that means (a) a clear roadmap with quant and qual insights backing the prioritization (b) specific staffing allocation and (c) feasible resourcing asks (eg, budget, headcount, support from other teams).
- Passion from the team about continuing to tackle the problem space with this particular instantiation.