Three steps to deliver the best product experience

Building good products is hard. Building products and features to delight users at scale consistently is even harder. At Dropbox, our focus is on simple, beautiful product experiences. We want to bring joy to our users and make it easier for them to do their best work.

Can a product process guide us to deliver these results? At Dropbox we’ve been asking ourselves this question for a long time. The answer was a process to build products, features and even other processes by answering three questions:

• Why?
• How?
• What?

Answering these three questions in order has been one of the main ways we use to build product at Dropbox. We first identify meaningful opportunities, then explore solutions, and with that build products to delight our users.

The value of this three-phased process goes beyond building software products. As author and speaker, Simon Sinek described in his TED talk, the world’s most innovative companies and leaders also use a similar three-step process. There is a common bottomline: Start with the why, then the how and only after that, get to the what.

Why?

Why does this matter? Why should we do it now?

At Dropbox, we start the product development process with the why because we consider it the most important step. Starting with the why involves asking why a problem is important and why it should be tackled now. Explicitly doing this upfront allows us to work on problems that matter. At the why phase, we seek to answer questions like:

• Who are the users?
• Which problems are they facing?
• What are the problems for Dropbox?
• Why does this matter now?
• What is the opportunity space?

At this stage we focus on framing the problem and almost as a rule don’t include any aspects of the solution. Answering the above questions can involve other efforts such as synthesizing user research and competitive analysis. The primary goal of this stage is to come up with a set of hypotheses around the opportunity identified and markers of success. Within Dropbox, we call this the Phase 0 of the project.

Over the years, we’ve noticed that starting with the why has many benefits:

• Alignment: Once the above questions are answered, we typically hold a review across various stakeholders associated with the project. While defining the why for a Dropbox-Gmail integration, we were able to articulate the set of hypotheses for success and the set of metrics to validate each hypothesis. The review then served to align leadership and stakeholders on what success would look like and develop a shared sense of the problem.
• Deeper understanding of the user: At Dropbox, we start with the why for developing our internal-facing products as well. On our internal experimentation platform, answering the why was a forcing function to understand different user personas and articulate individual workflows. This revealed more entrenched pain-points than what we knew going in.
• Focus when there is complexity: While answering the why for revamping a product at Dropbox, we found that the existing state of the world was very fragmented. Answering the why led us to focusing on the power users and addressing the issues in specific areas first. This simplified project complexity.

At the same time there are some caveats:

• Moving fast: Not everything we do at Dropbox requires a Phase 0 with a rigid review process. Being flexible allows us to be nimble and move fast when necessary. Small obvious features and quick experiments that test hypotheses don’t need as much rigor as a large new product.
• Setting scope and the right level of abstraction: The benefit of asking why is that it abstracts the specific feature/product away and focuses on the problems we’re looking to address. But the why has to be at the level of abstraction that sets a scope on the problems we’re looking to address. Without that scope there is a risk of attempting to solve an unbounded problem.

How?

Getting to a specific solution starting from a specific problem

The natural next step after asking the why is to investigate the how of addressing those opportunities. In the how phase we go from having clarity on the problem space to knowing the specific approaches to address that problem space. Before beginning this phase, it’s important that we’ve exited the previous phase with clear alignment. This avoids spending time and energy chasing the wrong problems.

There could be more than one way of addressing the problems (but not always). These different solution approaches often represent trade-offs. In the how phase, we explore different ways to address the problem and weigh each of them. For one of our product efforts to build a platform solution for the growth team, we considered three approaches: building in-house, leveraging an open-source solution, and buying a solution off the shelf.

Sometimes it’s not about evaluating a set of options, but figuring out the sequencing of the solution. Figuring out which set of problems to solve first flows from the priorities identified from the user problems. In the how phase, we want to work toward creating a hazy picture of what the final implemented solution is going to look like. At Dropbox, we refer to how phase as the Phase 1 of the project. Aspects of this phase include:

• Exploration of different approaches to address problems identified
• The best possible way to solve the problems with the rationale for that decision
• A low-fidelity solution with an early sizing on effort
• Sequencing of the solution and milestones
• Early thoughts on validation and learning plans
• Associated risks and mitigations

In the how phase we go through a process of divergent thinking to explore the possible space of solutions for the prioritized problems and follow it up with convergent thinking to arrive at the specific solution to address those problems. In some ways, this sequence of divergent-convergent thinking is similar to the double diamond model that’s commonly used for structuring the creative process, including designing products.

What?

Getting to high-fidelity solutions

Building on the first two steps, we arrive at the third step: the what. By the time we get here, we have enough validation and alignment on the problems we’re solving and their importance. There are no big questions on the value of the problem itself or the general approach.

In this phase, we look to move from a high-level solution approach to a specific solution that captures the detail. We write what is referred to as the product requirements. We build design specifications and discuss the details of the technical implementation for the product solution.

The aim of this phase is to reduce the risk and unknowns associated with the project. We also build the confidence and clarity needed by engineering and other teams to proceed to implementation. Aspects of this phase include:

• A clear set of use-cases that are in scope
• A feature set that is a part of addressing the opportunity
• Product specifications for both general and edge cases
• High-fidelity mocks that show what this solution should look like and work in detail (copy, images etc.)
• Metrics, analytics, and logging
• Cross-team dependencies
• Launch and go-to-market plans with clear timelines

At Dropbox, the what stage is often developed iteratively by working with different teams and only sometimes reviewed with leadership.

Going beyond products

Processes, programs, and more.

The three step process of why? how? and what? extends beyond product development at Dropbox. This approach has also been adopted to build out new processes and programs as well.

• New-Grad Product Manager program: We applied the process outlined above to build a new program to hire PMs straight out of school. The why explored the rationale and our opportunity to hire smart fresh graduates for the PM team. With the next phase, we explored different aspects of the program: Manager/mentor structures, project rotations, onboarding, and more.
• Data quality and integrity processes: Similarly, we started with the why to kick off an org-wide effort to improve data quality. For the how, we investigated different org structures, roles to be hired, and RACI models for key processes. Reviews at different levels of leadership allowed us to align on a Dropbox-wide solution.

One size doesn’t fit all

Change and scale the process to fit the need at hand

As you think about the three questions for a project, it’s important to avoid forcing the same process each time. The depth of analysis and rigor, the timelines, and the review cycles should match the complexity and risk associated with the project. Here are some of the ways in which we’ve looked to balance speed with rigor:

• The level of leadership involved varies depending on the risk and scope. Large projects need the highest level of approval at each step; smaller projects only need group level approval
• Combine answering the why and the how into a single phase for smaller projects. For even smaller and faster moving projects, this can be a simple one-pager
• Reviews, especially for the what phase, are not held if they directly derive from the how phase

As the product team has grown, individual teams have modified the three-phased process to their own mandates and needs. Some teams have an explicit prototyping phase to learn fast before shipping at scale. Growth teams have explicit steps around analysis and decision making for experiments.

In the end though, the three-phased process of why? how? what? or modifications to it intend to serve one purpose: To help Dropbox achieve its mission and help our users achieve theirs.