majestic-product

Diagnose an existing product's growth ceiling, pressure-test a commercial idea, or shape a non-commercial builder project through a structured step-by-step process. Use when the user wants to brainstorm, vet, or diagnose a product or SaaS idea, growth strategy, side project, hackathon, learning project, research tool, or open-source concept.

Write a lightweight feature brief or product decision document that records problem, evidence, options, scope, success measures, risks, and recommendation. Use when early exploration or a product decision needs a compact artifact before a full specification or implementation plan.

Decompose product requirements and feature requests into atomic user stories with testable Gherkin acceptance scenarios, risk-relevant edge coverage, and traceability. Use when drafting ticket-ready stories from approved behavior or auditing and repairing existing stories for compound scope, vague outcomes, missing negative paths, unsupported rules, or broken requirement links.

Design a customer lifecycle retention system with stage outcomes, onboarding, health signals, early warnings, intervention playbooks, and measurement. Use when churn is poorly understood, onboarding underperforms, or teams need proactive retention instrumentation rather than account-by-account sales actions. Not for account-specific commercial motions or for choosing a single top-level product health metric.

Choose and operate one stage-fit product health metric with driver inputs, guardrails, ownership, and a review cadence. Use when teams track too many disconnected metrics, need a growth focus, or must distinguish a useful leading signal from vanity metrics.

Design product pricing and packaging from a value metric, willingness-to-pay evidence, competitive context, costs, and expansion logic. Use when setting or revising prices, tiers, limits, or packaging without inventing precision the evidence cannot support.

Diagnose and repair a stuck, repeatedly reopened, or inconsistently executed cross-functional product decision. Use when product, design, engineering, operations, or leadership disagree about the outcome, evidence, authority, decision method, commitment, or follow-through. Not for interpersonal therapy, performance evaluation, or choosing the product strategy itself.

Plan and synthesize customer interviews, map desirability, viability, and feasibility assumptions, and frame Jobs-to-be-Done. Use when understanding adoption, switching, churn, or prioritizing what remains unknown before defining a solution or validation test.

Prioritize product opportunities and build an outcome-based Now, Next, Later roadmap with explicit evidence, tradeoffs, confidence, and a not-doing list. Use when ranking a backlog or communicating product direction without false precision or fixed-date theater.

Write an evidence-grounded product requirements document with users, scope, requirements, acceptance checks, success measures, risks, and unresolved decisions. Use when an approved product direction needs a PRD for implementation, stakeholder review, or delivery handoff.

Pressure-test demand for a product or idea, diagnose an existing product’s growth ceiling, and define the smallest test for the riskiest assumption. Use when vetting an idea, interrogating weak demand, or choosing proceed, sharpen, or pause before building.

Audit and repair individual requirements and requirement sets without inventing missing decisions. Use when requirements in a PRD, specification, user-story set, acceptance criteria, BRD, FRD, or catalogue need statement-level or set-level review for ambiguity, consistency, traceability, testability, evidence, abstraction fit, or coverage. Not for whole-document or implementation-plan readiness.

Rehearse a difficult product conversation through a bounded simulation, then debrief the user's observable communication choices and prepare a stronger next attempt. Use before or after a conversation with an engineer, designer, executive, customer, or operational stakeholder. Not for predicting what a real person thinks or generating synthetic feedback as if it came from them.

Map an observed operational workflow into actors, work objects, states, handoffs, evidence, burdens, automation choices, control points, and exceptions. Use when customer research, process notes, support evidence, or operator interviews need to become a grounded workflow model and a shortlist of software or AI opportunities. Not for conducting discovery research, validating demand, or writing requirements.