agentsclimarketplace

Product management

Skill sebastian-software/skills.sebastian-software.com/skills/product-management

Practice-built skills that give AI agents practical judgment for product, web, engineering, delivery, go-to-market, communication, and compliance work.

Install
npx -y skills add sebastian-software/skills.sebastian-software.com --skill product-management

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Plan, review, and improve evidence-led product decisions for software and digital products. Use for product discovery and research to decide what or whether to build, product briefs and evidence audits, customer problems and Jobs to be Done, product strategy, outcomes, MVP or initial scope, product operating models and empowered teams, continuous discovery and delivery, AI-assisted idea exploration, prioritization, roadmaps, feature requests, quality bars, product delight, release decisions, product experiments, adoption and retention learning, or transitions from consulting and services to repeatable products. Use when deciding what to build, why, for whom, how the team should explore it, or whether a product artifact or product is ready to act on, especially when product, design, engineering, and go-to-market evidence must stay aligned.

SKILL.md

8.3 KB, ~1.5k tokens by cl100k_base, as published. Nobody here has run it

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, evidence audit, 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:

    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 or routes:

    • Evidence review when reviewing an existing artifact, recommendation, or claim set for decision readiness. Also load the domain route that owns the artifact's subject.
    • Review modes after the evidence review when the artifact supports a product decision, go-to-market claim set, or launch readiness decision. Also load the domain routes named by the selected mode.
    • Review calibration for repeated or high-stakes reviews, behavioral case design, counterfactual checks, and post-decision outcome learning.
    • Discovery and evidence for market selection, interviews, observation, Jobs to be Done, validation, and service-to-product opportunities.
    • Strategy and outcomes for product theses, goals, differentiation, economics, strategic choices, and decision records.
    • Product operating model for empowered cross-functional teams, discovery and delivery responsibilities, high-integrity commitments, AI-era exploration tempo, and organizational change away from feature-factory behavior.
    • Scope and prioritization for initial releases, feature requests, roadmaps, tradeoffs, and non-goals.
    • Product quality and delight for quality bars, first-use experience, trust, polish, meaningful delight, and whole-journey reviews.
    • Shipping and learning for release readiness, instrumentation, experiments, post-launch review, and iteration.
    • Go-to-market handoff 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 many materially different options, assumptions, and missing questions, never to synthesize fictional customer certainty or generic market strategy. Cheap generation should increase exploration breadth, not lower the evidence required for consequential commitments.
  • When reviewing an existing artifact, inventory its claims and supplied evidence before applying preferred product frameworks. Do not let a strong template manufacture support.
  • When learning from a later outcome, preserve the original artifact, evidence cutoff, review, and expected signals. Do not turn hindsight into evidence that was unavailable at decision time.
  • 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

For an existing artifact or decision-readiness audit, use the deliverable in Evidence review instead.

Routing Boundaries

  • Use product-naming after the product thesis, target user, and differentiation are stable enough to support a naming brief.
  • Use this skill to frame the product decision and synthesize supplied customer evidence. Recruitment, fieldwork, participant operations, and execution of a focused research program remain outside its scope.
  • Carry stable product evidence into a bounded go-to-market handoff. Full positioning systems, marketing plans, launch execution, and pricing research remain outside this skill's scope.
  • Use linkedin-social-selling when LinkedIn is an evidence-backed acquisition or conversation channel, and linkedin-posts for post-only work.
  • Use product-design to research, frame, model, structure, and prototype the experience after product direction is stable enough to explore.
  • Use effective-web to specify, implement, and verify the browser experience once the design direction and interaction model are ready.
  • 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.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.