Mockups are the new spec

Last week I had the pleasure of chatting with Matt Miller and Jeff Perkins, co-founders of OfferTap, an exciting new company that is creating a platform that helps online merchants better target buyers and optimize e-commerce revenue.

I met Matt and Jeff several months ago at a conference on distributed development and global outsourcing. What struck me was that they had been very successful at creating their entire product with an outsourced team by never writing specs. They share our view at Macadamian - that a visual design is a far better spec than a written spec could ever be.

I caught up with Matt and Jeff to find out more about how they made it work with an outsourced team developing a new product in another country.

How did you come to the conclusion that a visual design was a better way to describe the product to your development team than a written spec?

Jeff: Actually, when we first started, we had put a lot of work into creating a spec and spelling out detailed business requirements. We found that despite that, we were spending a lot of time going back and forth to explain the requirements.
Matt: Our partner was impressed with the level of detail we had put together, but we spent a ton of time educating them about how the product would visually fit in with other e-commerce solutions, tie in with existing ads, and explaining overall how it would work.
Jeff: It came from the frustration of not getting to the end result fast enough. Every hour spent writing spec was an hour we were further away, and worse, it didn't seem to matter because it wasn't helping the development team. What our specs were missing was both the big picture and the user flow.

I understand you use hi-fidelity mockups, as opposed to wireframes. Tell me more about that and why you choose to put a lot of detail in your mockups.

Jeff: For us, a wireframe wasn't going to do, because we were also using the mockups to describe what we were doing to investors and customers. A wireframe wouldn't give us the same level of impact. Plus, the designs were going straight to the development team. When you have a design team, wireframes work fine, but in our case we were the designers, and it was just as easy for us to create more detailed designs.

What if you're not a designer by trade? How do you communicate ideas to your team if you don't have the skills to do hi-fi mockups?

Matt: There are a number of tools you can use to get your idea across. When we were experimenting and fleshing out ideas, we used tools like Snag-It to cut ideas from other products, and used PowerPoint to arrange them. The end result was good enough for experimenting on the placement of elements, and showing the flow of the product.

How much time do you think you saved in development by using mockups in place of specs?
Matt: It was significant. Once we started showing the team mockups, they understood exactly what we were doing. Especially in the beginning - it probably saved us a couple of months of spec writing and back-and-forth. At the front-end of the project, it even helped our outsourcing partner understand who they would put on the project.
Jeff: We probably cut the lifecycle in half. When you're outsourcing development, I don't think it's language barriers that are a problem, it's understanding what the product is supposed to do, and the vision for the product - especially when the product is new and breaking new ground.
Matt: Words can be interpreted so many different ways. The clarity was almost instantaneous when we switched to doing mockups. After a month of back and forth, they had a big AHA moment. It also let us switch from a Waterfall approach to Scrum, which we used for the remainder of the development.

What did you write down?
Jeff: We did write down a series of high-level business requirements, some background on the product strategy, and a list of features. That gave everyone the high-level view of what we were trying to accomplish.

Did working with an Agile process like Scrum not make it hard to get quotes from prospective outsourcing partners?

Jeff: A fixed-price contract doesn't guarantee that your partner will deliver what you want.
Matt: That's exactly what happened - we started down the path of describing everything, and we ended up spending so much time trying to cross the T's and dot the I's that we never got around to building it.
Jeff: The opportunity will pass you by working that way.
Matt: We actually found that doing a few mockups made it easier to find the right partner. We could tell by the questions they were asking, who they involved in the process, and how detailed their plan was whether they were grasping the product from the get-go.

How would you sum up what you learned for other product companies?
Matt: Build it first - get as close to building a prototype as you can. We built mockups to describe the features - that gives you a clear vision of what you're doing and helps you describe it to others. Don't spend time creating artifacts no-one will use.
Jeff: Adopt an agile methodology that lets you iterate fast, and solicit feedback early and often. A waterfall approach can lead you to analysis paralysis and keep you from innovating.

Incremental innovation in 2009

I've been thinking a lot about what we can expect in 2009 in new product innovations. Chances are we'll see mostly incremental innovation and very few breakthrough innovations, at least from established product companies.

People, and companies, are risk averse in a down economy. Few are ready to place a big bet on a product they aren't sure is going to generate immediate revenue. Incremental innovations, like small product improvements, should yield incremental revenue from existing customers. Apple, the company most people look to as one of the world's best innovators, released a series of incremental innovations this year at MacWorld - no breakthroughs for the Mac faithful this year.

Despite a lack of disruptive innovation, I'm hopeful that 2009 is a breakthrough year for design-thinking, driven by product companies wanting to reduce the risk of creating the wrong product or wrong innovation. I'm predicting that more product teams will invest in user research and prototyping, so that they can be more sure that they are focusing on creating the products and features that will provide the most value to their customers, and hence provide the biggest return.