How early is too early to start your product documentation process?
When you’re a small team, it’s easy to let documentation slip. I mean, if three-person phone calls count as company-wide meetings, keeping everyone on the same page is simple, right? While you can, and should, keep your product documentation process light, making sure you have a few key processes in place is important.
Here's why:
Documentation allows you to prioritize development initiatives based on their alignment with your business goals and KPIs.
Documentation helps you more seamlessly onboard new technical hires who can use it to learn about past choices and build context.
Documentation lets you parallelize workstreams with consistency and accuracy as you scale your product functions.
So, if documentation is so helpful, what should you actually be documenting in your product builds when you are a small team? How can you make your documentation valuable rather than arbitrary lists of features and functions?
At Remedy, we’re strong proponents of having detailed, actionable, and standardized documentation. As an external technical partner that often partners with growing companies, we regularly help startups implement robust documentation standards, as part of an efficient agile process.
We recommend focusing on two key pieces of documentation — roadmaps and user stories — to stay intentional in the types of documentation you spend time on.
Roadmaps tie directly back to business themes, and user stories provide essential business context for onboarding and continuity; prioritizing them allows for your documentation process to stay light, while having company-wide impact.
Take a look at how Remedy utilizes and standardizes these two pieces of key documentation:
1. Roadmaps
A roadmap is a living document that outlines the tactical plan of your product strategy, breaking it down into manageable steps. A roadmap ties your product plans back to your company’s business goals and KPIs to help you prioritize initiatives.
Your roadmap is not just a list of features and functionalities. Rather, your roadmap is a north star about where you want to go — not about how you will get there.
At Remedy, we create roadmaps that look 3-6 months out, especially for early-stage companies. During these 3-6 months, you may change how you prioritize initiatives or define success as you learn more about your users. Your roadmap should be a living document where you welcome iterations based on discovery. We set a monthly roadmapping session where we add, update, and reprioritize.
There are a handful of helpful tools out there to assist with creating effective roadmaps. A few of our favorites include:
Google Sheets (nope, you don’t need anything fancy to create a roadmap! A simple and organized spreadsheet can also do the trick as long as your content is strong)
Here’s an example of an anonymized roadmap we created in Google sheets for a healthtech partner:
This roadmap may look a bit like a random colorized spreadsheet, so let’s break down a few of its key features:
Each theme is color-coded to indicate which business objective it ties back to.
It’s easy to get lost when you build without direction. Color-coordination ensures your product initiatives fulfill a business-goal, so you aren’t building superfluously and wasting valuable time and resources. If a theme doesn’t relate to a business objective and drive a measurable KPI, you should question why it’s on the roadmap.
There are numerical values in the “Priority” and “Effort” columns of the roadmap to help determine the importance of an initiative.
You may have already guessed that initiatives of high priority are assigned a higher “priority” number, and the “effort” is based on the number of sprints an initiative will take to complete.
We use these values to determine a ratio (priority:effort) to help teams determine which actions will create the highest impact, with the lowest lift. For example, if a theme is assigned a priority of 5, with an effort of 2, then the ratio is 5:2, or 2.5. The best themes to prioritize will have not just a high “priority” score — but also a high ratio.
Remember that business objectives, prioritization, and ratios may change over time based on new knowledge as you continue to build — it’s better to have an up-to-date roadmap than a stale one.
2. User Stories:
Now that we’ve outlined some of the big-picture documentation, let’s get granular.
One of the most important pieces of documentation is a user story. A user story is a brief, simple description of a feature or functionality from the perspective of an end user. It captures what a user wants and why. It uses language that both technical and non-technical stakeholders can understand. User stories help ensure development delivers value to users.
How you write and deploy user stories should be standard across builds to ensure actionability and quality. Before diving into the components of a user story itself, it’s important that your team establishes two key definitions:
Definition of Ready (DoR): This is your definition for whether a user story is ready to be included in a sprint, and it’s usually used during backlog grooming and sprint planning rituals. Your DoR should not change from story to story — instead, it is a company-wide standard.
Some examples of DoR criteria include, but are not limited to:
Is a description provided?
Have the validation rules been considered?
Are acceptance criteria listed?
Is the story linked to an epic?
At Remedy, our user stories have to meet the “INVEST” framework, which means they need to be independent, negotiable, valuable, estimable, small (can fit within a sprint), and testable.
Definition of Done (DoD): This is your definition for whether something is ready to be deployed (to staging, production, etc.). Your DoD will have common components across all user stories but some criteria may vary from story to story. For example, for a healthcare startup, some user stories may not be considered “done” until they’re reviewed by a clinical officer or compliance team.
Some examples of DoD criteria include, but are not limited to:
Have we completed all the acceptance criteria?
Do we have unit test coverage?
Has the work been tested by QA and validated for no errors?
Now that we’ve covered these key definitions, let’s talk about what components make up the user story itself.
All users stories should include:
A description of the feature or functionality from the perspective of an end user. A common format is, "As a [user], I want [feature] so that [benefit]."
Acceptance criteria, which are the boxes that need to be ticked to validate that a story is done. They clearly define success for a particular user story.
What’s out of scope so that you can move quickly while tracking what elements should be focused on down the line. Sometimes you cut corners to get functionality to users quickly; it's important to note this so there are no surprises later on. If someone returns to the documentation, they should understand what was left out and why.
Reference Materials to show what other products or features were used as references during the build. Reference materials can include designs, schemas, and architectural diagrams.
Non-Functional Requirements, which are criteria or constraints that specify the quality attributes, performance characteristics, security measures, and other aspects of a software product that are not related to its functional behavior.
Subtasks, which are independent, broken-down steps of the user story defined by the engineers. If the roadmap theme is the “why” and the user story is the “what”, the subtask often covers the “how.”
Estimation of the size of the user story and the relative effort required to implement it, written in terms of story points. Stories should be estimated by the team members performing the work, not management; this represents the team’s commitment based on their current understanding.
Here’s an example of an anonymized user story we created for a healthtech partner:
Here are a few aspects of this user story to make note of:
The user story description clearly identifies the type of user (business owner), the feature (receive kit notifications), and the benefit (to stay informed and be able to promptly respond). This language is meaningful to all stakeholders, both technical and non-technical.
The number of story points in this example is 3. At Remedy, our engineers determine story points using the Fibonacci sequence (1, 2, 3, 5, 8, 13…). We have a guideline that stories should not exceed 5 points to ensure they can be delivered within a sprint. Remedy’s goal is to deliver value every single sprint.
The Definition of Done (DoD) is clearly defined at the bottom of the story based on specific attributes. It includes acceptance criteria, unit tests, code reviews, etc.
When we join companies’ product teams, we often see vague user stories that say “integrate payments” with a simple description of “use Stripe.” As a result, you might wonder how and why that feature was implemented — and if you aren’t the original engineer, this makes it tough to revisit the code.
Like an internal team, Remedy operates with a product-focused mindset. That’s why we’re committed to making sure our work is well-documented during our multi-year partnerships.
All in all, as a small team, be strategic in your documentation process. Document only what you need – product roadmaps and user stories – to ensure that your short-term decisions will have an immediate impact without slowing you down. As these strategic wins result in growth, continue to enhance your documentation processes to maintain velocity with each new team member.
Remember, if you didn’t document it (properly), did it really happen?
Sign up for our newsletter to get notified of all future our product workshops and stay in the loop with our other product advice.
Comments