The Product 360 Framework

Product 360 connects nine questions about your product to current evidence, named owners and a review cadence. Use it to explain your decisions and see where the evidence is missing.

Why this matters

Product context often sits across old decks, tickets and people’s memories. Each new question forces the team to reconstruct it. A Product 360 gives those answers a shared home: connected artifacts, each with an owner and a review date.

Use it to answer customers, finance, sales and executives consistently. Chapter 37 shows how to build one.

What a product manager is for

The four risks

Marty Cagan’s Inspired identifies four risks:

• Value: will customers buy or use it?
• Usability: can users operate it?
• Feasibility: can engineering build it with available time, skills and technology?
• Business viability: can sales, marketing, finance, legal, support and partners sustain it?

The PM is accountable for value and viability, the designer for usability, and the tech lead for feasibility. The team owns all four together. Own the value and viability artifacts. Understand and challenge the usability and feasibility evidence.

In Empowered, Cagan advocates giving teams problems to solve. Transformed extends this into a product operating model: discovery before delivery, small instrumented releases, and strategy-led problem selection. Product 360 makes that model visible through its artifacts.

Business, technology and user experience

Martin Eriksson places product management at the intersection of these three disciplines. Maintaining the 360 requires regular contact with all three.

Ken Norton describes the PM as an advocate “for whoever isn’t currently in the room.” Written customer, engineering, sales and finance evidence helps represent those interests when decisions happen.

How AI changes the role

In early 2025, Cagan suggested AI could shrink a typical team from about eight people to three: a PM, designer and engineer. By mid-2026 he qualified that optimism. In “The AI Productivity Paradox,” he argued that accelerating an output-focused process can increase shipping without improving outcomes. He later questioned whether AI would create as many strong product creators as he first expected.

A late-2025 survey by Lenny Rachitsky and Noam Segal covered about 1,750 tech workers. PMs used AI most for PRDs and prototypes. Nearly two-thirds saved four or more hours weekly. Fewer used it for research or roadmap choices. Norton’s twenty-year retrospective similarly emphasizes judgment, influence and advocacy.

AI reduces the effort of producing artifacts. You still choose which artifacts matter, make their decisions and verify their contents.

Three levels of product work

Shreyas Doshi distinguishes impact (choosing work that moves the business), execution (doing it well) and optics (showing that work accurately). Answer an impact question such as “should we enter this market?” with strategic evidence. A release-status update answers a different question.

Strategy artifacts support impact decisions. Plans, specs and metrics support execution. Reviews and communication make the work visible.

The nine dimensions of the Product 360

The Product 360 divides the product into nine dimensions. Each one answers a question someone will eventually ask you, and each maps to a part of this book.

The nine group into three families. Direction (customer, strategy, business) answers why and for whom. Delivery (build, measure, go-to-market) answers what and how. Durability (operate, lifecycle, leadership) answers how the product keeps working as a business over years, which is the part PM training often skips. Part VIII (Chapters 31 to 33) covers AI across all nine dimensions, and the Capstone (Chapter 37) shows how to build each one.

AI across all nine dimensions

AI changes the product and the work used to manage it.

AI in the product. Add questions about user trust, inference cost, evaluations, model versions, quality variation, provider changes and model retirement. These belong within the existing dimensions. Chapter 31 covers them in depth.

AI in the work. A harness connected to approved documents, tickets, CRM and analytics can draft artifacts and compare their contents. Keep sources readable and current. Chapter 32 covers these workflows.

The artifact stack

An artifact is a document with an owner, purpose, audience and update rhythm. These four properties make it maintainable.

Three kinds of artifact

Artifacts change at different speeds, and treating them all the same is how teams end up with either a stale strategy or a strategy that changes every week.

• Durable artifacts change rarely, usually once a year or at a major strategic shift. Vision, strategy one-pager, personas, positioning. If these change monthly, you don’t have a strategy; you have a mood.
• Living artifacts change on a cadence: weekly, monthly or quarterly. Roadmap, metrics dashboard, OKRs, risk register, decision log, competitive landscape. If these go a quarter without an update, they’re lying to someone.
• Event artifacts are created for a specific decision or moment and then archived. PRDs, PR/FAQs, launch plans, experiment readouts, business cases, post-launch reviews, sunset plans. They’re written once, used intensely, and then become the history that explains why the product looks the way it does.

The stack has a direction. Durable artifacts constrain living ones: the roadmap should be explainable from the strategy. Living artifacts decide which event artifacts get written: a PRD exists because something made it onto the roadmap. When an event artifact contradicts a durable one (a PRD for a segment the strategy says you don’t serve), you’ve found either a bad PRD or a strategy that needs revisiting. Both are worth knowing, and the stack makes the conflict visible.

The minimum viable 360

Start with twelve core artifacts. Create the other templates when a decision requires them.

If you’re building a 360 from nothing, build these twelve first, in roughly this order. The Capstone walks through it in a 30/60/90-day plan.

Where the 360 lives

The 360 needs one home: a single page (the Product 360 index) that links every artifact, names its owner and shows when it was last updated. That page can live in Confluence, Notion, Google Drive, a SharePoint site or a Git repository. The tool matters less than three properties:

1. One entry point. Anyone new to the product starts at the index.
2. Visible freshness. Every artifact shows its owner and last-reviewed date. Stale artifacts are flagged, not hidden.
3. Readable by machines. In 2026 this one matters more than it used to. If your artifacts are in formats an AI harness can read through a connector (pages, docs, Markdown files), the harness can answer questions across the whole 360. If they’re screenshots of slides, it can’t.

The operating cadence

Artifacts don’t keep themselves true. People do, on a rhythm. The operating cadence is the calendar that says which artifact gets reviewed when, by whom, and what decision the review produces.

This cadence synthesizes established practices. In Working Backwards, Colin Bryar and Bill Carr describe Amazon’s weekly business review: metric owners explain variances in a fixed metric set. Quarterly business reviews are common in enterprise software. Amazon’s OP1 and OP2 planning cycles produce and revise annual narratives.

Melissa Perri and Denise Tilles identify process and governance as one pillar of Product Operations, alongside business and data insights and customer and market insights. Regular reviews connect that evidence to decisions.

Every ritual must support a decision. Record the date, decision, alternatives, approver and reasons in the decision log. This preserves context for later reviews. Chapter 29 explains decision logs and DACI: Driver, Approver, Contributors and Informed.

How to build your Product 360

The method has six steps. The Capstone expands them into a full 30/60/90-day plan with prompts.

1. Scope the surface area. Write down, in one paragraph, exactly what you own: which product or products, which customers, which teams, which revenue. Scope disputes are a common hidden cause of a broken 360. If two PMs both think they own pricing, neither of their 360s is true.
2. Inventory what exists. Gather every document, deck, dashboard and ticket that describes the product. Don’t judge it yet; just collect it. An AI harness with connectors into your doc tools makes this much faster.
3. Map it to the nine dimensions. Sort the inventory by dimension and kind (durable, living, event). Mark each item as current, stale or contradicted. Gaps become obvious immediately.
4. Build the spine. Create or repair the twelve spine artifacts, in order, starting with the Product 360 index. Reuse what’s good; rewrite what’s stale. Each artifact gets an owner and a review date.
5. Set the cadence. Put the rituals on the calendar, with the artifacts each one reviews. Start lighter than you think you need. A weekly metrics review and a monthly roadmap review beat an ambitious calendar nobody attends.
6. Publish and keep it alive. Share the index with your team, your manager and your key stakeholders. Tell them it’s the source of truth. Then make it true: when a decision happens, it goes in the log; when a strategy changes, the one-pager changes first.

The AI lens

Your 360 is your AI context

In 2026, AI turns a well-kept Product 360 into reusable context. When your artifacts are current and readable, you can hand them to a harness and ask questions that used to take a week of meetings:

• “Does the Q3 roadmap still trace back to the strategy one-pager? List anything on the roadmap that doesn’t.”
• “Summarize every decision in the log that touches pricing, and flag any that contradict the current packaging doc.”
• “Draft a first version of the QBR narrative from the dashboard export, the OKR tracker and this month’s customer insight summary.”

These tasks need current, connected sources. The harness can compare written artifacts and expose gaps for you to review.

What not to hand to AI

The harness drafts, checks and summarizes. It doesn’t decide, and it doesn’t own. Three guardrails:

• Data boundaries. Customer data, unreleased financials and confidential strategy go only into tools your company has approved for that data. Check before you connect.
• Decisions stay human. An AI can lay out pricing options with their tradeoffs. You and your approvers choose. The decision log records who decided, and it shouldn’t say “the model.”
• Verify the numbers. AI-generated summaries of metrics are fast and frequently wrong in small ways: a misread column, a wrong time window, a silently dropped segment. Every number that goes into a durable artifact or an executive review gets checked against the source. Chapter 19 covers how.

The Beacon case: a new Principal PM’s first inventory

You start with step 1 and write the scope paragraph: “Beacon: the standalone AI incident-management product, including Beacon Classic (legacy correlation) and Beacon Agents (diagnosis and supervised remediation). Customers: about 420 enterprise accounts plus the MSP partner channel. Teams: 3 PMs, 1 designer, 5 engineering teams, 2 applied AI engineers, a PMM and shared product ops. Revenue: about $48M ARR.” You send it to your manager and to the group PM for Northlight Observe, because you suspect the boundary between Beacon and Observe is fuzzy. It is: Observe’s PM believes alert correlation belongs to Observe. That disagreement goes into the decision log as the first open item.

Step 2, the inventory, turns up 140 documents. Sorted against the nine dimensions, the picture looks like this:

The gaps rank themselves. Gross margin and the missing North Star are business-critical and visible to executives within weeks. The Beacon Agents launch has a fixed date. Beacon Classic’s end of life is creating customer escalations. So your first spine artifacts after the index are the business model summary, the North Star and metric tree, the launch plan, and a lifecycle assessment for Classic. Personas and strategy follow, but they can wait a month; the four urgent artifacts can’t.

By the QBR, the index covers nine dimensions and twelve artifacts: four new, five repaired, and three marked “stale, owner assigned.” Six decisions are logged and reviews are scheduled. The gaps are visible and owned.

Product 360 artifacts

# [Product name] · Product 360

**Owner:** [Name, title]   **Last reviewed:** [YYYY-MM-DD]   **Lifecycle stage:** [Introduce / Grow / Mature / Decline / Retire]

## Scope
[One paragraph: which products, customers, teams and revenue this 360 covers. Name what is explicitly out of scope and who owns it.]

## The 360 at a glance
| Dimension | Key question | Artifact (link) | Owner | Kind | Last reviewed | State |
|---|---|---|---|---|---|---|
| Customer | Who is this for, and what job? | [Personas and problem hypothesis] | | Durable | | Current / Stale / Missing |
| Strategy | Where we play, how we win | [Vision and strategy one-pager] | | Durable | | |
| Strategy | Who we compete with | [Competitive landscape] | | Living (Q) | | |
| Business | How it makes money | [Business model and unit economics] | | Living (Q) | | |
| Build | What's next | [Outcome roadmap] | | Living (M) | | |
| Measure | How we know it works | [North Star, metric tree, dashboard] | | Living (W) | | |
| Measure | What we committed to | [OKRs] | | Living (Q) | | |
| Go-to-market | How it reaches customers | [Positioning and messaging] | | Durable | | |
| Operate | How we run it | [Operating cadence, decision log, risk register] | | Living (W) | | |
| Lifecycle | Where it is in its life | [Lifecycle stage assessment] | | Durable | | |
| Leadership | Who must be aligned | [Stakeholder map and DACI] | | Living (Q) | | |
| AI (if applicable) | Quality, cost, models, risk | [Eval plan, AI cost model, model register, AI risk assessment] | | Living (M) | | |

## Current priorities
1. [The one to three things that matter most this quarter, each linked to its artifact]

## Open decisions
[Link to the decision log, filtered to open items]

## Active events
[Links to in-flight PRDs, launch plans, business cases, sunset plans]

## Key contacts
[Engineering lead, design lead, PMM, product ops, sales lead, support lead, finance partner]

# Artifact inventory · [Product] · [Date]

## Scope statement
[Paste the one-paragraph scope.]

## Inventory
| # | Document | Link | Dimension | Kind (durable/living/event) | Last updated | Owner | State (current/stale/contradicted) | Notes |
|---|---|---|---|---|---|---|---|---|
| 1 | | | | | | | | |

## Gaps by dimension
| Dimension | Spine artifact | Exists? | State | Business risk if missing (H/M/L) | Deadline driver | Priority |
|---|---|---|---|---|---|---|
| Customer | Problem hypothesis and personas | | | | | |
| Strategy | Vision and strategy one-pager | | | | | |
| Strategy | Competitive landscape | | | | | |
| Business | Business model and unit economics | | | | | |
| Build | Outcome roadmap | | | | | |
| Measure | North Star and metric tree | | | | | |
| Measure | OKRs | | | | | |
| Go-to-market | Positioning and messaging | | | | | |
| Operate | Cadence and decision log | | | | | |
| Lifecycle | Lifecycle stage assessment | | | | | |
| Leadership | Stakeholder map and DACI | | | | | |

## Contradictions found
[Each pair of artifacts that disagree, what they disagree on, and who needs to resolve it.]

## Build order
1. [Artifact] because [deadline or risk]

# Operating cadence · [Product] · [Quarter]

| Cadence | Ritual | Day and time | Attendees | Artifacts reviewed | Output | Owner |
|---|---|---|---|---|---|---|
| Weekly | Metrics review | | PM, eng lead, design, analyst | Dashboard, risk register | Adjustments, escalations | |
| Weekly | Team sync | | Product team | Decision log, discovery log | Decisions logged | |
| Biweekly | Sprint review and planning | | Product team | Backlog, release plan | Sprint commitment | |
| Monthly | Product review | | Leadership, PM, eng, design, PMM | Roadmap, OKRs, competitive changes, insight summary | Roadmap changes, asks | |
| Quarterly | Business review | | Leadership, finance, sales, CS | Business model, OKRs, lifecycle stage | Bets, staffing, pricing | |
| Annually | Strategy refresh | | Leadership | All durable artifacts | Strategy for the year | |
| Per event | Launch go/no-go | | Launch team | Launch plan, readiness checklist | Ship or hold | |

## Rules
- Every ritual produces a decision or is cancelled after two meetings without one.
- Decisions are written in the decision log within 24 hours.
- Each artifact shows its owner and last-reviewed date. Anything past its review date is marked stale on the 360 index.

Prompts

Goal: Turn a pile of existing documents into a first Product 360 inventory.
Paste in (or connect the harness to): the documents, decks, pages and dashboards you've gathered for [product]. Use only tools approved for this data.

You are helping a Principal PM build a Product 360 for [product]. The Product 360 has nine dimensions: Customer, Strategy, Business, Build, Measure, Go-to-market, Operate, Lifecycle, Leadership. Artifacts are durable (change yearly), living (change on a weekly to quarterly cadence) or event (created for one decision or moment).

For every document provided:
1. Give its title, link or file name, and last-updated date if visible.
2. Assign one primary dimension and the artifact kind.
3. Summarize in one sentence what question it answers.
4. Mark it current, stale (older than its natural cadence) or contradicted (conflicts with another document), and say which document it conflicts with.

Then produce:
- A table of the twelve spine artifacts (Product 360 index, problem hypothesis and personas, vision and strategy one-pager, competitive landscape, business model and unit economics, outcome roadmap, North Star and metric tree, OKRs, positioning and messaging, operating cadence and decision log, lifecycle stage assessment, stakeholder map and DACI) showing which exist, their state and the best existing source for each.
- A list of every contradiction you found, quoting the conflicting statements.

Base every row on a supplied document. Mark unknown dates or states as "Unknown."

Check the output: open three documents the model marked "current" and two it marked "contradicted" and confirm it read them correctly. Spot-check that no spine artifact was marked "exists" on the strength of a passing mention.

Goal: Produce the first version of the Product 360 index page.
Paste in: the scope paragraph, the completed artifact inventory and the list of open decisions.

Using the inventory below, draft a Product 360 index for [product] using this structure: scope; a table of the nine dimensions with key question, linked artifact, owner, kind, last reviewed and state; current priorities (no more than three); open decisions; active events; key contacts.

Rules:
- Use only artifacts and facts that appear in the inventory. Where an artifact is missing, write "Missing" and leave the owner blank for me to fill.
- Rank current priorities by business risk and deadline, and give a one-line reason for each.
- Keep the index under 600 words, using links and status fields.

[inventory]

Check the output: every link should resolve to a real document, every "current" label should match the inventory, and the priorities should be ones you'd defend to your manager.

Goal: Get a realistic first cadence instead of an aspirational one.
Paste in: team size and roles, existing recurring meetings, the planning calendar (QBR dates, annual planning), and upcoming events such as launches.

I own [product]. Here's my team and the meetings that already exist: [details]. Propose an operating cadence using the fewest new meetings possible. Reuse existing meetings where they can absorb a ritual. For each ritual give: frequency, attendees, the artifacts reviewed, the decision it produces and a 1-line agenda. Flag any ritual that has no clear decision output, and recommend cutting it. Finish with the total hours per week the cadence costs the PM and the engineering lead.

Check the output: count the hours yourself. If the PM's ritual load exceeds about 20% of the week, ask for a lighter version.

Goal: Find places where your artifacts disagree before an executive does.
Paste in: your current strategy one-pager, roadmap, OKRs, business model summary and positioning doc (or point the harness to them).

Compare these artifacts for [product] and list every contradiction or unsupported link. Specifically:
1. Roadmap items that don't trace to a strategic choice in the one-pager.
2. OKRs that measure something the strategy doesn't prioritize, or priorities with no OKR.
3. Positioning claims the roadmap doesn't support.
4. Business-model assumptions (margin, price, growth) that conflict with the latest numbers.
For each, quote both sources, explain the conflict in one sentence and suggest which artifact is more likely to be wrong and why.

Check the output: for each contradiction, decide yourself which artifact to change, and log the decision.

Anti-patterns

Checklist

• I’ve written a one-paragraph scope for my product, and my manager and neighboring PMs agree with it.
• Every existing document is inventoried and mapped to a dimension and artifact kind.
• The Product 360 index exists, links every spine artifact and shows owners and last-reviewed dates.
• All twelve spine artifacts exist, or are explicitly marked missing with an owner and date.
• For an AI-powered product, the eval plan, AI cost model, model register and AI risk assessment are on the index.
• Contradictions between artifacts are listed, and each has a decision owner.
• The operating cadence is on the calendar, and every ritual names the decision it produces.
• A decision log exists and has entries from the last two weeks.
• The index is shared with my team, my manager and key stakeholders as the source of truth.
• The 360 lives somewhere an approved AI harness can read it.