A couple of weeks ago, we announced our plans to start an app on Monday and launch it on Friday. We’d like to share lessons we learned.
The Result
The production application went live at http://fashionopoly.com on Friday. It’s currently invite-only so there’s not much to see publicly. I recorded a screencast (it’s not a “talkie”) but I can’t show that, either. Ah, the suspense. Sorry!
Please accept these fashionable photos of Los Angeles Laker superstar Kobe Bryant instead:
You’ll recognize the features we completed, however: sign in with email & password, sign in with Facebook, beta invites, scoring system, commenting, post to your Facebook wall, like, flag, moderate, edit your profile, upload an image from your hard drive, upload an image from a URL, GET shopping results from the Amazon API, tagging, search by tag, filter by category, filter by location.
Tools
The obligatory set of tools we used includes:
- Heroku and S3 for deployment
- Clearance and Clearance Facebook for Facebook integration. Clearance Facebook is a private library we wrote for another project. It uses Facebooker under the hood. Like Clearance, it has a set of Cucumber features that mock out Facebook. If this project came a few weeks later, we would have used the new Facebook API but we felt it was safer to go with what we know.
- Cucumber, Webrat, RSpec, Shoulda matchers, Timecop, Webmock, Factory Bot, and Email Spec for testing
- Geokit and jQuery Auto-geocoder for location stuff.
- Searchlogic and jQuery for searching and filtering. I would like to write a separate article about this.
- Less CSS and Formtastic for DRYer, faster CSS and forms.
- Basecamp, Campfire, and a real-life whiteboard for communication. The client and half the thoughtbot team also shared our conference room.
- Pivotal Tracker for user stories.
Speed Lesson: Derivation
Look at that list of features. We’ve written each of those at least once before. Nothing was really from “scratch.” We could either use a gem or consult old code if we got stuck. It’s the first reason why we were able to finish so many in one week without compromising our values (everything was written test-first, outside-in with acceptance tests as the outer loop and unit tests as in the inner loop).
The result still feels unique to me, though. People smirk when you say you’re building a “social” anything but the paradigm works.
The derivation also makes the one week concept more reasonable. We’re working on other, longer projects where it wouldn’t make sense. It’s time consuming to learn the language of the construction or medical industries versus the language of a social site.
Speed Lesson: On-site customer
This is an XP rule. It’s something we’ve done with our other clients, but not consistently. I would highly recommend this for any consulting engagement for the simple reason:
The many small decisions that must get made… get made faster when the customer is on-site.
The cumulative gain is very noticeable. If your client balks at the idea, I like the quote from that XP rules page as a response:
This may seem like a lot of the customer’s time at first but we should remember that the customer’s time is spared initially by not requiring a detailed requirements specification and saved later by not delivering an uncooperative system.
Speed Lesson: Heroku
It goes without saying that Rails is a productivity enhancer.
The combination of user stories, TDD, continuous integration, spikes, and on-site customer was another clear productivity enhancer for us. Let’s call that a subset of “agile” or XP.
The third productivity enhancer was Heroku. Sendgrid, Delayed Job, Hoptoad, deploying to staging and production, thumbnailing images and storing on S3. All of that stuff is second nature on the platform. They’re solved problems that take minutes, not hours of configuration or tweaking.
I came across a presentation by Ian McFarland of Pivotal Labs this week called Agile, Rails, and the Cloud that makes the same argument and I couldn’t agree more.
Strategy Lesson: A Brand Guideline
When I showed my colleagues a draft of this post, they said, “I’d expect to hear stories about making tough decisions on prioritization.” This actually wasn’t an issue. There were user stories ready in Pivotal Tracker. We made a point to prioritize them first thing Monday morning. About halfway through the week, we wrote the major features on the board that we wanted to get done and just did it.
On the other side of the coin, the sloppiest part of the project was decision-making around design. There were six cooks in the kitchen: two designers on our side and four people on the client side.
We should have clarifyied the brand vision and target audience before we started. We didn’t draw the line, asking for adjectives describing the desired brand (“innovative”, “stylish”, “reliable”, etc.). We didn’t ask that the client accept or reject the designs on the basis of the brand vision or target audience instead of making requests for color, layout, or other design elements.
I think we all agree that design by committee results in a design that is the lowest common denominator. It also results in a lack of cohesiveness in the design. Worst of all, it’s slow.
We fought those forces as much as we could but there’s definitely room for improvement.
Strategy Lesson: A good product today
Paraphrasing Rousseau, who was part of the client team:
A good product today is better than a great product a month from now.
I love their strategy:
- Use an experienced team like thoughtbot
- Build a minimum viable product in a week
- Privately validate that customers want it
- After customer validation, open to the public to validate the business model
This is basically the Customer Development risk reduction methodology with the twist of white-hot energy focused for a week on product development preceding a longer period of private customer development.
The book “Four Steps to the Epiphany” is the Customer Development bible, but it’s ironically a slow read. Very dense. I’d recommend Ash Maruya’s “Customer Development Checklist for My Web Startup”, Part 1 and Part 2.
Other people frequently make the mistake of trying to get their startup going “cheaply” by hiring night-and-weekenders. The product development process inevitably drags on, and sometimes never launches. Either the founders lose motivation or have to spend more money to do it right. In the end, it’s not cheaper to make your customers wait for a web startup-style product.
As Rails developers, we all know about the power of constraints. The focusing power of the one week constraint is as real as other constraints. It’s also a ton of fun!
