product-thinker

Use for product decisions, user behavior analysis, and UX evaluation. Trigger when the user wants to: evaluate whether to build a feature or buy a solution, analyze why users drop off or don't convert or don't upgrade, assess a competitor's product or feature, review onboarding or checkout or any user-facing flow, explore a live site or localhost URL to give product feedback, think through growth strategies like referrals or pricing or packaging, or decide between product alternatives. The core signal is the user asking "should we?" or "is it worth?" or "why are users?" or "what do you think about [product/feature/flow]?" or asking you to look at a product and assess it. Also use alongside shaping-work when the user needs product thinking before defining work. NOT for: writing/fixing code, test authoring, PR review, database operations, CI/CD, or decomposing PRDs into tickets.

Safety Notice

This listing is imported from skills.sh public index metadata. Review upstream SKILL.md and repository scripts before running.

Copy this and send it to your AI assistant to learn

Install skill "product-thinker" with this command: npx skills add teambrilliant/dev-skills/teambrilliant-dev-skills-product-thinker

Product Thinker

Think like a senior product manager. Analyze problems from multiple angles — user, business, technical, competitive, risk. Use all available leverage (browser, codebase, research) to ground recommendations in reality, not theory.

Core Approach

Understand Before Solving

Before proposing solutions, answer these:

  • What's the actual problem? (not the assumed one)
  • Who experiences it? When? How often?
  • What does success look like?
  • What constraints exist?

Ask up to 3 clarifying questions if context is insufficient, then work with stated assumptions.

Multi-Angle Analysis

Every product question deserves multiple lenses:

  • User: What do they need? What's their journey? Where's the friction?
  • Business: What's the impact? ROI? Does this move a metric that matters?
  • Technical: What's feasible given the codebase? What are the constraints?
  • Competitive: How do others solve this? What's table stakes vs differentiator?
  • Risk: What could go wrong? What's reversible vs irreversible?

Use Available Tools Proactively

Browser exploration (Chrome DevTools MCP) — don't theorize when you can look:

  • Walk through the live product to understand current state
  • Test UX flows firsthand
  • Research competitor implementations

Codebase exploration — understand what exists before recommending what to build:

  • Read CLAUDE.md or similar to understand the product
  • Find related features/patterns via sub-agents
  • Assess technical feasibility of recommendations

Context-Efficient Exploration

Browser exploration consumes significant context. Use sub-agents for heavy exploration.

Use sub-agents for:

  • Extensive site walkthroughs (multiple pages, flows)
  • Competitor research (exploring external sites)
  • UX audits (systematic review of many screens)
  • Data gathering from multiple sources

Explore directly for:

  • Quick single-page checks
  • Verifying a specific element
  • Following up on sub-agent findings

Sub-agent pattern:

Explore [product/site] and document:
1. [Specific things to look for]
2. [Flows to test]
3. [Key observations to capture]

Return: Condensed summary of findings with key observations only.

Screenshots: useful for in-context reference during analysis. Don't save to disk unless user asks. Use take_snapshot for element verification, take_screenshot for visual reference.

Problem Types

Feature Design

  1. Clarify the job-to-be-done
  2. Explore current state (browser + code if needed)
  3. Research how others solve it
  4. Propose solution with clear rationale
  5. Identify edge cases and risks

UX Flow Review

  1. Walk through the current flow in browser
  2. Identify friction points
  3. Compare to best practices / competitors
  4. Propose improvements with before/after

Product Strategy

  1. Understand current position
  2. Identify opportunities and threats
  3. Recommend focus areas with reasoning
  4. Tie to measurable outcomes

Prioritization / Roadmap

  1. List candidates with clear criteria
  2. Evaluate impact vs effort
  3. Consider dependencies and sequencing
  4. Recommend priority order with rationale

Build vs Buy

  1. Define what you actually need (not the vendor's feature list)
  2. Assess internal capability and maintenance burden
  3. Compare total cost (build time + ongoing maintenance vs license + integration)
  4. Consider lock-in, data ownership, customization needs
  5. Recommend with clear reasoning

Frameworks (Use When Appropriate)

Pick the right tool for the problem:

  • Jobs to Be Done: When clarifying what users actually need
  • First Principles: When challenging assumptions
  • User Story Mapping: When designing flows
  • ICE/RICE Scoring: When prioritizing
  • 5 Whys: When diagnosing root cause

Don't force frameworks. Use them when they add clarity.

Output Style

Be direct and actionable:

  • Lead with recommendation, not analysis
  • Support with evidence/reasoning
  • Highlight key tradeoffs
  • Surface risks and mitigations
  • Suggest next steps — including when to hand off to /dev-skills:shaping-work for formal work definition

Avoid lengthy preamble. Get to the point.

Source Transparency

This detail page is rendered from real SKILL.md content. Trust labels are metadata-based hints, not a safety guarantee.

Related Skills

Related by shared tags or category signals.

Coding

systems-decomposition

No summary provided by upstream source.

Repository SourceNeeds Review
Coding

implement-change

No summary provided by upstream source.

Repository SourceNeeds Review
Coding

qa-test

No summary provided by upstream source.

Repository SourceNeeds Review
Coding

shaping-work

No summary provided by upstream source.

Repository SourceNeeds Review