You can use ClickUp Docs to communicate product requirements with your engineering team and stakeholders.
Read on to learn how Sam solved a major communication problem for their Agile team!
Meet Sam
Sam is a product manager for a cloud-based software company. They are working on a particular feature of their product with a dedicated team including:
-
One designer
-
Two developers
-
One QA engineer
The challenge
The team gets along well, but Sam notices the team spends most of the daily standup meetings asking Sam questions about the feature and how it should work.
Sam decides to give the team guidance outside of standups using ClickUp Docs.
The solution
Sam decides that each feature should have its own Doc. When the team is working on a feature, all the relevant information should be in one place.
Using pages within a Doc allows the team to find relevant answers quickly without looking for and searching through separate Docs.
Sam creates a few pages within the Doc to structure the product brief based on what the team needs to know and might be looking for.
-
Feature team charter
-
Design requirements
-
Functional requirements
-
UX requirements
Tip: Search for specific pages or content within a Doc using the Search feature!
Sam adds headings and other formatting elements to each page to communicate their vision for the feature.
Sam shares the document with the feature team. They work together to write up and agree on the charter.
Sam invites the team to ask questions by adding comments on the Doc so that everyone can see the questions and answers.
Retrospective
A few Sprints fly by, and the team is grateful for the Doc to help guide them. Stand-up meetings are now much more efficient and effective.
A feature improvement is shipped and added to the product. Unfortunately, this causes a new bug in another part of the feature that wasn't being updated in the release.
The developers quickly hotfix the bug, and at their next retrospective, the feature team discusses how this could have been avoided.
A QA engineer suggests some sort of acceptance criteria so that no changes can be sent to production unless all the testing criteria are cleared.
The team agrees! Sam adds a new page to the feature brief Doc to document the acceptance criteria for the feature.
Sam uses Code Blocks ( /co ) to format their acceptance criteria requirements, as the team is already familiar with Gherkin, and ClickUp supports it for code blocks!
The result
As the feature team rolls out more improvements and squash bugs, customers are increasingly adopting the feature. The feature team grows to include two more developers and another QA engineer.
The new team members adapt quickly and start contributing with the help of Sam's feature brief Doc!
Sam also shares the feature brief Doc template with other product managers so they can adapt it for their feature-based teams.
It's a big win for Sam's team, and others too!