# Product Vision Template

> **Formats:** Markdown (canonical) | DOCX | PDF
> **Updated:** 2026-03-22
> **License:** CC BY 4.0 -- Kate Makrigiannis / k8mak.com

A fill-in-the-blank template for writing a product vision statement that's clear enough to align a team and specific enough to guide real decisions.

## When to use this

You're starting a new product, resetting direction on an existing one, or your team keeps building features without a shared sense of where the product is going. A vision statement answers "what are we building and why does it matter?" in a way that everyone on the team can repeat without reading a slide deck.

---

## The vision statement template

Use this structure. Fill in each bracketed field. If a field is hard to fill, that's a signal -- it means the team hasn't aligned on that dimension yet.

```
For [target user/persona],
who [need or problem they face],
[product name] is a [product category]
that [key benefit or value proposition].

Unlike [current alternative or competitor],
our product [primary differentiator].
```

**What each line does:**

| Line | Purpose | Common mistake |
|---|---|---|
| **For** | Names the specific user. Not "everyone." | Too broad: "For healthcare professionals" vs. "For primary care physicians managing 2,000+ patient panels" |
| **Who** | States the problem in the user's language. | Describing the solution instead of the problem |
| **Is a** | Anchors the product in a recognizable category. | Inventing a new category nobody understands |
| **That** | Names the single most important benefit. | Listing 5 benefits instead of picking one |
| **Unlike** | Names what the user does today without your product. | Ignoring competitors or pretending they don't exist |
| **Our product** | States what makes you different. | Differentiation that sounds good but isn't defensible |

---

## How to fill it in

### Step 1: Start with the user and the problem

Write the "For" and "who" lines first. These are the foundation. If you can't name a specific user with a specific problem, you don't have a vision -- you have a technology looking for a purpose.

**Test:** Can you picture this person? Do you know their name, their job, their Tuesday morning? If not, go do user research before writing a vision statement.

### Step 2: Name the category and benefit

The "is a" line sets expectations. A "medication tracking app" is understood differently than a "chronic disease management platform." Pick the category that matches how your user would describe the product to a friend.

The "that" line is the hardest. You get one benefit. Not three. Not a compound sentence with "and." One. Pick the benefit that, if you nailed it and nothing else, would still make the product worth using.

### Step 3: Draw the contrast

The "unlike" line grounds the vision in reality. Your user is doing something today -- spreadsheets, phone calls, a competitor's product, nothing at all. Name it. This shows you understand the world your user lives in.

The differentiator line explains why switching to your product is worth the effort. It should be specific and defensible. "Better user experience" is not a differentiator. "Reduces clinician documentation time by 60% through voice-to-chart AI" is.

---

## Vision statement checklist

Before sharing your vision statement, verify:

- [ ] **Specific user.** You named a real persona, not "users" or "customers"
- [ ] **Real problem.** The problem is stated from the user's perspective, not your product's
- [ ] **Recognizable category.** Someone outside your team would understand what kind of product this is
- [ ] **One primary benefit.** Not a list. One.
- [ ] **Honest alternative.** You named what the user does today, not a straw man
- [ ] **Defensible differentiator.** You can explain why this is true and why competitors can't easily copy it
- [ ] **Memorable.** A team member can repeat it from memory after hearing it once
- [ ] **Stable.** This statement should hold for 12-18 months. If it changes every sprint, it's a strategy, not a vision

---

## Worked examples

### Example 1: Health-tech

```
For newly diagnosed diabetics managing their condition for the first time,
who struggle to track glucose, medication, and diet across disconnected tools,
HealthAlly is a personal health companion app
that simplifies daily diabetes management into a single, guided routine.

Unlike generic health trackers that record data without context,
our product connects glucose readings, medication logs, and meal data
to show patients the patterns that matter -- and shares them directly
with their care team.
```

### Example 2: B2B SaaS

```
For product managers at mid-size SaaS companies,
who spend 5+ hours per week assembling status updates from 4 different tools,
ShipSync is a delivery intelligence dashboard
that auto-generates stakeholder-ready updates from your existing project data.

Unlike manual status reports and slide decks,
our product pulls from Jira, GitHub, and Slack to surface what changed,
what's blocked, and what shipped -- without anyone writing a word.
```

### Example 3: Internal tool

```
For clinical research coordinators managing 10+ active trials,
who lose hours each week reconciling enrollment data across spreadsheets
and regulatory systems,
TrialTrack is an enrollment management platform
that gives coordinators a single, real-time view of every patient
across every trial.

Unlike the current process of emailing spreadsheets between sites,
our platform syncs enrollment status automatically and flags
compliance risks before they become audit findings.
```

---

## Facilitator tips

If you're coaching a team through vision writing:

- **Write individually first, then converge.** Have each person write their own version. Compare them. The disagreements are the most valuable part -- they show where the team isn't aligned.
- **The "For" line reveals strategy.** If the team can't agree on who the primary user is, that's not a writing problem -- it's a strategy problem. Solve it before wordsmithing the statement.
- **One benefit is a constraint, not a limitation.** Teams resist picking one benefit because they're afraid of leaving things out. Remind them: the vision statement is a compass, not a feature list. It points direction. The roadmap covers the rest.
- **Test with someone outside the team.** Read the vision statement to a colleague who doesn't work on this product. If they can explain back what the product does and why it matters, the statement works. If they look confused, rewrite.
- **Revisit annually, not quarterly.** A vision that changes every quarter isn't a vision -- it's a mood. Vision statements should be stable enough to guide 12-18 months of work. If the fundamentals change, rewrite. If just the priorities shift, that's a roadmap update, not a vision update.

---

## How did it go?

After writing your vision statement, check:

- [ ] The statement fits in a single paragraph (not a page)
- [ ] A team member can repeat it from memory
- [ ] It names a specific user, not "everyone"
- [ ] The benefit is singular, not a list
- [ ] The differentiator is defensible, not generic
- [ ] Someone outside the team understood it on first read
- [ ] The team agrees on it (disagreements resolved, not papered over)

---

*Part of the [k8 Agent Toolkit](https://k8mak.com/agent-toolkit). Download other formats at k8mak.com/resources.*