Why Bottle Rocket Apps Has Gone (Back To) “Lean”

Upon our launch in 2008, Bottle Rocket Apps pioneered a “low-fi to high-fi” approach to developing apps. We started with an app mission statement and explored various user experience concepts through pencil sketches. We then designed and built the app based on those sketches and constant discussions with the client as the app evolved.

As we grew beyond just a handful of people, and added Rocketeers who specialized in app strategy, user experience design, quality assurance, and other areas, we adopted a more formal approach. We would devote a considerable amount of time up front to establishing a defined scope for the project, developing in-depth requirements, and creating a detailed, written specification for the app. All this happened—usually over numerous revisions—before we ever placed a pixel in Photoshop or wrote a line of code. This spec became the bible for the entire project and only after the client approved it in its entirety would work begin. And even then, much time was spent constantly trying to keep the spec updated throughout the implementation and testing of the project.

After a while, we began to realize that this rigid “waterfall” process was beginning to buckle under its own weight. For starters, it was incredibly wasteful. We wasted valuable time in the sales process, trying to pre-define a project scope, when our talented strategists had not yet engaged with our client. Then we wasted more time and effort—both the clients and our own—in the design phase, trying to think through and solve every possible problem on paper. The spec began to get in its own way—instead of focusing on shipping an app, we were concentrating on an interim deliverables that really had very little value to anyone.

Then there was a second, less obvious problem. We always emphasized user-centered design, but no actual users ever saw the app until it was released to the market. Instead, we built the app based on our client’s and our own unconfirmed assumptions. Fortunately, we are quite good at what we do, and our clients generally know their users fairly well, so major misses were rare. However, when fundamental failures in the solution (like unneeded or missing features, or usability problems) did occur, they were much more costly to correct late in the development cycle, or when the app had already been released.

So earlier this year, we decided to return to our roots, in a sense, by adopting a new and simpler approach. This approach was informed by the teachings of Lean Manufacturing, Lean Startup, Lean UX, Agile software development, and our own years of experience in the industry. We did away with our waterfall process—and in fact, with any type of standard process at all—and chose instead to approach each project from a set of core principles.

Those principles include:

  • Eliminate waste: use short cycle iterations (typically a week long) and frequent informal testing with real users to ensure we are building apps they want, and avoid spending time creating interim deliverables unless they produce obvious value for our client or our users.
  • Achieve quality through iteration: build the core experience of the app first, and then expand and polish the feature set from there, based on internal and external user feedback.
  • Work as a team: literally breaking down the silos between our disciplines, each of our project teams now works together cross-functionally in a collaborative workspace. The team owns and solves all project problems together, and each member of the team is accountable to the others for their work.
  • Collaborate with our client: we talk with our clients at least two to three times a week (or sometimes multiple times a day), sharing and seeking feedback and critique on designs and strategies that don’t yet feel finished. Our clients enjoy more visibility into our work, and we benefit by avoiding going down the wrong path for too long.
  • Build a shared understanding: working together and communicating proactively between specialists on a team creates a common understanding of the users’ needs and how the app will meet them, reducing the need for formal documentation.
  • Embrace change: by definition, this means that there is agreement that the real scope of the project isn’t knowable when we start it. By accepting this fact, we allow for the learnings and changes in priorities to occur naturally during the evolution of an app ultimately mold the final product.

As I said, Lean is a philosophy, not a process. Each team works hard to understand the particular needs of their client and their users, and then applies these principles to an approach that best fits the need of their particular project. Moving away from a rigid process has allowed us to complete deep, complex apps faster, on time and on budget, and with even higher quality than ever before.