Thoughts and Lessons from Rails Rumble 2010

I met Nick Plante working at Relevance and discovered that he was one of the people who organized the Rails Rumble. I asked him about it and expressed my interests in participating. It was too late to get in on a team, but he invited me to be a judge.

I was asked to review 20 apps in about 72 hours, judging each by 4 categories: Appearance, Completeness, Innovativeness & Usefulness. I took this all very seriously, and I created a template to give detailed feedback in all areas. (I know I would have loved to get feedback that way if I had entered.) There were many things that raised my brow throughout my review of the suggested apps. Without a doubt, there were some amazing wins. But, there were also several common fails for many of the apps I reviewed.

First and foremost, let me start by recognizing that these apps were all made in just 48 hours by a team of no more than four people. That's a serious feat! All of the apps had some serious sweat poured into them and just participating in the Rumble is a win, as there is much to learn from accepting such tight constraints. And under these constraints, it was clear that most teams fell apart around the same thing -- Minimal Viable Product (MVP).

A very unusable pen with lots of gadgetry and features... and the text that reads: 'When all you needed was a pen'

Minimal Viable Product

A Minimal Viable Product, in this case, would be the most simple and achievable feature set used to demonstrate a solution to users with limited time (i.e., the judges) with a goal of getting feedback on its value. Almost every great virtual product starts out small and introduces enhancements to test the value of new features, while all the while its core remains usable and intact.

The applications that I noticed most positively were those that had a clear understanding of MVP. They served a specific purpose. They were polished in appearance. And the minimal feature set was functionally complete. When certain features were not implemented, these apps clearly indicated that these features were "coming soon"; they were thoughtfully and tastefully integrated in appropriate locations throughout the app. These features were also enhancements not blatant omissions. The teams who got this right created products/tools that demonstrated solutions. They did so with clean interfaces that told the user what to do when and where. And it was clear that the tool was working by the feedback provided to the user post-interaction via validation and messaging. Even upon first laying eyes on these apps, they informed the user as to why they were there and what they should expect from their experience. They had clear calls-to-action that guided me to where I needed to be at each stage of my interaction with the app. Kudos to all who put such thought and work into your app so I didn't have to figure out how to use it!

The applications that I noticed most critically were those that completely missed the MVP boat. These apps may have had great functionality on the inside, but signing up was complicated. Or broken. Or upon landing, there was no clear explanation as to what problem the app was trying to solve. Other apps got the landing right, but then fell apart on the inside due to excess features which resulted in poor organization, poor flow, or general incompleteness. Some apps failed to guide the user through their experience; they lacked clear labeling and messaging. These apps seemed to lack focus and/or balance.

Questions that could be helpful in a Rumble

How do we apply this learning to future Rumble events? Asking the following questions could give you a head start on the competition.

For MVP:

  • What is the problem that I am solving? How can I solve it in the most simple and focused way?
  • Can we solve the overall problem one feature at a time?
  • Are there future (post-Rumble) features that I want to preview to the users? Can I provide those previews without compromising the core functionality of the app, or would these enhancements just be a distraction?
  • Is what I am working on essential to the current release of this product?

For Usability:

  • Have I clearly stated what the user should be doing at every stage — from landing, to signup, to sign in, to using the tool, to logging out?
  • Do I have validations, confirmations, and essential messaging in place?
  • Have I labeled forms and form elements clearly?
  • Are there any broken links?
  • Have I made it easy for users to recover from mistakes they might make when entering data?

Rails Rumble apps I reviewed that "wowed me"

Of the apps that were assigned to me for judging, these entries were the shining stars. (Note: they are not the list of top apps for the Rumble. For that list, you should check out the complete scores and all of the amazing stuff that came out of this 48 hour whirlwind of productivity.)


All in all, it was really great to be a part of the Rumble. I enjoyed looking over all the applications, and I was even more amazed and humbled to get thanks from teams for my thorough reviews and honest feedback. I would do it again in a heartbeat, but I definitely hope to join a team and participate in the thrill of the competition next year. I look forward to Rails Rumble 2011 and hopefully your feedback!