AN EXPERIMENT IS A PRODUCT

In the Lean Startup model, an experiment is more than just a theoretical inquiry; it is also a first product. If this or any other experiment is successful, it allows the manager to get started with his or her campaign: enlisting early adopters, adding employees to each further experiment or iteration, and eventually starting to build a product. By the time that product is ready to be distributed widely, it will already have established customers. It will have solved real problems and offer detailed specifications for what needs to be built.

Unlike a traditional strategic planning or market research process, this specification will be rooted in feedback on what is working today rather than in anticipation of what might work tomorrow.

To see this in action, consider an example from Kodak. Kodak’s history is bound up with cameras and film, but today it also operates a substantial online business called Kodak Gallery. Mark Cook is Kodak Gallery’s vice president of products, and he is working to change Kodak Gallery’s culture of development to embrace experimentation.

Mark explained, “Traditionally, the product manager says, ‘I just want this.’ In response, the engineer says, ‘I’m going to build it.’ Instead, I try to push my team to first answer four questions:

1.Do consumers recognize that they have the problem you are trying to solve?

2.If there was a solution, would they buy it?

3.Would they buy it from us?

4.Can we build a solution for that problem?”

The common tendency of product development is to skip straight to the fourth question and build a solution before confirming that customers have the problem. For example, Kodak Gallery offered wedding cards with gilded text and graphics on its site. Those designs were popular with customers who were getting married, and so the team redesigned the cards to be used at other special occasions, such as for holidays. The market research and design process indicated that customers would like the new cards, and that finding justified the significant effort that went into creating them.

 

Days before the launch, the team realized the cards were too difficult to understand from their depiction on the website; people couldn’t see how beautiful they were. They were also hard to produce. Cook realized that they had done the work backward. He explained, “Until we could figure out how to sell and make the product, it wasn’t worth spending any engineering time on.”

Learning from that experience, Cook took a different approach when he led his team through the development of a new set of features for a product that makes it easier to share photos taken at an event. They believed that an online “event album” would provide a way for people who attended a wedding, a conference, or another gathering to share photos with other attendees. Unlike other online photo sharing services, Kodak Gallery’s event album would have strong privacy controls, assuring that the photos would be shared only with people who attended the same event.

The Kodak Gallery team built a simple prototype of the event album. It lacked many features—so many, in fact, that the team was reluctant to show it to customers. However, even at that early stage, allowing customers to use the prototype helped the team refute their hypotheses. First, creating an album was not as easy as the team had predicted; none of the early customers were able to create one. Further, customers complained that the early product version lacked essential features.

Those negative results demoralized the team. The usability problems frustrated them, as did customer complains about missing features, many of which matched the original road map. Cook explained that even though the product was missing features, the project was not a failure. The initial product—flaws and all—confirmed that users did have the desire to create event albums, which was extremely valuable information. Where customers complained about missing features, this suggested that the team was on the right track. The team now had early evidence that those features were in fact important. What about features that were on the road map but that customers didn’t complain about? Maybe those features weren’t as important as they initially seemed.

Through a beta launch the team continued to learn and iterate. While the early users were enthusiastic and the numbers were promising, the team made a major discovery. Through the use of online surveying tool KISSinsights, the team learned that many customers wanted to be able to arrange the order of pictures before they would invite others to contribute. Knowing they weren’t ready to launch, Cook held off his division’s general manager by explaining how iterating and experimenting before beginning the marketing campaign would yield far better results. In a world where marketing launch dates were often set months in advance, waiting until the team had really solved the problem was a break from the past.

This process represented a dramatic change for Kodak Gallery; employees were used to being measured on their progress at completing tasks. As Cook says, “Success is not delivering a feature; success is learning how to solve the customer’s problem.”

Source The Lean Startup

Highlight news

Latest news

Page / 37