Some requests sound very short, very light, as if I should simply start right away.
"Write me an article."
"Make this screen look better."
"Optimize this workflow so it is cleaner."
In the past, I easily treated those sentences as enough to begin. I thought moving fast was useful. Make a draft first, revise later. Anything unclear would reveal itself while I was working.
But the more I learn about product work, UX/UI, Business Analysis, and working with AI, the more I see the opposite: a short request is not necessarily a clear request.
Sometimes it is only hiding many assumptions inside.
Who is this article for? What does "better-looking" mean, by whose taste, and for which user behavior? Does "cleaner" mean fewer steps for users, fewer operations for the team, or less complexity in the code?
If I rush straight into execution, I may work very hard. But hard work cannot rescue a problem statement I misunderstood from the beginning.
Going faster can just mean being wrong faster
AI makes this even clearer.
With one short prompt, AI can return a very smooth draft. An article with an opening, body, and conclusion. A list of user stories that sound reasonable. A screen with a clean layout. An email more polite than the one I would write while tired.
Looking at that output, I can easily feel the work is already halfway done.
But if the original request is vague, that smoothness can trick me. A fluent answer can still miss the point. A design that looks fine can still solve the wrong problem. A professional-sounding brief can still lack the most important thing: what are we doing this for?
AI does not automatically know my real context. A teammate cannot guess everything I did not say. Even I can fool myself, if I do not pause to write things down more clearly, into thinking I understand a request just because it sounds familiar.
I am beginning to realize that speed only matters when the direction is reasonably right.
If I do not know where I am going, moving faster may only take me farther away from where I needed to be.
A clear brief does not have to be long
I used to think a clear brief meant a very long document with many sections, many terms, and a slightly "grown-up" look. But a good brief does not have to be complicated.
It only needs enough anchors so the person doing the work does not have to guess too much.
Right now, when I meet a loose request, I usually ask five basic questions:
- What is the real goal? Are we trying to create awareness, persuade, explain, sell, save time, or reduce mistakes?
- Who is the reader or user? What do they already know, what do they need, what are they afraid of, and when will they use the result?
- What is the current context? Is this a new thing, an improvement to something existing, or a fix for a pain point?
- Are there constraints? Voice, deadline, required data, publishing platform, technical limits, or topics that must not be mentioned?
- What counts as done or good? When we look at the final result, what signs show it has met the need?
These five questions sound simple, but every time I answer them seriously, the request becomes much less foggy.
For example, "write an article about AI" is very broad. But if it becomes: "write a personal blog post in a warm voice for young people studying technology, about how to use AI to learn faster while keeping independent thinking," the work immediately has a better chance of going in the right direction.
It still does not need to be perfect. But now it has a goal, audience, angle, voice, and boundary.
For me, that is the difference between a casual ask and a brief someone can actually execute.
Asking again is not making things difficult
For a while, I felt awkward asking follow-up questions.
I was afraid people would think I was slow to understand. Afraid of making the conversation longer. Afraid my questions sounded too basic. Afraid that if I asked too much, the person assigning the work would think I was not capable enough.
But later I saw that asking again is not resisting the request. Asking again is a way of caring for the outcome.
When I ask, "Who is this article for?", I am not making things hard for the requester. I am trying not to write a grammatically correct article for the wrong reader.
When I ask, "Do you want this screen to feel more minimal, friendly, or professional?", I am not nitpicking the word "better." I am helping both sides avoid repeated revisions because each person imagined a different direction.
When I ask, "If we could keep only one message, what should the reader remember?", I am not slowing the article down. I am looking for the axis that keeps it from wandering.
The right question can save more time than immediate action.
Because fixing a wrong assumption at the beginning is usually lighter than fixing a nearly finished product.
Using AI as someone that helps me think more clearly
What I like about AI is not only that it can write quickly. What I find more useful is that it can help me see what is still unclear.
Instead of starting with a prompt like "do this for me," I am practicing prompts like:
- "Ask me the missing questions needed to clarify this request."
- "Point out the vague assumptions in this brief."
- "If you were a BA or Product Designer, what would you ask before doing this?"
- "Turn these messy notes into a clear brief, but do not invent missing data."
That way of asking makes AI a companion in the thinking part, not just a machine that generates drafts.
It also forces me to be more honest with myself. If I do not know who the reader is, I have to admit I do not know yet. If I do not have a real example, I have to mark that as something to add. If I am using broad words like "better," "cooler," or "optimized," I have to bring them down to earth with more specific criteria.
This skill feels very close to Business Analysis.
A BA does not only record requirements. A BA helps requirements become understandable, discussable, testable, and executable. Product thinking is similar: before rushing into a solution, I need to understand the problem, the user, the context, and how we will know whether we solved the right thing.
AI can strongly support expression, synthesis, and structure. But the responsibility for the question still belongs to me.
A clear brief is a small gift
I do not think every piece of work needs a heavy process. Some small tasks only need a few lines. Some conversations become clear after one extra question.
But I want to stop treating vagueness as something we simply have to endure.
A clearer request is a small gift to the person doing the work, because they do not have to guess so much.
It is a gift to the person receiving the result, because what they receive is closer to what they really need.
And it is also a gift to my future self, because when I look back, I understand why I chose one direction, left another out, and called something finished.
I am still learning to ask better questions. Sometimes I still miss things. Sometimes I still rush. Sometimes a request feels so familiar that I assume I understand it.
But at least now, before beginning, I often stop for one breath and ask myself:
"Do I actually have a clear request, or only a sentence that sounds easy?"
Often, that one pause makes the work more honest.