# Example 22 — Command path: clarify -> evaluate

## Why this example exists

A lot of real PM work does not begin with a clean feature evaluation.
It begins with a half-formed ask that needs clarification **before** value judgment is credible.

This example shows how a command-style path is useful when one workflow is not enough.

## Command used

- `clarify-then-evaluate`

## Scene

A growth stakeholder wants a new AI-generated “daily momentum card” feature inside a collaboration product.
They believe it will increase daily engagement and sharing.
The PM suspects it may be attention-grabbing but weak on real retention value.

## Raw input

> Growth wants us to ship a daily AI momentum card that summarizes each user’s workday and gives them a motivational nudge. They think it could improve daily engagement and make the product feel more alive. I’m not sure whether this solves a real problem or just sounds fun. Help me think through it.

## Why one workflow is not enough

If you jump straight into `evaluate-feature-value`, you risk evaluating a fuzzy object.
The real questions still need to be clarified first:

- what problem is this supposed to solve
- who actually benefits
- whether “engagement” here means habit, delight, sharing, or retention support

## Step 1 — Clarify the ask

### What strong behavior looks like

A strong first pass should do things like:

- separate the visible idea from the underlying job
- ask whether the target is retention, reactivation, delight, or product storytelling
- check whether the team is solving a genuine user need or inventing ambient activity
- avoid brainstorming card formats too early

### Useful clarification outcome

By the end of this step, the PM should be able to restate the situation more clearly:

- this is **not yet** a feature request with proven value
- it is a hypothesis about increasing return frequency through a lightweight emotional or reflective touchpoint
- the key uncertainty is whether users actually want this inside the product, or whether it distracts from more meaningful workflow value

## Step 2 — Evaluate whether it is worth doing

### What strong behavior looks like

Once the ask is clarified, the next pass should evaluate:

- user value: does this solve a real recurring need, or just create novelty
- business value: does it support retention or differentiation in a meaningful way
- strategic fit: does it help the current period goal, or steal time from core product work
- opportunity cost: what gets displaced if this gets a slot

### Strong recommendation shape

A good evaluation output would likely land somewhere like:

- **current call:** hold or small experiment, not full build
- **why:** the concept may create momentary delight, but current evidence for meaningful retention lift is weak
- **main risk:** it consumes product attention while the team still has stronger core retention work available
- **next move:** if stakeholders care a lot, test it as a low-cost experiment rather than a roadmap priority

## Why this command path matters

This path shows a specific `pm-workbench` advantage over generic AI:

- it does **not** treat a vivid idea as a stable product problem
- it clarifies the real evaluation object first
- then it makes a sharper go / hold / experiment call

## Suggested final output shape

A compact package from this command path should leave the PM with:

1. a short Request Clarification Brief
2. a Feature Evaluation Memo
3. a one-paragraph stakeholder-ready recommendation

## What this proves about the workbench

The point is not that `pm-workbench` can do two steps instead of one.
The point is that it follows the more trustworthy PM sequence:

**clarify what we are really talking about -> then judge whether it deserves real capacity**
