Dropbox’s Waseem Daher on Iteration over “Perfection”

A few weeks ago, Apptimize hosted an event in SF: Fast Data Driven Growth on Native Mobile. Speakers from Dropbox, Lyft, and Yahoo! Growth shared the different strategies these industry leaders have been employing to stay ahead of the pack. This week, we’re sharing the key learnings from Waseem Daher’s talk.

The Dropbox team was really excited. After conducting a bunch of user tests and getting a whole bunch of feedback, they knew what they wanted to build next in their app: the activity stream. Lots of their users had mentioned that the app should implement a feature that made it easier to access items on mobile. They started working, but that’s when things started to go slightly awry.

After creating detailed specifications, mockups, and prototypes for the activity stream, the proudly shared their work with the team…only to find that nobody liked it. What happened?

The problem was scope creep. Figuring out what users are asking for isn’t enough. “You have to figure out what problems you’re not solving,” says Daher.

Daher said that everyone involved had different ideas of what the activity stream was supposed to do. Some thought it would be a social stream that showed what friend and co-workers were using. Others thought it would be a recent items list so users could easily find recently opened items. They tried to build too much at once, rather than using an MVP.

“Smart people really like to over complicate the problem because you can see four steps ahead, so its very tempting to say like, ‘Oh let me go build that final version.’ But when you do that…you don’t get something that actually increases your users’ metrics.”

This isn’t uncommon. Every day, teams build features based on innocuous or unconscious assumptions. Even when we conduct user testing or get similar feedback, it’s still not accurate enough. According to Gartner Research Group, “mobile users have a hard time articulating what a mobile app should do.” If users can’t even describe clearly what they want, how on earth are we supposed to understand and build those products?

It’s All About MVPs and Validation

Daher says it’s all about making simple, “dumb” changes and testing them. Instead of building a huge fleshed-out feature, Daher suggests making a small, simple MVP, then deploying it to a small group of users to see how they respond. Dropbox uses internally built A/B testing tools to ship the MVP to a small percentage of actual users to learn how it affects user behavior. After they’ve validated whether or not users respond positively, the team uses the feedback and data gained from the tests to intelligently iterate from there.

This methodology allows Dropbox to move quickly and build products that are validated by real user data. Taking the guess work out of it helps them avoid investing large amounts of time and engineering resources in something they’re not sure will connect. Building like this ensures that they’ll have steady growth, and an app that consistently gets better at meeting user needs.

Engineering Constraints

“The thing that makes doing the dumb thing hard is also an engineering constraint.”

One important caveat is that teams have to support it with their infrastructure, by decreasing their release cycle. Originally, Dropbox had been shipping on a 6 week cadence. While a 6 week cadence seems pretty commonplace, it’s a surprisingly big problem when you’re trying to build an amazing app. If a change somehow doesn’t make it into a release, it could end up taking 12 or even 18 weeks until a feature is actually updated. When you’re moving quickly and building on your MVPs, those weeks are one of the biggest hindrances to building a great product.

“One of the things to keep your scope simple is to just tighten up the release cycle.”

Daher says that the team made it a priority to reorganize, which enabled them to transition into a 3 week release cadence on iOS. It helped the team feel more at ease about doing simple changes because it allowed them to test it out, see the baseline, then intelligently iterate from there. Tightening the release cycle has been instrumental in Dropbox’s strategy.

Author’s note: One way we’ve seen companies move faster is to decrease risk by using tools like feature flags.

Wrapping It All Up

Daher and his team, like many other top apps, use this formula to ensure they’re always improving to stay at the top of their game. Using it allows them to avoid making assumptions and make smart, data-driven decisions to create better products for their customers.

Stay tuned for next week where we’ll share strategies from Lyft’s David Dryjanski about shortening your team’s release cycles. To stay up to date about our next event, subscribe to our newsletter at the bottom of this page.