”if a company is using Lean and Agile - then why would they need a prototyping tool like Fluid UI?” I was asked. The gathered crowd looked on. Had he ever built software I wondered? Did he know the Lean methodology well, or was he just looking for a question to appear wise while testing whether I deserved to be there at all. “Sure”, I stuttered. “Good question”.

Many of the things that were once considered important competitive advantages of big businesses are being undone with the advent of the Lean methodology. Traditional foci - such as the protection of IP and repeatable business processes - are seeing companies deliver too slowly in the face of faster moving startups using Lean Product Validation, Scrum and Agile.

Using the principles of Kaizen, companies are focusing relentlessly on improving their ability to get things done quickly with a minimum of waste and handovers.

Using Agile, they are focusing on getting working products into the hands of users as quickly as possible.

Using Scrum and small, cross disciplinary teams, they are eliminating the delays relating to communication issues that frequently cause projects to grind to a halt.

Within this spectrum though, the choice as to how to iterate - with throwaway prototypes, by starting directly in code or by using some other approach rarely get discussed. This uncertainty arose in the eyes of my questioner - the thought of developing a throwaway prototype itself was surely to be considered wasteful productivity, and should not be part of the lean/agile approach.

Is prototyping wasteful?

The core idea [of Lean] is to maximize customer value while minimizing waste. Simply, Lean means creating more value for customers with fewer resources. (http://www.lean.org/WhatsLean/)

A pure interpretation of Lean Production Validation could well conclude that any work that does not directly involve making the product for your users - including processes such as prototyping - are simply slowing down the end deliverables and creating waste. The kindly gentleman in the question above was almost definitely wondering whether this was the case. While potentially true - clearly there is also a more nuanced answer.

If the amount of time saved by creating a prototype fails to reduce the time needed to create valuable software, then the Lean requires that you don’t prototype. Of course - every piece of research about the cost and benefits of prototyping confirms that this is not the case. Why so? Let’s start with the two biggest inefficiencies in any product development process.

The two biggest causes of waste

The single biggest inefficiency in any product development effort is building a product no-one wants. If no-one is interested in your product, then 100% of your time is wasted in creating it, and 100% of your marketing spend for advertising it is also wasted. It’s the worst possible scenario. Market research and UX research exist to mitigate this risk. This whole validation process is a core part of the Lean methodology. Clearly, reducing risk is an entirely acceptable investment within the Lean framework (as it should be).

The second largest point of inefficiency in any product development effort lies at the crossovers and boundaries of the work the team is undertaking. Practitioners of Scrum regularly claim a 400% and more improvement in overall efficiency after adopting the approach. Their successes come from short, regular and structured bouts of communication combined with plenty of time to just get things done. Self reflection on the process being used is also a core part of the overall approach.

So why does prototyping still happen?

A picture is worth a thousand words. A prototype is worth a thousand pictures.

Software prototyping, as a process (prototyping is not a goal, nor is it a tool) helps at both the product validation and internal communication stages of product development.

It reduced the risk of building the wrong product (by allowing you communicate with users before you ever have working code) and

It allows you communicate better with your development team earlier in the process, improving internal communication and understanding of the product.

As we discussed previous about the impact of prototyping in the development process, it is an incredibly effective way of reducing the risk of the two biggest issues that companies face when creating new products.

Summary

Let’s hope that right now your company has already adopted or is trying to shift towards an Open Innovation and a Lean Product Validation type approach. If you are wondering what is involved, and you want to talk further about what is involved in adapting your approach, catch me on Twitter or Linked In. And don’t forget to sign up for Fluid UI to do your prototyping - we win when your products are delivered faster to market than any of your competitors :) Talk soon - Dave.