Preface Of The Book Look And Flow

For many years now we have watched software product managers do their work and noticed a trend.  Product managers visit customers, talk to them, use a word processing software to take down notes very carefully, and then use a very elaborate requirements document to convey the desired product to user experience designers, and developers. This requirement document captures the desired product intention in great, but hardly accurate, detail. This requirements document, for no particular reason, becomes a contract between product managers and the development team. Depending on the level of trust between the product manager and the development team, sometimes it works. Most of the time it does not. In any case, the real problems faced by customers take a back seat in this contentious relationship between product managers and development teams.

With the advent of cloud computing and mobile apps, the pace and nature of software development has been altered significantly. Software developers, even the ones that develop business software, now focus on building simple products that can be developed in months rather than build products that take years to build.

Most organizations have recognized the trends and realized that the approach of elaborate requirements document does not work. They have adopted agile development models, where a group of people produce software in short development cycles, each cycle typically lasting a couple of weeks. This approach works. The smart ones have realized that building something quickly, showing it to customers and validating the value the product or service brings for customers is a good way to build software.

With this agile approach, product managers, who are used to long detailed requirements documents become less valuable if they do not develop the skill to produce a tangible artifact that they can use to validate their ideas with customers and convey their ideas to development teams. In short, they need to stop being slaves of presentation tools such as Microsoft PowerPoint and start building something.

We have also watched and worked with several user experience designers. They have a different kind of problem. They start with their favourite tools for visual design or user experience design. They use tools such as Adobe Photoshop to create stunning visuals of a few screens. They then create flow charts to come up with the flow. These documents are then passed on to the development team. It takes months before they can see the working product, which in most cases, is not very close to what was envisioned. The reason is the stunning visuals do not take into consideration the real purpose of the product. The flow charts created in a flow charting tools do not convey the user experience effectively to the development team. So the real design decisions are taken in a hurry by a development team member who just wants to make the product work.

There is something wrong with the above scenarios. If product managers build simple prototypes to tell the product story to users, validate the idea and then pass on the prototypes to the design and development teams, they can build a much better product that actually solves problems for customers. In this book we will tell you how to convert your ideas into tangible artifacts such as storyboards and prototypes, using which you can tell you product story effectively.

This book is for product managers and product designers who build software products for people. The product development approach discussed in this book may not be suitable for software that does not require people interaction.