Product strategy office hours

Skill wfprieto/wcbs-build-kit/skills/product-strategy-office-hours

Use when a request needs product strategy, founder/CEO-style decision clarity, premise challenge, target-user sharpening, alternatives generation, opportunity sizing, or pre-build alignment before APIVR planning. Especially useful before building features, products, landing pages, workflows, or strategic recommendations where the problem, buyer, user, urgency, or success metric is not yet crisp.From its SKILL.md

Install

npx -y skills add wfprieto/wcbs-build-kit --skill product-strategy-office-hours

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

3 stars3 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.

SKILL.md

3.5 KB, as published. Nobody here has run it

Product Strategy Office Hours

Use this skill during APIVR Phase 1 Audit and Phase 2 Plan when the build decision itself needs pressure-testing.

<HARD-GATE> Do not let product strategy become a brainstorm pile. Convert ambiguity into decisions, non-goals, evidence needs, and acceptance criteria before implementation. </HARD-GATE>

APIVR Integration

Phase 1 Audit: identify user, buyer, pain, urgency, current workaround, promise, risk, and missing evidence.
Phase 2 Plan: convert the decision into scope, non-goals, vertical slices, success metrics, and proof required.
Phase 3 Implement: build only the approved slice.
Phase 4-6: verify the user outcome, commercial claim, and evidence state.

Decision Flow

flowchart TD
  A["Product or strategy work requested"] --> B{"Is the user, buyer, pain, and desired outcome explicit?"}
  B -- "No" --> C["Run one-question-at-a-time alignment"]
  B -- "Yes" --> D{"Does the premise have evidence?"}
  C --> D
  D -- "No" --> E["Generate alternatives and mark evidence Unknown/Likely"]
  D -- "Yes" --> F{"Can scope be sliced into one verifiable outcome?"}
  E --> F
  F -- "No" --> G["Use product requirements and issue slicing"]
  F -- "Yes" --> H["Write APIVR plan with success metric and non-goals"]

Operating Protocol

State the current premise in one sentence.
Ask or answer one decision-tree question at a time.
Identify the highest-risk assumption.
Generate at least two credible alternatives when the first idea is not clearly dominant.
Select the smallest vertical slice that can prove or disprove the premise.
Convert the result into acceptance criteria and evidence states.

Good / Bad

<Bad> Build the dashboard because the user asked for a dashboard. </Bad> <Good> Clarify who uses the dashboard, which decision it changes, what data must be trusted, what export or alert replaces manual work, and which one metric proves the dashboard is useful. </Good>

Worked Example

Scenario: A founder asks for a lead-scoring dashboard.

Premise: sales needs a faster way to decide which leads deserve same-day outreach.
Highest-risk assumption: the existing CRM data actually predicts urgency.
Alternative considered: daily prioritized email instead of a dashboard.
APIVR decision: Standard tier because business workflow and reporting are affected.
Plan output: one lead-priority view, one export, one evidence check against recent won/lost leads.
Verdict rule: PASS only when the user decision, data source, and verification result are at least Verified or explicitly risk-accepted.