4 Design document
This chapter covers
- Defining antigoals as part of the filtering process
- Drafting a design document based on the information available
- Reviewing a design document
- The evolution of design docs
Once you have defined the problem your system should solve, as well as a list of stakeholders, and already have a rough understanding of what technologies and solutions would be most appropriate for the product, as described in Chapter 3, it is time to prepare a design document.
It is worth noting here that there is no set-in-stone order of actions at the early stage of creating an ML system. You can start preparing a design document as soon as you’ve identified the problem and goals (especially if you work in a startup, where the speed of delivery is times more important than following processes). But since this book is presented as a checklist, the list of actions is also displayed in a traditional sequence.
As one of the authors’ manager once said, no fancy recommendation algorithm could beat a customer with a shopping list. These people have a goal and a plan for achieving it. Nothing can stop them.
If you are an engineer and need to build a machine, you need to start with a blueprint. Other engineers will review it and provide feedback, which will probably lead to another iteration of blueprints, and another one and another one, until your design is finally ready to be brought to life.