Le Petit Prototype: From Little Questions to Big Ideas


by Riva Bakal, Emily Kramer, Namrata Patel

Eric Ries told us on the first day, “launch early and launch often.”  But, what can and should be done before launch? How do you think about Ries’ advice for an early-stage product (something that’s not even ready to launch)?  For our fledgling mobile application, the iterative approach really took hold in customer discovery interviews and usability tests.  We learned first hand the power of talking to users, customer-centric hypothesis testing, and “launching” with paper sketches and wireframes.  Users may not always know what they want and can’t tell you exactly what product to build; they can, however, share potential use cases and latent needs, ultimately describing exactly what the market looks like.

We started the semester with the plan to build a mobile application from scratch.  With lots of app ideas floating around, we whittled our way down to one: mobile safety.  The first version of Checkmat.es was born.  The application aimed to make students safer by keeping them in contact with friends or parents in the event of an emergency.  Aside from creating a product, the process taught us about applying lean techniques to startups in their nascence.

Having a Hunch
As classic founder-users, we brainstormed use cases initially based on our experiences as college students.  We certainly had a hunch as to how the app would work, but how could three HBS students who all attended college in Cambridge, MA – Harvard, MIT, and Tufts –really understand the safety needs of students in diffuse urban campuses or sprawling state universities?  Having a hunch is great for the beginning phases of development, but customer interviews kept us from assuming that everyone had the exact same needs as us, from falling victim to confirmation bias, and from building an app that served the needs of a small minority.  

Talking to Users Early
There is no good reason to wait for high fidelity prototypes.  Talk to users early.  There’s a temptation to “wow” users with an aesthetically pleasing, fully-baked prototype, but in reality, you can’t let users anchor to a prototype. Thinking creatively and expansively about the problem is paramount.  Wireframes were more than sufficient to coax such feedback from users and validate or challenge our hypotheses. In the early hand drawings, we sketched out the core interactions and use cases.  We transferred those onto an iPhone outline and created buttons and messages with the basic PowerPoint tools.  PowerPoint then gave us enough flexibility to make quick modifications to the wireframes, especially during the usability tests.  A high fidelity prototype doesn’t give you the flexibility you need to act quickly on what you hear.

User discovery interviews also revealed the importance of privacy to users.  We were surprised by users’ false concern that the app would track users’ location at all times or automatically push notifications to parents or campus security.  While we had designed the app from the beginning so a user can self-select an appropriate contact, we had underestimated how much this concern could prevent user adoption.  Users latch onto preconceived notions of how things have worked in the past or how they think they will work.  Though we reframed the interaction design to emphasize privacy and choice, these interviews helped us understand the real needs and preferences of our users, rather than just the features they need in our application.

Keeping it to the Minimum
We also learned that “minimum” is the key word in minimum viable product.  Jamming the app with additional ‘bells and whistles’ confuses users more than anything.  Clean design tugs at their intuition so that they can see how to navigate through the product on their own in order to capture its value.  We took the design advice that “in anything at all, perfection is finally attained not when there is no longer anything to add, but when there is no longer anything to take away” to heart[i].

Minimum also doesn’t mean cheap.  Development estimates for Checkmat.es ranged from $7.5 to $10k.  “Lean” necessitates bootstrapping and hustling to find resources.  If we had a do-over, we would apply for MVP funding.

So, What Does Lean Mean?
We were scrappy and process-oriented.  We tried everything that we could to push the product forward without throwing tons money at it.  All the techniques we deployed – user discovery interviews, usability tests, and a minimum viable product – were geared towards testing whether our product met the users’ market.  At each juncture we reflected on our initial hypotheses and revised our approach.  While luck may be another way to get there, customer-centric hypothesis testing is more of a sure-fire way of building something that people care about.



[i] Antoine de St. Exupery. Wind Sand and Stars. Trans. Lewis Galantiere. New York: Harcourt Inc