<!-- Free part of the ihumane Product thinking module, generated from pro/product-thinking/ by scripts/build-free.js. Edit pro/product-thinking/, not this file. -->

# 4 · Check: the right thing, for the right person

The UI review (UI design, `5-review.md`) asks whether what you built is well
made. This part asks whether it's the right thing. Do it before you say done
on any job sized **full** in `START.md`, and keep the reasoning where the
next session will find it.

---

### K1 · Walk it through as the person
**Rule:** Before saying done, use what you built as the person from W1
would, in their situation (W2), with realistic content. Start from nothing,
do the whole job, and stop where they'd stop. Note every point where they'd
be confused, wait, or need you to explain something. Fix those first.
**Why:** You know how it's meant to work. They don't, and they won't read
instructions. Walking it through as them is the closest you can get to
watching them use it.
**Agent trap:** testing features one at a time ("create works, edit works,
delete works") instead of doing the job. Every part passes, and the job
still takes eleven steps and a guess.
**Check:** did you do the full job end to end, as the person? How many steps
did it take, and could any of them go?

> **In ihumane Pro** (https://ihumane.ai/#pricing):
> - K2 · Hold it against the problem, the success line, and today
> - K3 · Write the product brief where the next session finds it
> - K4 · Report the product decisions, not only the build

## Template: PRODUCT.md

Copy this into `PRODUCT.md` and fill it in. Mark each line **known** (they
said it, or you found it) or **assumed**.

```markdown
# PRODUCT.md

> Read this before adding or removing features. Update it when who it's for,
> the problem or the scope changes.
> Last updated: <date> by <agent/human>

## For
- Person: <one person, one situation: role, device, how often, what they're in the middle of> (known | assumed)
- Not for: <who this version deliberately doesn't serve>
- Who decides / pays, if different: <person, and what they care about>

## Job
When <situation>, I want to <make progress>, so I can <outcome>.

## Today
- They use: <the current way, including "nothing">
- It does well: <what we must also do>
- Switching costs: <data to bring over, habits, other people>

## Problem
<What goes wrong today, for whom, how often.>

## Different because
<One sentence. A competitor couldn't use it unchanged.>

## Success
- Looks like: <what's noticeably different when it works>
- We'd notice by: <a number they track, a complaint that stops, a step they skip>

## This version
- Core loop: <the shortest path from situation to job done>
- Next (ranked): <features for later, in order>

## Left out on purpose
| Feature | Why not now | Would add when |
|---------|-------------|----------------|
| <feature> | <reason> | <what would change that> |

## Open questions
- <questions for the person, with the default we're using meanwhile>
```

---

## Check

- [ ] You did the whole job as the person, from an empty start, with realistic content.
- [ ] You answered the three K2 questions, and reported any "no" or "unsure".
- [ ] `PRODUCT.md` (or the project's existing notes) holds the current brief, with known and assumed marked.
- [ ] `DESIGN.md`, if it exists, agrees with the brief.
- [ ] Your report names who it's for, what's left out and why, and what you assumed.
- [ ] At most one question at the end.
