jezweb Imagine: find the bigger product in the request
The brief is rarely the real opportunity; it's a symptom of a bigger need. Before you scope the task, imagine what this could become and what the users and the business will need that nobody's asked for yet. The output is a north-star, not a task list and not estimates: a direction to steer by, deliberately ahead of what you'll build first.
Read the real thing first, as the end user. The actual conversation, the documents, the product as it is, not a summary, and walk their workflow as the person who'll use it. A stray field or step in their own docs often reveals the real job. You can't expand a request you only half understand.
Find where the bigger product is hiding:
- Find yourself in their diagram. If they've drawn their process, you're usually one box in it and the rest is the roadmap. Build your box, but see the whole picture you're a part of.
- Trace the pains to a shared root. Several complaints usually share one cause. Owning that root is the wedge, the thing that makes solving the rest follow.
- Hear what they don't want, and make it a line. A "don't turn this into X" is a gift: turn it into a structural constraint you design around, not a wish you might quietly drift past.
- Carry the commercial with the technical. The vision includes how it's paid for and pitched, not just what it does. A north-star the business can't fund or sell isn't one.
- Look at how the leaders already do it. Study the best products in the space, and notice what they pointedly don't do. The bigger version is often visible in what leaders ship; the opening is often the thing they've all missed.
Then expand, deliberately past the ask:
- What's the version that makes someone say "how did I work without it"? What adjacent need does this unlock next?
- What changes at ten times the scale, and what single integration or piece of data would change the shape of it, not just add a feature?
- What will the business need in a year that this is quietly the foundation for?
Map the edges, tier them, build none. Name the futures and rank the jumps they'll make; commit to none. This is a vision to steer by, not a spec.
A real example beats this list. Keep one genuinely good vision doc as the quality bar, a concrete worked example teaches the shape far better than any set of prompts (this is goals-over-recipes from plan-and-build, applied to the skill itself).
Pair with challenge (stress-test the idea), then plan-and-build (turn the chosen slice into a plan). The failure this prevents: building exactly what was asked and shipping a smaller, more forgettable thing than the request was actually pointing at.