Compare the options below for the stated user and job to be done. Treat this as a product decision, not a feature checklist. [DECISION AND OPTIONS] [TARGET USER AND WORKFLOW] [MUST-HAVE REQUIREMENTS] [EVIDENCE AND SOURCE NOTES] [CONSTRAINTS] Use only the evidence I provide. If a required input is missing, ask up to 3 clarifying questions before analyzing. Do not infer that a feature exists because a competing product has it.
Produce: 1. A comparison table with rows for each must-have and meaningful differentiator. Include: requirement, user importance, each option’s evidence-backed status (meets, partial, absent, unknown), and the workflow consequence. 2. A short “decision-ready findings” section with the 3 most consequential trade-offs. Distinguish surface parity from differences that change time, error rate, permissions, handoffs, or adoption. 3. A recommendation for the stated decision, including conditions that would change it. 4. A validation plan with 3-5 testable acceptance criteria or research questions. Write them as observable outcomes, not feature requests. 5. An “unknowns and risks” list, separating missing evidence from known limitations. Normalize names that describe the same capability, but do not collapse genuinely different workflows. Account for setup effort, migration, accessibility, integrations, security or permissions, and operating cost when relevant. Self-check that every status has a source note, and flag any requirement that cannot be evaluated with the available evidence.
Fill in
| Placeholder | What to enter | Example |
|---|---|---|
| [DECISION AND OPTIONS] | State the decision to make and name the products, plans, or feature approaches being compared. | Choose a help-desk platform: Zendesk Suite Professional or Intercom Advanced for a 12-person support team. |
| [TARGET USER AND WORKFLOW] | Describe the primary user, their goal, and the steps they currently take. | Support agents triage email and chat, find account history, escalate billing cases, and managers review weekly backlog trends. |
| [MUST-HAVE REQUIREMENTS] | List the non-negotiable needs and any useful differentiators in priority order. | SSO, email and chat tickets, role-based permissions, Salesforce context, multilingual help center, weekly reporting, and predictable cost at 20 seats. |
| [EVIDENCE AND SOURCE NOTES] | Paste verified documentation, test results, screenshots, pricing notes, or customer feedback for each option. | Vendor plan pages dated September; a 30-minute trial of each; IT notes that Salesforce and Okta are already deployed. |
| [CONSTRAINTS] | State budget, timing, technical, legal, security, or change-management limits. | Launch within six weeks; annual software budget under $30,000; IT will support only one new integration. |
How to use
- Describe one user workflow before listing features; it gives the comparison a practical unit of value.
- Paste sources or test notes for every option and label anything you have not verified.
- Inspect the unknowns section before accepting a recommendation.
- Follow up with: “Convert the validation plan into a 10-participant usability test script with pass/fail measures.”
Variations
Build versus buy
Use this when deciding between an internal feature and a vendor solution.
Analyze [PROBLEM] as a build-versus-buy decision using [INTERNAL OPTION], [VENDOR OPTION], [USER WORKFLOW], and [CONSTRAINTS]. Compare time to value, maintenance ownership, integration depth, data handling, customization, and failure modes. Produce a decision table, a 12-month cost and effort assumption list, and a recommendation with reversal criteria. Do not invent costs or technical capabilities; mark unknowns. End with five discovery questions for engineering, security, and users.
Pricing plans
Use this to compare tiers from one software vendor.
Compare [PLANS] for [TEAM AND USE CASE] using [CURRENT USAGE], [EXPECTED GROWTH], and [DOCUMENTED LIMITS]. Build a table for included features, usage caps, add-ons, administrative controls, and annualized cost assumptions. Identify the first limit likely to force an upgrade and any feature that is unnecessary for this team. Recommend a tier and a review trigger. Cite only the pricing evidence supplied and mark unknown billing details.
Competitive brief
Use this to prepare a concise internal product comparison.
Write a competitive feature brief comparing [OUR PRODUCT] with [COMPETITORS] for [TARGET SEGMENT], based on [EVIDENCE]. Include a workflow-oriented matrix, three defensible differentiators, two areas where competitors are stronger, and recommended positioning boundaries. Do not claim superiority without evidence or copy competitors’ terminology without explanation. Flag stale, marketing-only, or unverified evidence. End with three customer interview questions to validate the comparison.
Tips
- Write requirements as outcomes in a workflow, such as “an agent can see account status without leaving the ticket,” not “Salesforce integration.”
- Use “unknown” as a real result; forcing yes-or-no statuses makes a comparison look certain when it is not.
- Separate a capability existing in a product from it being included in the plan you can buy.
- Test the most expensive or irreversible assumption first, such as data migration, permission model, or API coverage.
FAQ
Can AI research product features for me?
It can organize information, but product pages and plans change. Give it dated sources or verify the resulting claims against current documentation.
What makes a feature comparison useful?
It links features to a named user workflow and decision criteria. A long feature inventory without consequences does not reveal trade-offs.
How many options should I compare?
Two to four options keeps the analysis readable. If you have more, use a short screening step before a deeper comparison.