Product Analysis Framework

Product Analysis Framework

Overview

Use this skill to turn a product website or product name into a decision-useful analysis document. Optimize for a product manager, founder, investor, strategy, or research audience rather than for marketing copy.

Read the target product's current public sources first. Then separate verified facts from your analysis and write a clear memo using the structure in references/output-template.md.

Workflow

1. Identify the product and the expected output:
   • product name and URL
   • requested language
   • target folder or document destination
   • required sections named by the user
2. Gather facts from current sources:
   • official homepage
   • official docs
   • pricing page
   • security, enterprise, or API pages when relevant
   • recent official blog, funding, or launch announcements when the user wants current context
3. Extract the product shape:
   • what the product does
   • who it serves
   • what jobs it helps users complete
   • how it packages and monetizes value
4. Write the analysis:
   • keep facts and analysis clearly separated
   • use concise sectioning
   • explain why the product is differentiated, not just what features it has
5. Validate before finishing:
   • every fact should map back to a source
   • current facts should be date-aware
   • competitor comparisons should end in a conclusion, not a list

Source Policy

Prefer primary sources. Use official company pages, official documentation, official pricing pages, official security pages, official blog posts, and official press releases first.

When the request depends on current information, always verify it live instead of relying on memory. This includes:

• pricing
• funding announcements
• customer counts
• security claims
• AI features
• enterprise features
• model or protocol support

When a statement is an inference rather than a direct claim, label it as analysis. Do not present strategic interpretation as if it were a quoted fact.

Analysis Dimensions

Cover the dimensions the user explicitly requests first. Then fill in the missing layers that make the memo more decision-useful:

• product overview
• product capabilities grouped by function, not by webpage navigation
• target users or buyers
• core strengths
• core moat or technical moat
• pricing and business model
• market positioning and competitor comparison
• risks, weaknesses, and growth opportunities
• final judgment

For capability grouping, prefer buckets such as:

• core workflow or infrastructure
• user-facing product capabilities
• AI or automation capabilities
• analytics, governance, and enterprise controls

For audience analysis, distinguish among:

• buyer
• daily user
• enterprise approver

Writing Rules

Write in plain, decision-oriented language. Do not turn the document into a feature dump.

Prefer this pattern inside major sections:

1. 事实 or Verified facts
2. 分析判断 or Analysis

When the user does not specify otherwise:

• write in the user's language
• default to Markdown
• optimize for knowledge-base readability
• use short paragraphs and compact tables

Competitor Handling

Pick 3 to 5 comparison products that clarify the market map. Use direct competitors first, then substitutes or adjacent categories if they sharpen positioning.

Compare on:

• positioning
• source of content or product input
• key strengths
• AI or automation capabilities when relevant
• enterprise readiness
• best-fit customer

Do not stop at feature parity. Explain where the target product sits in the market and what kind of company it is best for.

Output

Use the template in references/output-template.md unless the user gives a different structure.

If writing into the user's workspace:

• match the local naming style when obvious
• place the note in the requested folder
• include a short source list at the end
• keep the note easy to scan in Obsidian or Markdown viewers

If the user asks for a reusable framework instead of a one-off memo, expose the section structure and the fact-vs-analysis rule explicitly so it can be reused across products.

Final Checklist

Before finishing, confirm:

• the required user-requested sections are present
• current facts were checked live when needed
• facts and analysis are not mixed together carelessly
• the memo says who the product is for and why it wins
• the conclusion gives a real judgment