Whole product for projects
Crossing the Chasm (Moore 2014)
introduces the concept of the “Whole product metaphor,” which I adapted for talking to engineers about various ways to view the scope of a project.
In short, a project can be understood to have multiple layers. When an engineer says a project is or will be “done,” it is really helpful to clarify what version of the project they’re talking about.
- The innermost layer is the “technical project.” This layer involves all work to make the project do the things it says it is going to do, i.e. writing the code that achieves the goals of the project without breaking existing functionality.
- Outside that layer is the “deployed project.” This layer involves any additional work necessary to make the project robust, e.g. integration testing, performance testing, capacity planning, CI/CD, monitoring + alerting, and actually safely deploying the code to production.
- The next layer is the “expected project.” This layer involves any work necessary for someone to be successful using the tool, e.g. documentation, security, training + operational playbooks for supporting teams, and usability features.
- The final layer is the “whole project.” This layer involves all the work necessary to ensure that users actually gain value from the project. This work includes onboarding users, measuring the usage + value provided by the project, integrating the project with other related parts of user workflows, and publicizing the project with users and stakeholders.
See also:
Moore, Geoffery. 2014. Crossing the Chasm: Marketing and Selling Disruptive Products to Mainstream Customers. 3rd ed. Harper Collins.