Most people use Claude Code for implementation. I've started using it earlier in the process — before any code is written, as a thinking tool for product decisions.
It's surprisingly good at it.
Edge case enumeration
Before implementing any feature:
I'm building [feature]. Before I spec it out:
What are all the edge cases I need to handle?
Think about:
- Empty states
- Error conditions
- Unusual but valid inputs
- Concurrency (two users doing this at the same time)
- The user who tries to break it on purpose
Don't suggest implementation — just enumerate the cases.This consistently surfaces things I would have discovered in QA instead of requirements. Cheaper to handle upfront.
User flow thinking
A user wants to [accomplish goal] using [feature].
Walk me through the entire flow from their perspective.
Where might they get confused? Where might they fail?
What information do they need at each step?Claude doesn't know your users, but it can reason about a generic user's mental model. This catches gaps in the flow that are obvious once named but invisible when you're inside the implementation.
Scope discipline
The hardest thing in product work is deciding what not to build. Claude is useful for making the case for minimal scope:
I want to build [feature]. What's the minimum version that would be
useful to a first user?
Then: what's being added to make it complete vs useful?
Separate "must have for first user" from "nice to have".The "first user" framing forces prioritization. Claude is consistent at identifying which requirements are actually assumptions about polish, not requirements about utility.
Copy review before implementation
For anything user-facing, run the copy through Claude before building the UI around it:
This is the copy for [feature]: [paste]
From a user's perspective:
1. Is it clear what this does?
2. Is there anything ambiguous?
3. What question would a confused user have?
4. Is any word doing more work than it should?Fixing confusing copy before the UI is built around it saves a redesign later. It takes five minutes before implementation, or two days after.
The "why would someone pay for this" test
For features on paid products:
Pretend you're a potential customer evaluating [feature].
Why would you pay for it? What would make you not pay for it?
What would have to be true for this to be worth $[price]?Claude's answer is a hypothesis, not market research. But it consistently surfaces the cases where a feature isn't actually solving a clear problem — the kind of thing that only becomes obvious when you try to explain why someone would pay for it.
What Claude doesn't know
Claude doesn't know your actual users, your market, your competitive position, or your company's priorities. All of those require real inputs.
These prompts are most useful when you have those inputs and need a structured way to think through the implications — not when you're trying to skip the user research step.
Product thinking prompts are in the Agent Prompt Playbook — edge case enumeration, scope minimization, user flow analysis. $29.