Minimum Viable Product (MVP) is something we talk a lot about with our clients at Atomic Object. MVP was coined by Frank Robinson in 2001. Eric Ries made the phrase popular through his book “Lean Startup.” Its commonly shared meaning is the version of a product with the least effort, allowing a product team to collect information about what customers use.
On many projects, we start our conversations by aligning on what MVP means relative to our project constraints. I like to start here because it helps the developers and me expedite the development process. Something else that helps expedite development is creating the minimum amount of project documentation at the right level of detail. Below I will share the project documentation that has served our current project team and me well.
Produce the minimum pertinent documentation.
I’ve been on one long-running project for the last few years at Atomic Object. During this time, we have planned for and released several MVP versions of big features. The timelines from discovery to delivery have been short, on average eight weeks long. With such tight delivery timelines, the team must choose carefully which documents we create. Otherwise, we rob from the time allocated to building the product to create project documentation.
Parkinson’s Law states that “work expands to fill the time available for its completion,” but time has often been an immovable constraint on my current project. Therefore, our team tries to maximize the time we schedule to get alignment on what we are building.
In her book “Continuous Discovery Habits,” Teresa Torres discusses the various artifacts created in a project’s lifecycle. She lays out three types of project documentation. There are artifacts to:
- Do the work
- Communicate the work to stakeholders
- Archive the work (document what happened)
Create Documentation that Serves Multiple Purposes
Torres recommends creating one artifact that serves all three purposes. Essentially, we follow that same advice. We use a Miro board to keep track of things. The essential documents we produce when faced with compressed timelines include the following.
Minimum Artifacts Needed to Do the Work
- Story map. This is our team’s go-to document for aligning the teams on what we will build. It is told from the perspective of the product and what it will take to deliver the user experience. This artifact is valuable because it depicts the smaller components of the feature we are trying to deliver.
- Wireframes or high-fidelity designs. This is the second most helpful type of artifact in an MVP situation after the story map. The time we allocate for the discovery phase dictates how closely designs resemble the final state. If the time is really short, then we will proceed to development with low-fidelity wireframes.
- Requirements document, otherwise known as Software Requirements Specification (SRS). At the very least, this document contains intended use cases and a definition of “done.”
Minimum Artifacts Needed to Communicate the Work
- Development release timeline. In this artifact, the team ties the component pieces from the story map to the dates they will be delivered.
- Scope change history. The purpose is to communicate the change requested, by whom, and when it occurred.
Minimum Artifacts Needed to Archive the Work
- Release notes. We post release notes in Slack. They include the date, a short description of the problem it addressed, and its corresponding Jira ticket number.
- Decision document. This is an overview of key decisions made in various team meetings, emails, and Slack. Here is where I catalog recordings of virtual meetings for reference.
When we have to rein in an already aggressive timeline, we have managed with just a story map and wireframes.
Final Thoughts
Our current client’s primary concern is speed to market. Therefore, we prioritize starting development work as soon as possible over producing comprehensive project artifacts. Creating a minimal amount of helpful documentation has become our best practice. If your project also has a short runway for preparing documentation, I hope the list above will expedite your development process.