PRODUCT VISION

بيان رؤية المنتج

tasleemat asset PMO-03.02 template --lang en

Deliverable Summary & Governance Boundaries

Lifecycle Phase Alignment

Phase 03: Initiating

Sizing Tier Requirements

Tier 1 Tier 2 Tier 3

Validation Contract

This deliverable conforms to a strict companion Draft 2020-12 JSON Schema for automated structural and semantic validation.

tasleemat validate PMO-03.02 ./completed_data.json

Template Markdown (Bilingual)

<!--  LLM INSTRUCTIONS: Fill in the [ Add details... ] placeholders based on project context.

The product vision provides the future view of the product being developed. The product vision is aspirational, yet achievable and realistic. It is developed at the very beginning of a project, and is often an input to the business case.

The product vision is often used in place of a project charter on agile-based projects. It is developed once, at the beginning of the project.

Tailoring Notes:

*   Document the business goals that the product is aligned to.

*   Identify key competitors and how this product will be better.

*   Describe what differentiates this product from similar products in the market.

*   You can combine all the information into a sentence or two, or you can follow the formula shown in the form below. The sections are here to be filled or removed, not all to be completed.

*   The vision is written once, at the start. If it is revised later, record what changed and why, because a vision that moves without a record leaves the backlog and the roadmap built on the earlier one without explanation.

Alignment: the product vision should be aligned and consistent with the following documents: Product backlog, Roadmap, Release plan.

Writing guidance:
*   Write for a reader who has not met the customer. A vision that only makes sense to the team that wrote it has not been communicated.
*   Keep it aspirational but reachable. If the vision describes something the team could not build in the planned time, it will be quietly abandoned, and what remains is a document nobody trusts.
*   Say who the customer is before saying what the product does. A product described without a customer is a solution looking for a problem.
*   Prefer a few specific commitments over many vague ones. A vision that promises everything commits to nothing.

Section Instructions:
*   **Vision Elements:**
    -   **Target Customer:** The person or group who will buy or use the product. Name who they are in a way that lets a reader tell whether a given person is in scope, because "small business" and "enterprise customer" lead to different products.
    -   **Needs:** The needs or requirements that the product will address. State the underlying need rather than the feature that answers it, because features can be built many ways and the need cannot.
    -   **Product and Key Attributes:** A description of the product that includes attributes, functional and nonfunctional requirements, and top-level requirements. Keep this at the top level: it is a vision, not a specification, and detail added here will age badly before the backlog is written.
    -   **Key Benefit:** Why the customer would buy the product. One benefit, stated in the customer's terms rather than the team's. If several benefits compete, record the primary one here and the others below, because a vision that promises everything commits to nothing.
*   **Tailoring Detail:**
    -   **Business Goals:** The business goals the product is aligned to. This is what makes a vision arguable: without it, "key benefit" cannot be weighed against a competing use of the same budget.
    -   **Competitive Position:** The key competitors, and how this product will be better. "Better" must be measured on something the customer cares about; being newer or cheaper to build is not the same thing.
    -   **Differentiation:** What differentiates this product from similar products in the market. If nothing does, that is a finding worth recording now rather than discovering after the product is built.
    -   **Vision Statement:** The whole vision in a sentence or two, once the sections above are settled. Write it last, from what the sections concluded, not first as a summary of what was intended.
-->

<h3 dir="ltr" align="right">{{Company_Name}}</h3>
<h2 dir="ltr" align="right">{{Product_Name}} - {{Product_ID}}</h2>
<h1 dir="ltr" align="center">PRODUCT VISION</h1>

| **Date Prepared:** {{Current_Date}} | **Product Owner:** {{Product_Owner_Name}} | **Prepared By:** {{Prepared_By}} |
| :--- | :--- | :--- |  

---

## 1. Target Customer
<!-- The person or group who will buy or use the product. Name who they are in a way that lets a reader tell whether a given person is in scope, because "small business" and "enterprise customer" lead to different products. -->

**Target Customer:**

[ Add details... ]

---

## 2. Needs
<!-- The needs or requirements that the product will address. State the underlying need rather than the feature that answers it, because features can be built many ways and the need cannot. -->

**Needs:**

[ Add details... ]

---

## 3. Product and Key Attributes
<!-- A description of the product that includes attributes, functional and nonfunctional requirements, and top-level requirements. Keep this at the top level: it is a vision, not a specification, and detail added here will age badly before the backlog is written. -->

**Product and Key Attributes:**

[ Add details... ]

---

## 4. Key Benefit
<!-- Why the customer would buy the product. One benefit, stated in the customer's terms rather than the team's. If several benefits compete, record the primary one here and the others below, because a vision that promises everything commits to nothing. -->

**Key Benefit:**

[ Add details... ]

---

## 5. Business Goals
<!-- The business goals the product is aligned to. This is what makes a vision arguable: without it, "key benefit" cannot be weighed against a competing use of the same budget. -->

**Business Goals:**

[ Add details... ]

---

## 6. Competitive Position
<!-- The key competitors, and how this product will be better. "Better" must be measured on something the customer cares about; being newer or cheaper to build is not the same thing. -->

**Competitive Position:**

[ Add details... ]

---

## 7. Differentiation
<!-- What differentiates this product from similar products in the market. If nothing does, that is a finding worth recording now rather than discovering after the product is built. -->

**Differentiation:**

[ Add details... ]

---

## 8. Vision Statement
<!-- The whole vision in a sentence or two, once the sections above are settled. Write it last, from what the sections concluded, not first as a summary of what was intended. -->

**Vision Statement:**

[ Add details... ]

---

## 9. Sign-off and Approvals

| Role | Name | Signature | Date |
| :--- | :--- | :---: | :---: |
| **Product Owner** | {{Product_Owner_Name}} | _______________________ | [ .... - .... - .... ] |
| **Project Sponsor** | {{Project_Sponsor_Name}} | _______________________ | [ .... - .... - .... ] |
| **Key User / Customer Representative** | {{Customer_Representative_Name}} | _______________________ | [ .... - .... - .... ] |
---

<div dir="ltr" align="right" style="margin-top: 20px; font-size: 12px; color: #7f8c8d;">
  <span>Electronic Audit Trail: Hash SHA256: {{Audit_Trail_SHA256_Hash}}</span> <br>
  <strong>Template:</strong> PRODUCT VISION | <strong>Ref:</strong> PMO-03.02 <br>
  <i>Generated on: {{Current_Timestamp}}, by <a href="https://github.com/fakhruldeen/Tasleemat/" style="color: #7f8c8d;">Tasleemat</a></i>
</div>

User Guide & Practitioner Instructions

Tasleemat Forms Guide

Project Artifact: Product Vision

Document Reference: PMO-03.02

This document provides a comprehensive, professional reference to understand the purpose and effective usage of the Product Vision in alignment with the Tasleemat framework.

1. What?

A formal Tasleemat-aligned project document known as the Product Vision, which provides the future view of the product being developed. It is aspirational, yet achievable and realistic, and is developed at the very beginning of a project, where it is often an input to the business case. On agile-based projects it is often used in place of a project charter.

It records four elements: the target customer, the needs the product will address, the product and its key attributes, and the key benefit. It also carries the business goals, the competitive position, the differentiation, and the vision statement itself, each of which the tailoring guidance calls for.

2. Why?

To keep the product pointed at a real customer and a real need while the detail is negotiated later, and to give the business case something concrete to be tested against.

3. When?

This artifact is prepared at the INITIATING Process Group of the project lifecycle. It is developed once, at the very beginning of the project. If it is revised later, record what changed and why, since the backlog and the roadmap will have been built on the earlier version.

4. Who?

Responsibilities: Developed by the Product Owner with the Sponsor, agreed with the target customer or their representative, and signed off by the Project Sponsor or Client.

Tailoring Tips

Document the business goals that the product is aligned to.
Identify key competitors and how this product will be better.
Describe what differentiates this product from similar products in the market.
You can combine all the information into a sentence or two, or you can follow the formula shown in the form. The sections are there to be filled or removed, not all to be completed.
The vision is written once, at the start. Record any later revision and its reason.

Alignment & Dependencies

1. Pre-requisites & Inputs (Upstream Dependencies)

Mandatory:
- Business Case (PMO-01.01)
- Customer & Market Needs Analysis
Optional / Contextual:
- Project Charter (PMO-03.01)
- Strategic Objectives

2. Downstream Dependents

Mandatory:
- Product Backlog (PMO-04.02.08)
- User Story Mapping (PMO-04.02.09)
- Project Roadmap (PMO-04.01.03)
Optional / Contextual:
- Release Plan (PMO-04.03.09)
- Requirements Documentation (PMO-04.02.03)

5. How?

To accurately and professionally complete the PRODUCT VISION, the responsible party must populate the following sections based on the project context (ensure parameters.md is referenced for global project variables):

Target Customer: The person or group who will buy or use the product. Name who they are in a way that lets a reader tell whether a given person is in scope, because "small business" and "enterprise customer" lead to different products.
Needs: The needs or requirements that the product will address. State the underlying need rather than the feature that answers it, because features can be built many ways and the need cannot.
Product and Key Attributes: A description of the product that includes attributes, functional and nonfunctional requirements, and top-level requirements. Keep this at the top level: it is a vision, not a specification, and detail added here will age badly before the backlog is written.
Key Benefit: Why the customer would buy the product. One benefit, stated in the customer's terms rather than the team's. If several benefits compete, record the primary one here and the others below, because a vision that promises everything commits to nothing.
Business Goals: The business goals the product is aligned to. This is what makes a vision arguable: without it, "key benefit" cannot be weighed against a competing use of the same budget.
Competitive Position: The key competitors, and how this product will be better. "Better" must be measured on something the customer cares about; being newer or cheaper to build is not the same thing.
Differentiation: What differentiates this product from similar products in the market. If nothing does, that is a finding worth recording now rather than discovering after the product is built.
Vision Statement: The whole vision in a sentence or two, once the sections above are settled. Write it last, from what the sections concluded, not first as a summary of what was intended.

📥 Associated Templates

6. Reference Example

A fully completed, gold-standard reference example illustrating this artifact in practice is available:

📖 Completed Example: 03_02_Product_Vision_Example.md

LLM Generation Prompt & Agent Instructions

PRODUCT VISION - LLM GENERATION GUIDE

System Prompt / Instructions: This document serves as the detailed instruction set for generating the PRODUCT VISION. When asked to populate this form, use the guidance provided for each section below to accurately generate the required content. Reference parameters.md for global project variables.

Context & Definition: The product vision provides the future view of the product being developed. It is aspirational, yet achievable and realistic, and is developed at the very beginning of a project, where it is often an input to the business case. On agile-based projects it is often used in place of a project charter, and it is developed once, at the beginning.

Alignment & Dependencies: * Pre-requisites (Inputs): * Mandatory: Business Case (PMO-01.01), Customer & Market Needs Analysis * Optional: Project Charter (PMO-03.01), Strategic Objectives * Downstream Dependents: * Mandatory: Product Backlog (PMO-04.02.08), User Story Mapping (PMO-04.02.09), Project Roadmap (PMO-04.01.03) * Optional: Release Plan (PMO-04.03.09), Requirements Documentation (PMO-04.02.03)

Vision Elements

Target Customer

Instruction: The person or group who will buy or use the product. Name who they are in a way that lets a reader tell whether a given person is in scope, because "small business" and "enterprise customer" lead to different products.