Work Bytemark Cloud

How backups came to Bytemark Cloud

Designing, building and launching a backup feature for a cloud hosting product, while I was its product manager and led the product team, in 2016 and 2017.

First published on the previous version of this site; lightly edited.

A glass wall covered in sticky notes from the design sprint

Why backups

From regular customer interviews, the product team found that backups were both a consistent pain point and somewhere our cloud hosting product fell short. Customers without backups, or unsure whether they really had the backups they’d need in a crisis, were anxious about it. Some had found peace of mind with their own scripts, at the cost of upkeep and storage.

“I always have that bit of doubt whether the backup is actually running.”

Helping customers feel secure was too good an opportunity to miss.

A five-day design sprint

Early research told us a good backup service would be a real challenge for the company. To meet it, we brought people from across the organisation together for a five-day Google Ventures design sprint.

The sprint’s whiteboard map, from the long-term goal down to the customer journeys for backing up and restoring — Day one: the long-term goal, “easy to implement and well-functioning backups and restores for everyone, by default”, and the map beneath it.

On day one we set the long-term goal, chose a narrow target of existing cloud customers, and picked two tasks to prototype: setting up backups, and restoring from one. By day four, after a run of group design exercises, we were ready to prototype and test.

Testing a prototype

We built the prototype in a day, inside the existing product, in HTML, CSS and JavaScript. We took shortcuts, and it still tested our coding and our nerve. Looking back I’d swap that for a prototyping tool, but putting the prototype inside a product the testers already knew did help them find their way.

The one-day prototype, as the testers saw it.

Building a beta

From the usability research I sketched an interface that could be configured for complicated backup schedules, but kept the basic service simple enough that every customer could use it with almost no effort.

“It’s time-critical, so finding it in the panel is easier. It’s point and click.”

Paper sketches of the backup schedule settings — Sketches for scheduling

The first backup panel in the prototype, with one schedule and a backup-now button — The prototype’s backup panel

The beta backup panel, with several schedules, their costs, and a list of manual backups to restore — The beta, with schedules and costs

A click-test heatmap over the restore screen’s search and browse options — A click test on restoring a file

A terminal session listing a server’s backups and mounting one to restore files — Restoring from the command line

Easy backups for everyone, by default

It was a challenging project for Bytemark’s engineering team, and for me as a new product manager. We had to compromise on what we could deliver before it had proved its revenue.

I’m proud of the pricing I worked out: fair to the customers who used it heavily, fair to the company’s investment, and with a free service included. By default, for every customer.