Harvard’s new Innovation Lab has been hosting a lot of great events this fall, and one of them was a talk given by Eric Ries, author of The Lean Startup. To me, the thesis of his talk was that in order to run a lean startup, you need to test your ideas early and often. He told a story about working as the Chief Technology Officer of IMVU, a software company that was making an avatar-based instant messaging system. They had spent a year developing the technology, fixing bugs, and getting it perfect, but when it came to launch, they had a major problem. In order to sign up for the software, customers would need to click on a pop-up screen within their normal instant messaging window that said something to the effect of, “click to download a new avatar service.” But when it went live, no one downloaded it! After a year of burning the midnight oil to get the product up and running, it all came down to a single pop-up box that couldn’t get the job done. Eric’s point was that they probably could have saved themselves a year of trouble, and learned that customers were not interested in avatar-based instant messaging by testing that pop-up box on day 1.
For his audience of Harvard Business School students and start-up folks, he made the case for testing early as (“How can we figure out what we’re trying to learn with minimum effort?”) and described a feedback loop of Build – Measure – Learn. To me, this struck me as similar to the Express, Test Cycle that I was taught in Product Design classes. There, the point was: express your idea (either by actually building it, or explaining it through a storyboard, video, or demo), test it with your audience, get their feedback, and get back to work.
While it was an effective way to perfect a product or service concept, I came to understand that the Express, Test Cycle only worked if your idea was good in the first place. In other words, with the Express, Test Cycle you could still get pretty far down the rabbit hole of changing form factors or button colors before a consumer might admit to you that actually, they didn’t need/want this product at all.
When I worked at Jump, we commonly talked about the design process as a (not always linear) cycle between four stages.
First, observe how customers live, and find out what issues keep them up at night. For example, for a food client*, you might study busy parents and see how they deal with feeding their kids and negotiating healthy choices vs. convenience. Then, analyze your data to uncover insights about the customers. Maybe parents told you about secret rituals they used to manage food prep, or maybe they were really concerned about how their snacks appeared to others over how it made them feel. Next, translate these insights into directions – if food rituals are really important, what could our food company do strategically to better meet them? Should they shift from making only food products to making products that support these rituals? Finally, come up with actual solutions that the company could use. What would those products actually be – maybe a specialized kitchen tool, an iPhone app that celebrates the ritual, or a system for setting up space in your home to perform that ritual?
Now, as you might imagine, this process of observing, analyzing, and creating a strategy and ideas takes time – we would usually take 4-6 months to do a project like this – and most startups feel they do not have that kind of time to spare. But even a startup can find one busy parent to talk to before they get caught up in design details. Overall, while I’m hopeful that the success of Eric Ries’ book will help startups and entrepreneurs gain empathy for their consumers earlier in their building process, I worry that getting empathy at that stage is often too little, too late. As I interact more with the startup scene in Boston and the Innovation Lab, I’m hoping to convince them that they can truly differentiate their ideas with customer research that happens before the coding even begins.
*The example I use to explain the cycle is created based on typical Jump projects, but contains no confidential information.