A document like this can be used to provide focus and clarity around a team's purpose. This can be used for supersets of multiple product squads or an individual product squad (or a whole company at the early stage). It is best utilized when it is clear, succinct, and arrived at via a team discussion (not something the PM is filling out in a total vacuum).
It's also useful as a "one-pager" you can send around your company (or publish on an internal wiki) so those who are requesting information on your team or want to get stuff on your roadmap have a clear understanding of your priorities and how you think about what you're building. This makes it a lot easier to field incoming requests and show people where your priorities are.
It's important to frame your users goals first in a document like this to clearly define what they are trying to accomplish by using your product. Make sure to paint a clear picture of who your user is as well (be succinct!). This can include goals which are not met by your product but are important to understand for anyone who is building a product for the user persona in question.
This should get to the heart of what your team is doing to meet the users' goals with your product. These things can change over time or remain the same. But this should serve as a place you can look to clearly define what the team is focused on.
List the various types of user personas that could be interacting with your product. You can be a bit more descriptive here than in the primary goals perspective. The idea is to give people a sense of what the user personas you're building for looks like. This could also include internal teams or stakeholders in a company assuming you are doing something like building internal tools or an API.
Pick 2-3 core KPIs that you plan to report on that indicate whether your team is hitting the goals above or not. For an API team this could be things like the reliability & health of the API (error rates, uptime, average response time). You can add/include sub-KPIs where neccesary.
You may choose to give others visibility into your roadmap in this doc. It's a clear way to see whether what you are working on as a team aligns with the