Identify Assumptions Existing
Stress-test a feature idea on an existing product by surfacing risky assumptions across value, usability, viability, and feasibility before you commit engineering time.
Overview
Identify Assumptions (Existing Product) is an agent skill most often used in Validate (also Idea and Build) that surfaces risky assumptions across Value, Usability, Viability, and Feasibility using PM, designer, and engi
Install
npx skills add https://github.com/phuryn/pm-skills --skill identify-assumptions-existingWhat is this skill?
- Three-lens devil’s advocate pass: product manager, designer, and engineer failure modes
- Assumptions organized across four risk areas: Value, Usability, Viability, and Feasibility
- Ingests user-provided PRDs, designs, and research before generating assumptions
- Each assumption callout structure for specificity and testability
- Built for existing-product feature stress tests, not greenfield discovery alone
- three perspectives: Product Manager, Designer, and Engineer
Adoption & trust: 1k installs on skills.sh; 12.3k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You have a feature idea for a product that already ships, but you cannot see which beliefs about customers, UX, GTM, and tech are untested—and which could sink the bet.
Who is it for?
Indie PMs and solo founders adding features to an existing SaaS who want structured risk surfacing before writing tasks or cutting code.
Skip if: Teams that already ran formal assumption mapping with scored experiments, or greenfield ideas with no product context to anchor the four risk areas.
When should I use this skill?
Stress-testing a feature idea for an existing product, doing risk assessment, or preparing for assumption mapping.
What do I get? / Deliverables
You leave with a categorized, multi-perspective assumption inventory you can rank, test, and fold into scope decisions or a tighter PRD before implementation.
- Categorized assumption list across four risk areas
- Per-assumption notes from three stakeholder perspectives
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Validate because the skill targets feature ideas inside a live product—where scoping and de-risking happen before prototype or build expansion. Scope subphase fits assumption mapping and risk assessment that narrows what to build and what must be proven first.
Where it fits
Before sizing a billing add-on, list viability assumptions about finance and legal support.
Compare two enhancement ideas by surfacing which has fewer untested value assumptions.
Attach assumption notes to a PRD so the coding agent knows what must not be treated as settled fact.
Prioritize which usability assumptions to test in a clickable prototype first.
How it compares
Use instead of ad-hoc “what could go wrong?” brainstorming when you need the four risk dimensions and role-based lenses in one pass.
Common Questions / FAQ
Who is identify-assumptions-existing for?
Solo builders and small teams shipping on an existing product who need PM-grade assumption surfacing without a dedicated discovery consultant.
When should I use identify-assumptions-existing?
In Validate when scoping a feature on a live product; in Idea when comparing feature bets; in Build when a spec needs explicit value, usability, viability, and feasibility risks written out before agent implementation.
Is identify-assumptions-existing safe to install?
It is a planning and analysis workflow with no built-in shell or network execution described in the skill—review the Security Audits panel on this page before installing any skill from the registry.
SKILL.md
READMESKILL.md - Identify Assumptions Existing
## Identify Assumptions (Existing Product) Devil's advocate analysis to surface risky assumptions across four risk areas. ### Context You are stress-testing a feature idea for **$ARGUMENTS**. If the user provides files (designs, PRDs, research), read them first. ### Instructions The user will describe their product, objective, market segment, and feature idea. Work through these steps: 1. **Think from three perspectives** about why this feature might fail: - **Product Manager perspective**: Business viability, market fit, strategic alignment - **Designer perspective**: Usability, user experience, adoption barriers - **Engineer perspective**: Technical feasibility, performance, integration challenges 2. **Identify assumptions across four risk areas**: - **Value**: Will it create value for customers? Does it solve a real problem? - **Usability**: Will users figure out how to use it? Is the learning curve acceptable? - **Viability**: Can marketing, sales, finance, and legal support it? - **Feasibility**: Can it be built with existing technology? Are there integration risks? 3. **For each assumption**, note: - What specifically could go wrong - How confident you are (High/Medium/Low) - Suggested way to test it Think step by step. Be thorough but constructive — the goal is to strengthen the idea, not kill it. --- ### Further Reading - [Assumption Prioritization Canvas: How to Identify And Test The Right Assumptions](https://www.productcompass.pm/p/assumption-prioritization-canvas) - [How to Manage Risks as a Product Manager](https://www.productcompass.pm/p/how-to-manage-risks-as-a-product-manager) - [Continuous Product Discovery Masterclass (CPDM)](https://www.productcompass.pm/p/cpdm) (video course)