This is an overview and intro document. This initial “framing” of the product is the first piece of collateral created for use by the product team. Virtually all other collateral proceeds from it.
A Concise High-level Overview
Why (business requirements, goals)
Who (personas, actors, stakeholders, players)
What (workflow, tasks)
Primary Contributors to the Snapshot are the Product Owner / Manager, Business Analyst
The Snapshot is the point of reference for all team members. You need to have a shared context – especially in an Agile environment.
Describe (at a high level) why we need it – the purpose and goals … from the perspective of the client/user and the enterprise. It is the highest level of description and lays the justification for the business requirements and the product. It’s “the story behind the story”.
It can include framing info like:
- Target audience
- Perceived customer motivation
- Anticipated impact
- Market Forces
- Legacy Issues
- Perquisites and dependencies on previous products
It’s not necessary to flesh each of these bullets out completely, but it provides useful context for team members who interpret the product into code and design.
In many ways, this is your elevator pitch.
Actors & Roles
Identify (at a high level) who can do what … We have to know who we’re talking about and how they work. It lays the practical basis for:
- Use Cases
This is particularly critical to our ability to design a “customer-centric” product.
Identify (at a high level) what you can do.
It’s a practical description of what tasks you need to accomplish in the business requirements, in what order.
This is also why we’re designing the product (from the customer perspective).
Assumptions & Risk
Identify underlying “givens”
- the relationship to existing software.
- technical risks associated with the development of new capabilities.
How does this relate to other system products or components, including a general description of the technical interfaces. This may include:
- Hardware interface requirements (i.e. Technical perspective)
- User interface requirements (i.e. Design perspective)
- Marketing or client-specific information which helps to put the product capabilities into perspective (i.e. Business Perspective)
General Constraints and Guidelines
Factors limiting the design of the product, such as:
- Regulatory constraints
- User constraints
- Product structure constraints
- Performance constraints
This section may also define the criteria by which the product is to be rolled out in phased stages.
Why, Who, and What are essential shared knowledge for every member of the product team.
This concise, accessible “snapshot” is valuable when approaching potential investors.
© The Communication Studio LLC