OpenClaw Skillv1.0.0

Product Manager

Ivรกnby Ivรกn
Deploy on EasyClawdfrom $14.9/mo

Build products users love with discovery, prioritization, roadmapping, and cross-functional leadership.

How to use this skill

OpenClaw skills run inside an OpenClaw container. EasyClawd deploys and manages yours โ€” no server setup needed.

  1. Sign up on EasyClawd (2 minutes)
  2. Connect your Telegram bot
  3. Install Product Manager from the skills panel
Get started โ€” from $14.9/mo
5stars
2,179downloads
13installs
0comments
1versions

Latest Changelog

Initial release

Tags

latest: 1.0.0

Skill Documentation

---
name: Product Manager
description: Build products users love with discovery, prioritization, roadmapping, and cross-functional leadership.
metadata: {"clawdbot":{"emoji":"๐ŸŽฏ","os":["linux","darwin","win32"]}}
---

# Product Management Rules

## Discovery
- Talk to users weekly โ€” not just at project kickoff
- Watch behavior, don't just collect opinions โ€” users say one thing, do another
- Problem validation before solution validation โ€” are we solving the right thing?
- Jobs to be done: what's the user trying to accomplish?
- Competitors show what's possible, not what to copy

## Prioritization
- Impact vs effort is a starting point, not the answer
- Say no more than yes โ€” focus is a feature
- Urgent vs important: stakeholder pressure isn't priority
- Stack rank ruthlessly โ€” "everything is P1" means nothing is
- Revisit priorities when context changes โ€” quarterly at minimum

## Roadmapping
- Outcomes over outputs โ€” what will change, not what we'll build
- Time horizons: now (committed), next (planned), later (possible)
- Communicate uncertainty honestly โ€” roadmaps aren't promises
- Dependencies surfaced early โ€” blocked work wastes everyone's time
- Update when reality changes โ€” stale roadmaps destroy trust

## Requirements
- User stories: who, what, why โ€” not how
- Acceptance criteria define done โ€” ambiguity creates rework
- Edge cases addressed upfront โ€” not discovered in QA
- Scope creep is the enemy โ€” good enough now beats perfect later
- Technical constraints are real โ€” work with engineering, not around them

## Working with Engineering
- Context over directives โ€” explain why, not just what
- Tradeoffs are collaborative decisions
- Spec before sprint, not during โ€” no designing on the fly
- Protect focus time โ€” meetings kill flow
- Trust their estimates, push back on scope not time

## Working with Design
- Research together, don't hand off briefs
- Critique the work, not the designer
- Design reviews with users, not just stakeholders
- Mobile and edge cases early โ€” not afterthoughts
- Design system enables speed โ€” support it

## Stakeholder Management
- Regular updates prevent surprise requests
- Data calms opinion battles
- Explain trade-offs, don't just defend decisions
- Feedback channels prevent end-runs โ€” make input easy
- Executive sponsors for big initiatives

## Metrics
- One north star metric, 2-3 supporting
- Leading indicators for early signal โ€” don't wait for lagging
- Dashboards should prompt questions, not just display numbers
- Vanity metrics feel good, don't drive decisions
- A/B test when data beats intuition

## Launch
- Soft launch catches problems before scale
- Success criteria defined before launch โ€” not after
- Rollback plan before rollout
- Cross-functional checklist: docs, support, marketing
- Post-launch review: what worked, what didn't

## Common Mistakes
- Feature factory: shipping without learning
- Overspeccing: killing engineering autonomy
- Consensus seeking: decisions by committee
- Ignoring qualitative: data alone misses why
- Roadmap as backlog: detail everything, commit nothing
Security scan, version history, and community comments: view on ClawHub