Vague requirements are usually a test of judgement, not a trap. Turn the ambiguity into a short written brief, confirm it in ten minutes, ship a thin first version early, and make your assumptions visible so being wrong is cheap.
What people tell me
I recently started working as a developer. My manager gives me tasks in one or two sentences, like "improve the onboarding flow" or "add reporting for admins", and then expects me to work out the rest. I do not know what they actually want, I am scared of asking too many questions and looking slow, and twice now I have built something that was not what they had in mind. It feels like I am being set up to fail.
A composite of the messages behind this question, with personal details left out.
Key takeaways
- Ambiguity is part of the job at every level. Handling it well is one of the fastest ways to be trusted with bigger work.
- Write a five-line brief (goal, user, scope, out of scope, done means) and get it confirmed before building.
- Ask questions in one batch with your proposed answers, not one at a time with blank space.
- Show a rough version within the first quarter of the timeline so a wrong direction costs a day, not two weeks.
- Keep a running list of assumptions and decisions so nobody is surprised at the end.
Vague is normal, and it is not a trap
Almost every developer who writes to me about this assumes the manager is being careless or testing them unfairly. Usually neither is true. Most managers give short instructions because they are juggling ten other things, and because they genuinely do not know every detail yet. They are hoping you will work out the details, and they will notice whether you do.
In university, the assignment sheet tells you exactly what "done" means. At work, working out what done means is part of the task. The engineers who get handed interesting problems are rarely the ones who write the cleverest code. They are the ones who can take a two-line request and come back with a clear plan.
So the goal is not to eliminate vagueness. It is to turn it into something concrete, quickly and visibly.
Write a five-line brief before you write any code
Before you open your editor, write this in a message or a short document:
- Goal: what problem this solves and for whom.
- What I will build: the smallest version that solves it.
- Out of scope: what you are deliberately not doing yet.
- Done means: how anyone would know it works.
- Open questions: two to four things you genuinely cannot decide alone.
Then send it. Something like:
Before I start on admin reporting, here is how I understand it. Goal: admins can see weekly sign-ups and active users without asking engineering. I plan to add one page with two charts and a CSV export. Not doing: custom date ranges or email reports for now. Done means: an admin can open the page and download last month's numbers. Two questions: should this include deleted accounts, and does it need to work for every region or just ours? If I do not hear otherwise, I will assume no and ours only.
That last sentence matters. It gives your manager a default to accept, so a busy person can reply "sounds good" in ten seconds.
Ask questions in batches, with your own answer attached
People worry that asking questions makes them look slow. What actually makes someone look slow is asking one question at a time, spread across the day, with nothing attached. Compare these:
| Weak question | Strong question |
|---|---|
| "What should the report show?" | "I am planning sign-ups and active users per week. Is that the right starting point?" |
| "How should errors work?" | "I will show an empty state if there is no data and log failures. Anything else you need?" |
| "Which design should I use?" | "I will reuse the existing table component to save time. Is a custom design important here?" |
A question with a proposed answer shows you have already thought about it. It also makes you far easier to work with.
Show something early, even if it is ugly
The most expensive mistake with vague requirements is disappearing for two weeks and returning with a finished thing that was aimed at the wrong target. Instead, aim to show something within the first quarter of the timeline: a screenshot, a rough page with fake data, a sketch of the API shape.
A rough version gets a more honest reaction than any written description. People often do not know what they want until they see what they do not want. That is not a failure on their part. It is how most product decisions actually get made.
Keep your assumptions visible
Keep a short list in your pull request description or task notes:
- Assumed deleted users are excluded.
- Assumed weekly granularity is enough.
- Decided not to cache this yet because volumes are small.
If an assumption turns out wrong, the conversation is "we assumed X, let us change it", not "you built the wrong thing". Visible assumptions protect you and make changes cheap.
When it keeps going wrong
If you have done all of this and still keep missing the mark, have a calm conversation about it. Not a complaint, a request:
I have noticed a couple of my recent tasks ended up different from what you had in mind. I would like to get better at that. Would it help if I shared a short plan before starting each one, or is there something specific I should be asking earlier?
Most managers respond well to this. It shows ownership, and it often reveals context you did not have, such as a stakeholder they report to or a deadline they had not mentioned.
What this is really building
Handling ambiguity is not a side skill. It is close to the centre of what separates a junior engineer from a senior one. Senior engineers are rarely given detailed specifications. They are given problems, and trusted to shape them. Every vague task you handle well now is practice for that.
The fear of looking incompetent usually fades once you notice that nobody minds good questions. What they mind is surprises.
If you are still stuck
Read The Habits That Make an Engineer Worth Routing Work Through and What Actually Changes in Your First Two Years as an Engineer.
If you want someone to look at your specific situation, join Sefism and, as a member, book a 1:1 session. You can also browse the other career questions people have asked.
Was this answer helpful?
Read next
- What Actually Changes in Your First Two Years as an EngineerInterviews test the small part of the job that is easy to test, and the rest is learned on site. Reading code as the main skill, how to ask a question that costs nothing, why small shipped changes beat large ones in progress, using code review as the fastest teaching you will get, and the four things that actually get people promoted, three of which are not about writing code.
- The Habits That Make an Engineer Worth Routing Work ThroughEvery team has one or two engineers other people route work through, and what they have in common is not raw technical strength. It is that when something is given to them it comes back, and when it will not, you hear about it early. Fifteen habits that build that reputation, none of which require a title or permission.
Your situation is not quite this one?
Members get written answers to their own questions, a roadmap built for them and feedback on their projects. Early access is open to X and Instagram followers and university students. Prefer to talk? A free call works too.