<aside> ✨ You're reading page 4 of the Product Development Handbook.
Navigation
**Welcome
** People and Roles
Collect Data
→ Capture Context
Define a Feature
Prioritize
Build
Measure
</aside>
One of the hardest parts of software development is communication and getting a team of people to all have the same context of what they are building, and why. There is a disconnect between design, business, and development. These roles have different priorities or understanding of problems, yet they come together to reach the same outcome.
That's why teams need a consistent method for sharing context. Context documents are sometimes called, briefs, initiatives, programmes, themes, recipes, or areas of work. They help get a product team on the same page about what they are trying to achieve. Context documentation is high-level and living documentation - instead, they inform about the wider context and link to the feature specification documentation.
The two methods for capture context are Briefs and PRFAQs. Templates for Briefs and PRFAQs are available below.
<aside> 😫 I was working in a small team of 6 and we were wrapping up the build of a new feature, about to deploy it into production. I was chatting with one of the developers about building this feature, and then he said, "Well, I know I spent a lot of time working on this feature, but I don't know why we are actually building this feature in the first place." This showed me that throughout all of our design and development process, the context around decision making was always communicated verbally through meetings. This meant that there was no place to reference reasons for why we were doing this work. We needed to start focusing on documentation practices to build a better product.
</aside>
The goal of context documentation for everyone to know:
Context needs to be communicated everyone. Things need to be visible always are: