Persona Playbooks
A guide for product managers and strategists on how to organize a growing product intelligence library — build a structured system for user research
Product managers work across more distinct intelligence domains than almost any other role: what users need, what competitors are building, how the market is moving, what's technically feasible, and what the business can support. That breadth is the job's core value — a PM can hold context no single functional lead has — and it's also the reason PM intelligence is so often disorganized. Four distinct domains don't fit into one filing system without a plan.
Left unorganized, that intelligence fails in three predictable ways. Recent information crowds out reliable patterns, so last week's user interview outweighs a trend that's been visible for months. Evidence that exists somewhere in the PM's notes can't be located fast enough for the stakeholder meeting where it would matter. And competitive or market data that looks current may in fact be well over a year stale, cited with a confidence the data no longer earns.
An organized product intelligence library addresses all three at once: it keeps historical patterns next to fresh captures, makes retrieval fast at the moment a decision requires it, and carries the dates that let a PM tell current intelligence from expired intelligence on sight.
Product intelligence divides into four domains, each requiring a distinct organizational structure:
1. Customer and user intelligence: What users say, need, do, and experience — gathered through interviews, surveys, support tickets, reviews, and behavioral data interpretation.
2. Competitive intelligence: What competitors offer, how they position, what they're building, what their customers say about them, and how the competitive landscape is evolving.
3. Market and industry intelligence: The size, shape, and dynamics of the market — customer segments, buying behavior, market trends, regulatory environment, adjacent market movements.
4. Product and craft knowledge: Product management practices, UX patterns, growth frameworks, technical patterns relevant to product decisions, case studies from similar products.
Each domain has different update cadences, different retrieval needs, and different decision contexts. The organizational system must handle all four.
Collection: "Product Intelligence: [Product Name]"
Sub-Collections:
Customer Intelligence:
Competitive Intelligence:
Market Intelligence:
Product Craft:
User research is the highest-quality intelligence for product decisions — and the most poorly organized in most PM knowledge bases. Interview notes are typically in separate Google Docs organized by interview date. Survey results are in spreadsheets. Support ticket patterns exist as summaries that live in the PM's head.
An organized user research library aggregates these across sources:
For each significant user interview:
PARTICIPANT: [Segment — role, company size, industry, product tier; anonymized or coded]
Date: [interview date]
Interview focus: [what was the interview designed to learn?]
KEY FINDINGS:
1. [Most important thing learned — 1-2 sentences]
2. [Second most important thing — 1-2 sentences]
3. [Third — 1-2 sentences]
VERBATIM QUOTES (notable):
"[Direct quote 1]" — re: [topic]
"[Direct quote 2]" — re: [topic]
UNEXPECTED / SURPRISING:
[Anything that contradicted prior assumptions or revealed something new]
PRODUCT IMPLICATIONS:
[What this suggests for product decisions — specific, not vague]
TAGS: [segment: enterprise/smb/consumer], [product area: onboarding/core-workflow/reporting],
[sentiment: positive/negative/neutral], [decision-relevance: roadmap/positioning/pricing]
The segment and product area tags are the organizational backbone of the user research library. When a stakeholder asks "What do enterprise users say about reporting?" you need to filter to segment: enterprise + product area: reporting and retrieve the relevant captures — not search through 80 individual interview notes.
Individual interview captures are data points; patterns are intelligence. The most useful product intelligence is aggregated across multiple sources:
The pattern isn't visible in any individual capture; it's only visible when you can filter across captures by product area, segment, and sentiment simultaneously.
Pattern review protocol: Monthly, run a pattern review of the user research Collection for each major product area:
product area: onboarding + sentiment: negative: how many captures? What are the top themes?product area: core-workflow + sentiment: positive: what are users praising?segment: enterprise + last 90 days: what's the pattern across the most recent enterprise user feedback?These pattern reviews produce the evidence base for roadmap prioritization — and the specific, citable evidence that makes roadmap decisions defensible.
For each significant competitor, maintain a living competitor profile as the anchor document in their sub-Collection:
COMPETITOR: [Name]
Website: [URL] | Pricing page: [URL]
Profile last updated: [date]
TIER: [Primary competitor / Secondary competitor / Emerging player]
OVERVIEW
What they do: [one sentence]
Target customer: [who they primarily serve — be specific]
Pricing: [model and price points — DATE THIS explicitly]
Funding/stage: [last known funding, amount, stage]
POSITIONING
Their headline message: "[from their homepage]"
Core value proposition: [what they lead with]
Who they say they're for: [explicit target market language]
HOW WE WIN AGAINST THEM
Conditions: [specific situations, segments, or deal types where we win]
Our strongest argument:
Customer evidence for our win:
HOW WE LOSE TO THEM
Conditions: [when they win]
Their strongest argument against us:
What customers say when they choose them:
RECENT MOVES (newest first)
[Date]: [Event — feature launch / pricing change / funding / hire / partnership / PR]
[Date]:
PRODUCT OBSERVATION
Strengths: [what their product does well — based on direct observation]
Weaknesses: [gaps in their product — based on reviews, customer feedback, direct observation]
Roadmap signals: [what their job postings and recent launches suggest they're building]
Update cadence: Update competitor profiles in monthly competitive reviews. Not reactively — monthly is the right frequency for competitive intelligence that informs strategic decisions. React immediately only to tier-1 events (direct competitor product launches in your core category, funding rounds that change competitive dynamics, executive changes that signal strategic shifts).
Beyond individual competitor files, maintain a landscape-level synthesis document:
The landscape document is updated quarterly and is the synthesis document you'd use to answer "describe the competitive landscape" in an investor meeting, a board presentation, or a new hire orientation.
Market intelligence has a specific quality problem: quantitative market data ages. A TAM estimate from a 2022 analyst report may be significantly wrong in 2026, but if it's in your intelligence library without a date, you may cite it as if it were current.
Organization principles for market intelligence:
Date every quantitative capture explicitly: "Market size: $4.2B (Gartner, 2024)" — not "Market size: $4.2B." The date is part of the claim.
Replace rather than supplement:
When you find a more current data point for a market metric, replace the old capture (or mark the old one outdated) rather than accumulating multiple conflicting estimates. Having three conflicting market size estimates without knowing which is current is worse than having no data.
Tag by data type:
market-size — TAM/SAM/SOM estimatesgrowth-rate — market growth rate projectionsbuyer-behavior — how customers evaluate and buychannel — how the market reaches customersThese tags enable filtering to all your market intelligence on a specific question ("what do I have on buyer evaluation criteria?") without searching through all market captures.
Beyond intelligence about the specific market and product, product managers benefit from organizing their working knowledge — the PM frameworks, UX patterns, growth approaches, and product strategy resources they consult regularly.
Organization principle: Organize by question, not by source.
"PM: Frameworks — Discovery" — resources you consult when designing discovery research "PM: Frameworks — Prioritization" — resources and methods for roadmap prioritization "PM: Frameworks — Metrics" — resources on product metrics and analytics "PM: Patterns — Onboarding" — design patterns and case studies for user onboarding "PM: Patterns — Growth" — growth engineering patterns and case studies
When you're designing a discovery sprint and you want to consult your working knowledge library, you open "PM: Frameworks — Discovery" rather than searching. The organization by question makes the library a reference tool, not a filing cabinet.
The scenario: A senior PM at a B2B SaaS company is leading the evaluation of whether to expand into an adjacent market segment — mid-market companies, vs. the SMB focus the product currently serves.
Intelligence needed for the decision:
Customer intelligence: What do mid-market companies need that SMB doesn't? What would make the current product inadequate for mid-market? What do mid-market companies say when they evaluate the product and choose not to buy?
Competitive intelligence: Who serves mid-market companies in this category? How do they price and package for mid-market? What features do they emphasize?
Market intelligence: How large is the mid-market segment in this category? What's the buying cycle and evaluation process? Who are the decision-makers?
Library organization for the decision:
Created a temporary "Strategic Q: Mid-Market Expansion" sub-Collection for the 3-month evaluation:
Synthesis after 3 months:
From user intelligence: mid-market lost deals cluster around 3 gaps: (1) no SSO support, (2) no admin controls for multi-team accounts, (3) no audit logs for compliance. These are segment-specific needs — SMB customers rarely mention any of them.
From competitive intelligence: the 2 primary mid-market competitors both offer SSO, admin controls, and audit logs as standard. One pricing at $40/seat/month (vs. our $15 for SMB) — pricing delta suggests mid-market companies expect more capabilities and pay for them.
From market intelligence: mid-market evaluation cycles are 4-8 weeks vs. 1-2 days for SMB. Security review required for 80% of mid-market purchases in the category.
The decision document:
Built from the "Strategic Q: Mid-Market Expansion" Collection; every claim in the 8-page decision document is cited to a specific capture with date.
Recommendation: pursue mid-market expansion; requires 3 specific investments (SSO, admin controls, audit logs) before entering the segment. Expected payback: modeling shows break-even at ~12 mid-market accounts.
Decision memo outcome: presented to VP Product. Approved with funding allocated for the 3 feature investments. VP Product: "This is the clearest market entry analysis I've reviewed in 3 years. The evidence is specific and the gaps are clear."
outdated or replace it — multiple conflicting undated estimates are worse than one current one.For product managers and strategists, the intelligence library is the intellectual infrastructure for every significant product decision. Roadmap choices defended by user research patterns. Market entry decisions supported by specific competitive intelligence. Stakeholder presentations grounded in market data with clear dates and sources. The organizational discipline — four domains, distinct sub-Collections, dated and segment-tagged captures, temporary Strategic Q Collections for current decisions — determines whether the intelligence asset compounds over time or accumulates without serving decisions. The investment is real but modest: the capture and organization discipline produces the evidence base that converts good product intuition into evidence-backed product leadership.
Related reading: Clip Articles for Later Reading.
More WebSnips articles that pair well with this topic.
A guide for educators and course creators on how to organize a growing research library — build a structured teaching resource system for subject matter
A guide for lawyers on how to organize a growing research library — build a structured legal intelligence system for case law developments, regulatory
A guide for marketers on how to organize a growing research library — build a structured marketing intelligence system for competitive ads, campaign
A guide for remote team leads on how to organize a growing research library — build a structured knowledge system for async communication practices
A guide for knowledge workers and consultants on how to organize a growing research library — build a structured system for client intelligence, domain
A guide for PKM and tools enthusiasts on how to organize a growing research library — build a structured web research archive that integrates with your