# Two Prompts That Aren't in the Book **Bonus for readers of *The 4-Hour Side Hustle*.** Both follow the pattern from Appendix C: one job per prompt, an explicit prohibition on inventing, and a refusal token so the model can say *I can't* instead of producing something plausible. Both assume the Claude or ChatGPT Project from Chapter 3.3 — Business Brief, five writing samples, raw customer language. --- ## B1 — The Version 1.1 Update **When to run it:** three to six months after launch, when you have real support tickets, real refund reasons, and real questions from buyers — and no idea which of them justify changing the product. Everyone's instinct at this point is to rebuild. Usually two or three specific fixes would do it, and the rest of the complaints are about a product you deliberately chose not to build. > You are helping me decide what to change in version 1.1 of a digital product. Below are: (a) every support question I've received since launch, (b) every refund reason given, and (c) any review or unsolicited feedback. All verbatim and unedited. > > Your task: > > 1. Group the feedback into themes. Name each theme in the customers' words, not mine and not marketing language. > 2. For each theme, state how many separate people raised it. Count people, not messages — one person asking three times is one. > 3. Sort each theme into exactly one of: > - **DEFECT** — the product doesn't do what it says. Fix in 1.1, no discussion. > - **GAP** — the product doesn't do something a reasonable buyer expected. Candidate for 1.1. > - **SCOPE** — a request for a different product. Not 1.1. Possibly a future product. > - **MISMATCH** — the buyer wasn't who this is for. Fix the sales page, not the product. > 4. For each DEFECT and GAP, estimate the work in hours to fix, and say plainly whether it can be fixed by editing what exists or requires building something new. > > **Rules:** > - Do not invent feedback. Every theme must trace to at least one quoted line, and quote it. > - Do not propose improvements nobody asked for. If you think of one, it goes in a separate list at the end labelled `UNREQUESTED`, and I will probably ignore it. > - If a piece of feedback is too vague to categorize, list it under `UNCLEAR` rather than guessing which bucket it belongs in. > - Do not soften refund reasons. If someone said it was overpriced, write that they said it was overpriced. **Then, as a second message:** > Now argue that I should change nothing at all, and ship the sales-page fixes only. Make the strongest case you can. **How to read it.** Every DEFECT gets fixed. GAPs get fixed only where the hours are small and more than two separate people raised them — a gap raised once is a preference. Every SCOPE item goes in a file for later; that file is where your second product comes from. Every MISMATCH is a sales page problem, and fixing the page is cheaper than fixing the product and usually more effective. The argue-against pass exists because version 1.1 is where a finished product quietly becomes an unfinished one again. --- ## B2 — The Quarterly Tool-Price Audit **When to run it:** once a quarter, in the same sitting as your ledger re-score. Twenty minutes. Your stack drifts. Free tiers get smaller, paid tiers get more expensive, and per-seat pricing that made sense at fifty subscribers stops making sense at two thousand. None of it announces itself — the invoice just gets bigger, and you notice in a year. This prompt does not check prices for you. **It can't, and a model that claims to is guessing.** What it does is turn a pile of invoices into the three questions worth acting on. > You are auditing the software costs of a one-person business. Below is my current stack: each tool, the tier I'm on, what I pay monthly, and what I use it for. Where I know the usage numbers — subscribers, operations, storage, seats — they're included. > > Your task: > > 1. Rank every tool by **cost per job it actually does for me**, based only on the usage figures I gave you. Where I haven't given you a figure, say `NO USAGE DATA` rather than estimating. > 2. Identify any tool where I'm paying for a tier well above my actual usage. > 3. Identify any tool where I'm close enough to a tier limit that crossing it would be expensive, and say how close. > 4. Identify overlaps — two tools doing substantially the same job. > 5. Flag anything I've listed that I haven't described using in the last quarter. > > **Rules:** > - Do not tell me current prices for any tool. You do not have reliable pricing data and pricing changes constantly. Work only from the figures I gave you. > - Do not recommend alternative tools. Switching cost is almost always higher than the saving, and I'll ask if I want that conversation. > - Do not invent usage numbers. `NO USAGE DATA` is a complete and acceptable answer. > - If my stack looks reasonable and there's nothing worth changing, say so directly. Do not manufacture a recommendation. > > Output as a table sorted by monthly cost, highest first, with a short `ACTION` column limited to: `keep`, `downgrade`, `watch limit`, `cancel`, or `investigate`. **How to read it.** Anything marked `cancel` that you haven't used in a quarter, cancel today. Anything marked `watch limit` goes in your Command Center with the limit written down — the expensive surprises are almost always a tier crossing, not a price rise. Anything marked `investigate` gets fifteen minutes, and no more, before the next quarter. **The rule that keeps this honest:** the model must not tell you prices. It doesn't know them, they change monthly, and a confidently wrong price is worse than no price — it's the same failure mode the book's price appendix warns about, which is why the current stack table lives on the website with a dated changelog rather than frozen on a page. --- ## Checklist - [ ] B1 run only with verbatim, unedited feedback — no summaries - [ ] Every theme traced to a quoted line - [ ] Argue-against pass run before deciding anything - [ ] DEFECTs fixed; GAPs fixed only if small and raised by 2+ people - [ ] SCOPE items filed for a future product, not built into 1.1 - [ ] MISMATCHes fixed on the sales page, not in the product - [ ] B2 run quarterly, in the same sitting as the ledger re-score - [ ] Usage figures supplied where you have them, `NO USAGE DATA` accepted where you don't - [ ] No tool prices taken from the model — checked against real invoices - [ ] `watch limit` items recorded in the Command Center with the actual limit