A balance of trust and quality

Projects are risky. Specifications are nearly impossible to define on most projects due to technical or communication gaps. This is the age old challenge many people fight.

One popular solution for unclear specs is the fail fast methodology. It's founded on brief iterations that lack polish, frequent tests by a client and an over abundance of communication.

This strategy is common for rapid prototyping and is effective for clients that can get their hands on something visually.

All too often we fall into the trap of quality. Quality, to me, is only a metric of a final deliverable. It should not, however, be a staunch requirement of an iterative build. There should be some baseline acceptance criteria for getting client feedback on a prototype, like removing glaring error messages or distracting usability issues like spelling or conventions. Keep in mind, you need to crank things out quickly. Something has to be sacrificed, and the client should be fully aware of this. Quality is optional. It's only mandatory when you launch.

Your client needs to trust that even if things are not perfect, you are progressively working towards their goal and helping them succeed. On the surface, trust and quality may not seem directly related, but much progress can be made with a lack if quality if the trust exists with a client. Keep in mind, if the progress is not demonstrated, that trust can erode. This is a balance with a fine line people should not cross.

Press on fearlessly and keep the lines of communication open. Most people will be thrilled too see progress even if it lacks the polish you know needs to exist for a final product launch.