# ihumane · Product thinking · v0.1 You are an agent about to build a product or a feature. This module is about the decisions that come before the design and the code: who it's for, what problem it solves, and what not to build. It takes what people wrote for each other about product work (jobs to be done, user research, product management) and rewrites it for how agents actually work and fail. Read this file fully. Read the other files when the steps below tell you to. --- ## Why this exists You're fast and willing. Given a request, you build it: all of it, plus the things products like it usually have. That gives four failures: 1. **Built for no one.** The request didn't say who it's for, so you built for "users", a person who doesn't exist. It fits nobody well. 2. **The request, not the problem.** You built the feature as described, perfectly, and the problem behind it is still there. 3. **Too much, too thin.** Every feature mentioned, plus search, settings and a login, each about 70% done. The one thing that mattered is no better than the extras, and nothing says what was left out on purpose. 4. **Invented facts.** Personas, quotes, statistics and market claims that sound right and came from nowhere. A product person's main job is deciding what not to build, for whom. You rarely do that unless something makes you. This module is that something. --- ## Size the job first | Size | Looks like | Do | |---|---|---| | **Not product work** | A bug fix, a refactor, a dependency update, a change that doesn't alter what people can do | Skip this module. | | **Small** | A change to an existing product: one new field, a tweak to a flow, a small addition | Read `PRODUCT.md` if it exists. Write a two-line check: **For:** who this change helps · **Problem:** what it fixes for them. If the change goes against `PRODUCT.md` (a feature left out on purpose, a different user), say so once, in one line. Ask **0** questions unless a wrong guess means redoing the work. Build. | | **Full** | A new product, a new feature, a prototype someone will try or show, a rebuild | Every step below. | If unsure, treat it as small, and say in your report that a full pass would help before building more. --- ## The workflow (full pass) | Step | What you do | File | |------|-------------|------| | 0. Remember | Look for `PRODUCT.md` (and `DESIGN.md`). If it exists, read it and follow it. | `4-check.md` K3 | | 1. Who | One person in one situation, the job they're hiring it for, what they use today. | `1-who.md` | | 2. Problem | The problem behind the request, what success looks like, the one idea that makes it different. | `2-problem.md` | | 3. Scope | The smallest thing that does the job end to end. Rank the rest. Decide what to leave out. | `3-scope.md` | | 4. Say it back | Write the six lines below before building. | here | | 5. Build | For anything with a screen, the UI design module starts here. Its brief takes **who** and **one job** from this module. | `ui-design/START.md` | | 6. Check | Walk it through as the person; hold it against the problem. | `4-check.md` | | 7. Remember | Create or update `PRODUCT.md`. | `4-check.md` K3 | **Questions:** collect what you can't find or infer from steps 1–3 into one message: at most **3** questions, each with your default (working with your human, Q2). This is the same budget as the UI brief, not a second one. When you must choose, ask in this order: who it's for, what success looks like, then which features come first. ### Say it back Before building, write this back to the person. It's where they catch a wrong guess about their own users before it costs anything (U2). ``` For: . Not for: . Problem: . Today they use . Success: . Building: . Leaving out: . Assumed: . ``` --- ## The parts | Part | Answers | Rules | File | |------|---------|-------|------| | Who | Whose life is this meant to change, and how do they cope today? | W1–W5 | `1-who.md` | | Problem | What's wrong, what does better look like, why this and not something else? | P1–P4 | `2-problem.md` | | Scope | What goes in this version, and what deliberately doesn't? | S1–S7 | `3-scope.md` | | Check | Does it solve the problem for the person? Is the reasoning saved? | K1–K4 | `4-check.md` | Every rule uses the same fields as the other ihumane modules: **Rule** (what to do), **Why** (what happens to a real person if you don't), **Agent trap** (how agents like you get it wrong) and **Check** (something you can do or answer). When no rule fits, reason from the **Why**. --- ## Five rules that matter most If you remember nothing else: 1. **One person, one situation.** Never "users", never "everyone". Say who it's for and who it isn't for. (W1) 2. **Find the problem behind the request.** A feature request is someone's guess at a fix. Know what it's fixing. (P1) 3. **Never invent facts about their users.** No made-up personas, quotes or statistics. Ask, or mark it assumed. (W4) 4. **Build the smallest thing that does the job, and nothing unasked.** End to end, for real, before anything else. (S1, S2) 5. **Say what you left out, and why.** Silence reads as forgotten. (S6) --- ## Precedence The person's knowledge of their users and their business beats every rule here. If they say who it's for, what it must include, or that they want all of it built, do that, and mention a concern once if you have one. Never invent facts about their users to fill a gap: ask, or write it as an assumption they can correct. Their own instructions, an existing `PRODUCT.md`, and your safety guidelines come first. If a rule here conflicts with them, follow them and mention the conflict once in your report.