Minimum Viable Product = Measure Once, Cut Many Times

Developing with RoR + AWS provides incredible agility - making it possible to quickly develop products that people can react to. This combines well with “minimum viable product” theory -- an approach which is rapidly moving from web 2.0 startups to many companies across the spectrum.

From Wikipedia:

A Minimum Viable Product has just those features (and no more) that allows the product to be deployed. The product is typically deployed to a subset of possible customers, such as early adopters that are thought to be more forgiving, more likely to give feedback, and able to grasp a product vision from an early prototype or marketing information. It is a strategy targeted at avoiding building products that customers do not want, that seeks to maximize the information learned about the customer per dollar spent. "The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort."

The idea is not that different than the long-time approach of developing a prototype except that now the prototype becomes a production version. It may not be released widely but it’s not necessarily built to be disposable. The prototype is expressly created to test market reaction. Prototypes in the past were developed primarily to assess the technical challenges or to create a version for internal reaction only.

In this MVP process, requirements and user interface design are still important (and essential). The difference is that it’s no longer the case of working with internal team members using long documents and multi-week processes. Development now gets front-loaded more quickly into the process -- which for architects and developers is a great thing given how eager they are to roll up their sleeves.

Getting to a minimal viable product means that you have to be practical and determined in taking the vision, focusing in on a market and specific use cases, reducing what’s possible to the essential features and flows. Approaches for distilling requirements are similar to approaches for time-management. There are many often opposing ways to organize to-do lists but that’s because they map to the different ways people work.

One back-of-the-napkin approach to reducing requirements is to take a data model view and prioritize and group the entities that you’ll be tracking. You’ll find they are probably 3-4 major data elements with others nesting around these. By mapping the flows and actions between these elements you should have the primary value of the application. Add in straightforward navigation, minimal visualization and design and you’ll have a rough outline of the first agile cycle. The other data elements will accommodate additional features and capabilities and take care of edge cases. But you’ll want to get to these only if and when you find out they’re in demand.


Ruby’s object support and GEM structure makes it easy to build and extend. Rails provides a great framework for structuring applications. AWS enforces a loosely coupled but solid approach to system architecture. This means you can create and adapt applications quickly.

Which means you can measure once and then you can start developing. And then based on market data from real use, you can develop again. Without protracted periods of measurement market research and requirement cycles. The application becomes the plan.

MVP + RoR + AWS couldn't make for a better combination. (Unless of course, there was a monkey.) **


** Great commercial and back story on the monkey. We recommend.