October 30 2021
MVP and Iteration: How We Built a Web Application for Backup Analytics
Retrospect is a small company, so when we build new products or features, our goal is to find the intersection between what customers need and what our team can build, deliver, sell, and support.
In 2017, feedback from customers and partners frequently touched on how difficult it was to monitor and manage multiple instances of Retrospect Backup. Retrospect Backup is software that is installed on Windows and Macs, either servers or desktops, so administrators needed to log into each computer and look at the status in the application or configure email reporting for each instance. The process was painful and manual.
The Retrospect team talked about different solutions to this, including third-party monitoring service integration, better email reporting, or a web UI for each instance. Eventually, we agreed that the best long-term solution would be our own hosted service.
With a hosted service, customers and partners could log into a single web application and see an aggregated view of their entire backup infrastructure or, in the case of partners, all of their clients’ backup infrastructures through a single pane of glass. That one-sentence product pitch was the goal for Retrospect Management Console, focused initially on monitoring and analytics and eventually on management.
MVP: Minimum Viable Product
Building a minimum viable product or MVP represents a compromise between Sales, Engineering, and Product Management. Sales is looking at competitors and wanting to ship the equivalent solution as soon as possible. Engineering is trying to architect and deploy a well-designed product. Product Management is representing the customer and how this product will address their pain points. Finding a balance between these competing views comes down to a well-defined product roadmap that satisfies all three perspectives and begins with the MVP.
The value of the MVP is shipping and feedback. Shipping an MVP means the Engineering team has built a foundation for the product with a small set of features along with a packaging and deployment process. Feedback means you have customers–internally and externally–who are interested enough to give you feedback to help you iterate toward a better future product.
In our case, we wanted to ship the MVP for a hosted service that a customer could sign into and see an aggregated view from multiple Retrospect Backup instances. That translated into the following requirements:
- Hosted Service Platform: Heroku
- Database: Postgres
- Application Framework: Ruby-on-Rails
- Authentication: Devise
- Security: SSL encryption
- Data Processing: SuckerPunch
- Integration: Retrospect Backup connection and JSON data
- Dashboard: Aggregated view of multiple instances
The actual customer use case is the final point because the others represent the foundation of the product. We couldn’t get data into the service without them. The product requirement for the dashboard was a set of useful statistics and charts, and we could build more after shipping and getting feedback.
For comparison, we added the following features in future releases after the MVP:
- Scalable Data Processing: Sidekiq
- Detailed Instance Monitoring: Backup Report, Sources List, Scripts List, Backup Sets List, Scripts List
- Interactivity: Pause/Stop Support for Activities and Script Creation
We started building in May 2018 and shipped the MVP in August 2018. After testing it in-house for a month, we released it to the public as a beta. It required the latest version of Retrospect Backup to connect and send analytics data.
MVP Tradeoffs
When you’re building an MVP, you also need to acknowledge the tradeoffs. The problem with shipping an MVP is those early decisions build the foundation for the product, and as teams continue to build features on top of them, they also find it harder to justify the time commitment of changing them.
For us, we wanted to ship as soon as possible, which meant utilizing our existing knowledge of Ruby-on-Rails. We could have built the service as a Node.js application with React or Angular, but we weren’t as familiar with that approach. However, switching to a different application framework now would be a significant project because of the features we would need to replicate.
Moreover, we chose to have the API endpoint for the integration be served by the user-facing application. That design choice simplified the architecture in the beginning. We only needed one web instance running to both ingest data from Retrospect Backup and also serve the dashboard. However, as the service scaled, we needed to address that bottleneck.
MVPs are a fantastic approach to getting a product into customers’ hands and iterating based on their feedback, but your team needs to acknowledge the Engineering tradeoffs that come with that approach.
Feedback and Iteration
With the MVP shipped, we revisited the product roadmap. Sales wanted more management abilities to compete with other services. Product Management pushed for easier workflows for customers to use the service. Support pointed out issues that customers had. Engineering evaluated performance optimizations for scaling the service.
We’ve added a number of features since the MVP shipped, including the following:
- Navigation: Better navigation for organizations with managed organizations and multiple Retrospect Backup instances
- Detailed Monitoring: More insight into Retrospect Backup instances via Backup Report, Sources list, Scripts list, Backup Sets list, Scripts list
- Interactivity: Pause/Stop support for activities, shared scripts, and backup set/script creation
- Status: Detailed status for each Retrospect Backup instance’s service connectivity
- Scalable Data Processing: Sidekiq and Rails AutoScale
Web applications are particularly suited to MVPs and iteration based on feedback because the company controls the delivery. We only update Retrospect Backup every six months because customers have repeatedly told us they don’t want updates more frequently. However, with a web application, we can update the application far more frequently, and the customer is only aware if there are new features.
For Retrospect Management Console, we’re on deployment #396, so on average, we’ve shipped 2.5 times per week since Fall 2018.
Deeper Product Integration
Owning a hosted service allowed us to integrate and streamline the user experience for Retrospect Backup. In May 2021, we launched Retrospect Backup 18 with deeper integration with Retrospect Management Console.
When you download a trial of Retrospect Backup, the download link points to Retrospect Management Console. The service automatically creates an account for the embedded email address and license and then creates a personalized version of the application installer with license and Retrospect Management Console UUID included. After installation, Retrospect Backup automatically creates a public/private keypair and uploads it to the service, so that the service can bundle it in each client installer for that Retrospect instance.
In Retrospect Backup, the customer can copy a single download link for the Retrospect Backup Client agent installer and send it their entire company. When each employee downloads and installs it, their computer will be automatically added to the Retrospect Backup instance and start getting protected, without any administrative setup.
By leveraging Retrospect Management Console, the Engineering team was able to streamline the entire end-to-end process of trial download to automatic protection for an entire organization, requiring only a couple clicks from the administrator.
Building an MVP and then iterating based on feedback enabled the Retrospect Engineering team to ship an integrated backup service that helps companies easily onboard, protect, and manage their backup environment from a single pane of glass.
