product-management

# Product Management

Turn customer and business evidence into a focused product decision, a coherent
experience, and a learning loop. Treat discovery, scope, quality, distribution,
and post-release behavior as one system rather than separate handoffs.

## Workflow

1. Name the decision and artifact: opportunity assessment, product brief,
   discovery plan, strategy, initial scope, prioritization decision, roadmap,
   quality review, release recommendation, experiment, or post-launch review.
2. Build an evidence register. Separate observed behavior, measured outcomes,
   purchase or usage commitments, customer accounts, stakeholder claims, and
   assumptions. Never invent research, demand, metrics, or customer language.
3. Map the product path:

   ```text
   target situation -> struggle and trigger -> product promise -> first value
                    -> repeated value -> business result -> retention or referral
   ```

   Find the weakest transition or riskiest assumption before proposing work.
4. Load only the matching route:
   - [Discovery and evidence](references/discovery-and-evidence.md) for market
     selection, interviews, observation, Jobs to be Done, validation, and
     service-to-product opportunities.
   - [Strategy and outcomes](references/strategy-and-outcomes.md) for product
     theses, goals, differentiation, economics, strategic choices, and decision
     records.
   - [Scope and prioritization](references/scope-and-prioritization.md) for
     initial releases, feature requests, roadmaps, tradeoffs, and non-goals.
   - [Product quality and delight](references/product-quality-and-delight.md)
     for quality bars, first-use experience, trust, polish, meaningful delight,
     and whole-journey reviews.
   - [Shipping and learning](references/shipping-and-learning.md) for release
     readiness, instrumentation, experiments, post-launch review, and iteration.
   - [Go-to-market handoff](references/go-to-market-handoff.md) when product
     evidence must inform positioning, pricing, launch, channels, or sales.
5. Present options with consequences. Recommend one decision, state the
   assumptions it depends on, and name what would change the recommendation.
6. Define the smallest next action that reduces the most important uncertainty,
   plus an owner, decision window, and keep, change, or stop rule.

## Operating Rules

- Optimize for user progress and business viability, not feature volume,
  technical novelty, stakeholder enthusiasm, or roadmap completion.
- Ask what changed in the customer's situation, what they tried before, and why
  they acted now. A feature request is evidence of a situation, not an automatic
  specification.
- Prefer specific past behavior and meaningful commitment over hypothetical
  intent. Treat sign-ups, compliments, traffic, and survey votes as weaker than
  repeated use, switching behavior, payment, or operational adoption.
- Reduce scope before reducing the critical-path quality bar. A narrow,
  coherent product that completes one job is a stronger first release than a
  broad collection of partially working features.
- Define “good enough” by audience, risk, promise, reversibility, and business
  stage. Do not use perfectionism to avoid learning or speed to excuse broken
  trust, accessibility, privacy, reliability, or core usability.
- Quality is perceived as the aggregate of details. Prioritize clarity,
  behavior, responsiveness, recovery, and consistency before ornamental
  novelty.
- Treat product quality as a condition for retention and recommendation, not as
  a substitute for distribution. A good launch cannot rescue an irrelevant
  product, and a good product does not guarantee discovery.
- Ground AI-assisted product work in real evidence and accountable judgment.
  Use AI to expose options and missing questions, never to synthesize fictional
  customer certainty or generic market strategy.
- Keep platform tactics, channel claims, benchmark numbers, pricing formulas,
  and launch cadences testable and time-bound. Verify volatile guidance before
  making it a requirement.

## Default Deliverable

For a broad product decision, return:

1. Decision, time horizon, and accountable owner
2. Evidence register and important unknowns
3. Target user, situation, struggle, trigger, alternatives, and desired progress
4. Product thesis, business constraint, and distribution constraint
5. Options, tradeoffs, recommendation, and non-goals
6. Smallest coherent scope and explicit quality bar
7. Go-to-market and operational handoffs
8. Experiment, instrumentation, decision window, and stop or keep criteria

## Related Skills

- Use `product-naming` after the product thesis, target user, and differentiation
  are stable enough to support a naming brief.
- Use `customer-research` from the separately managed DALO `marketingskills`
  catalog to execute a focused research program; use this skill to frame the
  decision and synthesize the evidence.
- Use `product-marketing`, `marketing-plan`, `launch`, and `pricing` from that
  catalog for their dedicated deliverables after the product brief is stable.
- Use `linkedin-social-selling` when LinkedIn is an evidence-backed acquisition
  or conversation channel, and `linkedin-posts` for post-only work.
- Use `effective-web` to design, implement, and verify the browser experience
  after product outcomes, scope, and quality bar are decided.
- Use `web-legal-compliance` for privacy, consent, tracking, testimonials,
  direct marketing, and jurisdiction-specific legal requirements.
- Use `decision-records` to preserve durable product decisions, their
  tradeoffs, and the conditions that should reopen them.