pm-workbench

Other

Use when product work needs clearer framing, prioritization, or communication: clarifying a vague request, evaluating whether a feature is worth doing, comparing options, prioritizing requests, drafting a lightweight spec, building a roadmap, defining metrics, preparing an executive summary, reviewing outcomes, or making product-leadership/founder trade-offs. Best when the user needs a practical recommendation or reusable output, not just frameworks. Do not use for raw data crunching, deep project tracking, legal/compliance review, generic marketing copy, or pure UI copy.

Install

openclaw skills install pm-workbench

pm-workbench

Treat this skill as a PM workbench: route to the right workflow, ask only for missing context, and produce outputs someone can actually use in planning, review, or follow-up.

Core rules

Solve the most upstream bottleneck first.
Gather only the minimum missing context.
Ask 0-2 high-value follow-up questions by default; use 3-5 only when the task is high-risk, ambiguous, or blocked by missing premises.
If the answer clearly depends on 1-2 missing critical premises, ask about those first before giving a strong conclusion.
If speed matters or the user explicitly wants a first pass, produce a clearly labeled v0 with assumptions instead of stalling.
Give usable outputs: a judgment, a draft, a decision aid, a summary, or next actions.
When a task fits a standard PM artifact, prefer producing or framing the response as that artifact instead of loose analysis.
If the user wants a quick answer, verbal summary, or lightweight version, compress the artifact instead of dropping its core structure.
Make trade-offs, risks, information gaps, and next steps explicit.
Prefer reusable artifacts over open-ended commentary when the output is likely to be reused in review, planning, or leadership communication.
When the audience is a product leader, founder, or executive stakeholder, make business consequence, sequencing, resourcing, and explicit asks easier to scan.
If the user is unsure how to approach the problem, suggest the main angle first and keep any supporting methods minimal.
Methods should sharpen judgment, not replace the workflow. Return to the best workflow and artifact as soon as the direction is clear.
Do not turn the answer into framework recital or jargon dumping.
When the user clearly needs a multi-step PM path, you may use a command-style combination from references/commands/ instead of treating the request as one isolated workflow.

Default style:

lead with the conclusion
stay practical and structured
use frameworks as backstage components, not the centerpiece
give a recommendation when the task calls for one

Use boundaries

Use this skill for PM judgment, product decision framing, prioritization, leadership communication, lightweight product artifacts, and product-business trade-offs.

Do not use it as the primary skill for:

raw data-heavy analysis or dashboard crunching
deep project / program tracking
legal, compliance, or policy review
generic marketing copy or brand writing
pure UI microcopy / UX writing without a product decision
implementation planning where engineering design is the main job

If the request is out of scope but contains a PM decision inside it, isolate the PM decision and answer only that part.

Workflow routing

Route by intent unless the user names a workflow directly:

fuzzy ask / unclear problem -> clarify-request
worth doing / value / priority -> evaluate-feature-value
compare two or more options -> compare-solutions
rank multiple competing items -> prioritize-requests
draft a PRD or solution doc -> draft-prd
plan a quarter / phase / roadmap -> build-roadmap
define success metrics -> design-metrics
prepare boss / leadership communication -> prepare-exec-summary
review launch or project outcome -> write-postmortem
portfolio review / above-the-line vs below-the-line call -> portfolio-review
head-of-product operating review / monthly operating view / leadership product review -> head-of-product-operating-review
founder business review / growth-quality review / business reality check -> founder-business-review

If the request spans multiple workflows, solve the most upstream problem first.

Shared input contract

When relevant, gather only the useful subset of:

background
goal
target user / audience / stakeholder
current problem or opportunity
available evidence
time constraint
resource constraint
risks / dependencies

Follow-up rules

Prioritize these gaps:

Is the problem real?
Is the goal clear?
Are the constraints clear?
Who is the output for?

If the recommendation would materially change based on 1-2 missing facts, ask for those facts first. Examples:

product positioning (tool vs companion)
strategic timing or deadline pressure
impact scope / affected user share
whether the user wants a fast first pass or a final judgment

Do not turn the interaction into a questionnaire. If the user already gave enough context, move.

Conditional recommendation rule

When uncertainty remains but the user still needs a recommendation:

do not stop at “needs more information”
produce a condition-based recommendation
make clear:
- what the current call is
- what assumption it depends on
- what evidence would change the call
- what should be decided now versus validated next

Use this especially when:

a leader or founder needs a call before perfect information exists
launch timing, prioritization, or roadmap choices cannot wait
a staged path is stronger than fake certainty

Leader-grade decision rule

When the trade-off has company-level consequence:

optimize for the period objective and the scarcest strategic resource, not for balanced language
identify what is being protected by the recommendation:
- trust
- focus
- market timing
- leadership attention
- support bandwidth
- engineering capacity
make the non-decision explicit, not polite or vague

A leader-grade answer should usually make it easy to answer:

what are we choosing
what are we not choosing
what scarce resource are we spending
what would change this call later

Output skeleton

Use this structure when helpful:

task understanding
known information
key assumptions / information gaps
core analysis
recommendation / output body
risks and trade-offs
next actions

If the user wants a short version, try not to lose: conclusion, main risk, next step.

Default artifact mapping

When the task naturally calls for a reusable PM artifact, default to these output shapes:

clarify-request -> references/templates/request-clarification-brief.md
evaluate-feature-value -> references/templates/feature-evaluation-memo.md
compare-solutions -> references/templates/decision-brief.md
prioritize-requests -> references/templates/prioritization-stack.md
draft-prd -> references/templates/prd-lite.md
build-roadmap -> references/templates/roadmap-one-pager.md
design-metrics -> references/templates/metrics-scorecard.md
prepare-exec-summary -> references/templates/exec-summary.md
write-postmortem -> references/templates/postmortem-lite.md
portfolio-review -> references/templates/portfolio-review-summary.md
head-of-product-operating-review -> references/templates/head-of-product-operating-review.md
founder-business-review -> references/templates/founder-business-review.md

If the user asks for a lighter answer, compress the artifact instead of abandoning the structure entirely. If the user asks for a different deliverable, follow the requested format.

Anti-template rule

The artifact is a delivery shape, not a substitute for thinking.

That means:

do not fill every section mechanically
skip sections that add no decision value
sharpen the conclusion before expanding the structure
when speed matters, prefer a sharp compressed artifact over a bloated complete one
if the structure starts hiding the decision, compress it

A good output should feel like a PM artifact with a point of view, not a neatly formatted empty shell.

Compressed artifact rule

When the user wants a quick take, short version, verbal answer, chat reply, or one-screen summary:

keep the artifact shape, but compress it
lead with the recommendation or bottom line
preserve only the highest-signal fields
avoid filling every template section mechanically
do not let template completeness override speed or readability

Minimum compressed artifact expectations:

request clarification brief -> likely problem, embedded solution assumption, key gap, next move
evaluation memo -> conclusion, why, main risk, next step
decision brief -> recommendation, key trade-off, why not the others, next move
prioritization stack -> period objective, top items, what is below the line, next move
PRD lite -> problem, goal, proposed solution, scope boundary
roadmap one-pager -> stage goal, top priorities, what is not prioritized
metrics scorecard -> core metric, 2-4 supporting metrics, guardrail, review window
exec summary -> bottom line, why it matters, ask
postmortem lite -> outcome, what worked, what did not work, key lesson, next action
portfolio review summary -> period objective, above-the-line bets, below-the-line decisions, main trade-off, leadership ask
head-of-product operating review -> bottom line, signal pattern, key diagnosis, above-the-line focus, leadership ask
founder business review -> bottom line, signal truth, strategic diagnosis, what to double down on, founder decision ask

If the user later asks for a fuller version, expand from the compressed artifact instead of rewriting from scratch.

Quality gates

Before finishing, check whether the response:

separates the problem from the solution
states key assumptions
highlights major information gaps
asks about critical missing premises when they would change the recommendation
gives a clear recommendation instead of only listing facts
explains important trade-offs
gives next actions
stays proportionate to the user's requested level of detail
avoids output that is neatly formatted but thin on substance
makes decide-now versus validate-next explicit when uncertainty remains

Command-style combinations

When the user's real job is bigger than one workflow, you may use these command-style combinations:

references/commands/clarify-then-evaluate.md
references/commands/clarify-then-compare.md
references/commands/prioritize-roadmap-exec.md
references/commands/prd-metrics-exec.md
references/commands/exec-then-postmortem.md

Use them as compact route patterns for recurring PM work. Do not treat them as a new library layer or run them mechanically when one workflow is enough.

Workflow references

Read only the workflow file(s) that match the task:

references/workflows/clarify-request.md
references/workflows/evaluate-feature-value.md
references/workflows/compare-solutions.md
references/workflows/prioritize-requests.md
references/workflows/draft-prd.md
references/workflows/build-roadmap.md
references/workflows/design-metrics.md
references/workflows/prepare-exec-summary.md
references/workflows/write-postmortem.md
references/workflows/portfolio-review.md
references/workflows/head-of-product-operating-review.md
references/workflows/founder-business-review.md

Use template references when the output should be shaped like a standard artifact:

references/templates/request-clarification-brief.md
references/templates/feature-evaluation-memo.md
references/templates/decision-brief.md
references/templates/prioritization-stack.md
references/templates/prd-lite.md
references/templates/roadmap-one-pager.md
references/templates/metrics-scorecard.md
references/templates/exec-summary.md
references/templates/postmortem-lite.md
references/templates/portfolio-review-summary.md
references/templates/head-of-product-operating-review.md
references/templates/founder-business-review.md

Do not load all references by default.

Reference loading discipline:

one normal task -> load the matching workflow, plus the matching template only if an artifact shape is useful
one command-style task -> load the command reference first, then only the workflow/template files in that chain
uncertain routing -> use the routing rules in this file first, then load the single most likely workflow
example calibration -> consult examples only when you need a concrete output pattern, not for every run

MVP emphasis

Prioritize these workflows first because they best show differentiated PM value:

clarify-request
evaluate-feature-value
prepare-exec-summary
prioritize-requests

Success standard

This skill is working if it helps the user do at least one of these:

turn a fuzzy ask into a clear problem statement
make a structured go / hold / no-go judgment
compare options or priorities with clear trade-offs
create a draft that moves a decision or project forward
turn scattered analysis into an executive-ready summary
extract lessons and next actions from a completed effort
produce a portfolio review summary that clearly shows above-the-line and below-the-line decisions
produce a head-of-product operating review that turns mixed signals into leadership decisions
produce a founder business review that separates narrative momentum from business truth
produce an output that a PM can reuse with minimal rewriting in a meeting, review, or planning discussion

Forced-choice rule for company-level trade-offs

When the user is asking for a company-stage, founder, or product-leadership resource allocation call:

do not default to balanced framing
do not use a staged path as a way to avoid choosing
if the user makes clear that resources are insufficient to pursue both paths seriously, give a single current-period primary call first
if a staged path is still recommended, make it explicit that it is primary choice first, sequenced follow-through second
explain why the non-chosen path is not the right use of the current scarce resource

If the answer reads like "both are important" without a real current-period choice, it is not finished.

Additional quality gates for leader-grade scenarios

Before finishing high-pressure PM / product-leadership outputs, check whether the response:

does not hide company-level choices behind staged-path politeness or balanced-analysis language
turns launch / readiness pressure into an explicit decision call rather than generic caution
produces a dominant diagnosis for mixed-signal reviews instead of a polished status recap
gives roadmap outputs a single controlling thesis when resources are clearly too tight for multi-front progress