Why mock-ups are so gigantically important
The ability to show people exactly what you mean is an invaluable tool, not just for Product Owners and Product Managers but for anyone. Communication, verbal or written, is an exercise in faith that the other party has enough shared experiences with you that the way you choose to describe something will sync up with how they might describe it. This becomes a problem particularly for Product Owners and Product Managers because a large swath of their job is comprised of communicating intangible, soon to be tangible, things to people who have never seen them before. And to make matters worse, the penalty for failure is increased costs, blown schedules, and unhappy stakeholders.
Mock-ups take intangible ideas and make them a tangible reality, with considerably less effort than development. They allow us to clarify our misunderstandings quickly before serious resources have been committed. This is incredibly helpful because stakeholders and developers suffer from the same problem that most of us do, we have trouble envisioning the final product from abstract requirements. It is hard to read written requirements and visualize how they will impact a process flow or interface.
To compound the problem, people generally are not able to retain written content as effectively as other types of content. The NTL Institute posits that, on average only 10% of read content is retained, while visual and demonstrative content are 20% and 30% retained, respectively. This suggests that mock-ups, being both visual and demonstrative, not only communicate their message more effectively than written requirements, they facilitate the retention of their message to a greater degree.
Without mock-ups, it becomes incredibly hard for stakeholders to be sure that they have realized all requirements that will be relevant to them in a finished product. Missed requirements will then emerge in User Testing after development (usually the next time that the stakeholders see the project). Changes at this stage require revisions to code and additional QA.
This would not be a bad thing, if changing something after it was developed was as easy as changing it in a mock-up. Unfortunately, it isn’t. The well known Cost of Change model for Agile development, shown below, extrapolates that changes requested in Testing are close to 50 times more expensive to implement than changes requested in Requirements Gathering, and changes requested in Production are close to 150 times more expensive. There is a great advantage to avoiding this and being able to change quickly with low effort and low cost.
With mock-ups you can rapidly iterate through ideas with stakeholders, allowing them to participate in the solutioning process. You can identify any misunderstanding that arise from ineffective communication and make corrections quickly. The result of Requirements Gathering becomes an almost perfect facsimile of what will meet the stakeholders needs, making previously intangible ideas tangible. Combine this with requirements structured using the Product Requirements Hierarchy and development can take both and turn them into a reality without fear of further revisions being requested after their work is complete. All in all, the use of mock-ups in Product Teams leads to a more efficient use of development resources, decreased costs, and delivery of exactly what stakeholders need.
Sources
The Learning Pyramid
by Education Corner
Why Agile Software Development Techniques Work: Improved Feedback
by Scott W. Ambler
