I’ve been re-reading The Lean Startup on my commute into work. One key concept that it teaches is the “build, measure, learn” feedback loop; to get a product in front of customers quickly, gather feedback, learn from it, iterate and potentially pivot the project in another direction if needed.
“Build, Measure, Learn”
- Eric Ries, The Lean Startup
I’ve been working on a project recently where this approach failed at almost every stage of that process and with pretty catastrophic results.
The product was an immersive, interactive experience, targeted for modern browsers, a range of mobile devices and legacy browsers back to IE6. The customer, in the short term, was the agency’s client, who will have to remain nameless.
The project was complex and the first iteration of it was undertaken by a remote team who put together a PHP backend and front-end app using Backbone.js. This was delivered to the agency after 5 weeks of effort as a completed product that met the spec. However, this product appeared to have never been tested on any mobile devices. It simply didn’t run on any of them.
The project managers, pivoted the development and hired a team of two contractors - one flash developer (for legacy browser support) and one front-end developer (for mobile and modern browsers) - for the next attempt…
Version 2 used Angular as the framework for the HTML5 version, Node to serve the app, RequireJS to load dependencies, Grunt for linting and watching files, Zepto as a jQuery replacement (despite the fact Angular is bundled with jqLite), Raphael for drawing and animating SVG and Stylus for CSS pre-processing. I’ll be ignoring the details of this over-complicated setup here, but it might make a good topic for a future blog post…
Progress was slow and fraught with complexity. Video was a large component of the experience and building a video preview component that worked smoothly on iOS appeared to be a major sticking point for development.
After a week, I was bought on to the project as an additional resource to help with building out the UI, which so far had been abandoned in favour of fixing the video issues. Meanwhile, the Flash build progressed without too many difficulties and was taking shape nicely.
To cut a long story, 2 weeks later (after 8 weeks of total effort on two versions) the HTML5 version was still suffering from less than smooth video playback while the Flash version was being polished and made ready for release. The Flash worked and looked great - not something I thought I’d ever hear myself saying…!
At this stage, the Flash version was sent over to the client for approval.
Unfortunately, the client wasn’t that impressed but their feedback centered around a specific feature - the video preview functionality. The Flash guy was able to implement their feedback quickly, making a proof of concept that could be signed off in a matter of hours. The HTML5 lead was still busy trying to debug a version that would never be approved.
The reason for this rambling story is to illustrate one key point: it’s far better to show a rough outline and gather feedback than try to polish something that may not be what the customer wants. If this version 2 had focused on quickly producing an MVP to put in front of the client, lots of time and effort could perhaps have been saved, instead of building things that would never see the light of day.
I’d take this sentiment further and say that the most important thing when building a new project is to get a rough working version of the key user journey as fast as possible. There’s nothing to gain from spending weeks building a very specific widget or component if that thing turns out to be something the client later decides they don’t like - especially if they can only decide they don’t like it when they’ve seen it (or an approximation of it) first.
Building websites and web apps is difficult and I’m convinced no-one has come up with a bullet-proof approach yet. However, given the chance, I’d always aim to have something functional (even if basic) to show at each stage of the process, rather than ending up with something almost finished but not shippable when time and money run out.
We learn from our mistakes. Failing in web development is how we learn what works and what doesn’t. This makes failing a positive thing. It’s a shame that failure is often considered bad. However, in order to benefit from failure and implement what’s been learned, we have to fail fast so theres’ still time left to implement the newly acquired knowledge.
If you hate email but still want to keep in touch, follow me on Twitter.