MVP In Four Weeks

On a recent project, my client set the ambitious goal of launching their MVP (minimum viable product) with just four weeks of development time. The entire project was budgeted for just two months, and we needed to launch midway so that we could gather data and user feedback, then iterate on those learnings. (At the time of this writing, the site is live but the client is still under the radar using a temporary brand name, so unfortunately I can’t disclose their identity just yet. But we’ll post an addendum when they launch to the public!)

IMG_3105-sm

Requirements

  • Responsive, mobile-first design
  • Streaming video
  • Shopping cart with credit card payments over SSL
  • Embedded discussion forums
  • Analytics
  • Account creation and login via Facebook
  • A/B testing for pricing
  • Transactional emails
  • Helpdesk chat
  • Content management system

An additional challenge was that the team included just one developer and one designer. How would we meet our goal?

Agile

The cornerstone of our success, of course, was the XP-flavored Agile process we use here. We started by getting the entire team in a room (developer, designer, and the product owner) and defining a few personas representing the types of users we were designing for. Then we built out experience maps that illustrated how those users might use the product. By comparing the experience maps, we could see what features we would need to provide to that set of users to fulfill their needs.

We broke the required features up into bite-sized user stories with clear acceptance criteria, ruthlessly prioritized and re-prioritized those stories, built features using test-driven development, and frequently deployed working code to our acceptance server to tighten the feedback loop with the product owner.

IMG_3107-sm

Bootstrapping

We used the Raygun Rails application generator as the starting point. Raygun outputs the skeleton of an app which implements many of the best practices we tend to follow here, saving us the time of installing those same gems, configuration files, and hierarchies each time we start a project. Raygun also uses the Bootstrap CSS framework, which gives us the responsive behavior we needed out of the box, and providing a foundation for our custom design.

Services

We made heavy use of web services to maximize velocity and save us the up-front cost of building features from scratch; we couldn’t afford to waste any time re-inventing the wheel. We ended up integrating the following services into the MVP:

Heroku for hosting our Rails application (for both production and acceptance environments), PostgreSQL database, and SSL certificate. Heroku is our tried-and-true choice for devops-friendly hosting and dead-simple scaling.

Brightcove for streaming video. We needed the ability to scale our video CDN on demand, a customizable and embeddable player, an interface for admins to upload new content, and an API for gathering realtime usage data, such as saving each user’s progress as they watch videos. Brightcove provides all of this and was very easy to set up.

Stripe for credit card payments. Stripe’s reputation as a developer-friendly payment gateway is well deserved. We had no desire to handle sensitive card data on the server side (and the PCI compliance nightmare that entails). Stripe’s lovely client-side JavaScript API sends the card data to Stripe’s servers and returns a one-time token, which is posted to your backend via a hidden field in your payment form. Then a simple server-side API call using their Ruby gem converts that token into a captured payment. It all takes only a few lines of code.

Facebook OAuth for user account creation and authentication. While it limited our initial user base to Facebook users, it was incredibly easy to use the OmniAuth gem to implement a user model in our system without worrying about the details of confirmation emails, password management, etc. We knew we could add other authentication options in a future iteration.

Facebook embedded comments. A simple JavaScript snippet with our Facebook app ID and a unique page identifier was all it took to get a basic discussion forum on each product page. Not a lot of bells and whistles here, but it got the job done for our launch.

Intercom for embedded, synchronous and asynchronous customer messaging. The intercom-rails Ruby gem made integration of a “contact us” dialog just a few lines of code.

Optimizely for A/B testing. While best suited to testing out visual variations aimed at increasing conversion, we were able to use their API to trigger different behavior in our backend as well, allowing us to test a few different price points for our product.

Kiss Metrics for client-side and-server event tracking. We wanted to gather metrics on how each user was interacting with our product, e.g., which UI elements were they using, and what events were those actions triggering on the server side for those specific users? Kiss Metrics’ custom event tracking API made it easy to gather and analyze this data.

Amazon S3 for image and document uploads. Our CMS needed to offer our admin users the ability to upload new image content for products, as well as related downloadable documents. The Paperclip gem combined with S3 for storage fit the bill perfectly.

Sendgrid for transactional and marketing emails. They’ll handle the details of whitelabeling your domain so your emails don’t go to spam, if you don’t mind mucking about with your DNS records a tiny bit.

New Relic RPM for application performance monitoring. This wasn’t technically a part of the client’s requirements, but their free tier product is dead simple to integrate and provides valuable performance data during that critical launch period.

A Little Help From Our Friends

OK, I stretched the truth a bit when I said there was just one developer and one designer. One of the nice things about being at Carbon Five is that I was able to pull in a couple of other developers for a day or two at a time when I needed the additional firepower, such as when I received a brand new mockup from the designer. These pairing blitzes helped a lot.

Epilogue

The MVP launch was a success, and the initial traffic we received via Facebook and Google ads gave us the data we needed to know we were on the right track. After launch, we took the time to add the additional features we wanted, such as non-Facebook user accounts and custom threaded discussion forums, and continued to gather data and user feedback. Although the project has already transitioned to the client’s own team, the next step will be to launch to the general public under the actual brand name. Even then, the rapid development cycle will continue!

Have you had an experience (good or bad) with one of the technologies we used? We’d love to hear about it in the comments!

This entry was posted in Design, Mobile, Process, Web. Bookmark the permalink.
  • JonahWilliams

    We sometimes take this for granted but this, like all of our projects, was built by a team working 40 hours per week. Rapid development does not mean crunch mode and overtime.