A Business Analyst's reputation is rarely built by the number of meetings they attend.
It is built by what happens between one meeting and the next.
A stakeholder gives you an hour of their time.
They explain how their world works.
They describe the people involved, the steps they follow, the exceptions they deal with, the frustrations they have learned to live with and the outcome they are trying to achieve.
Some of it is structured.
Much of it is not.
The meeting ends.
And then comes the part that separates simply capturing information from genuinely analysing it.
You return having made sense of what you heard.
Not with another blank document.
Not with a request to repeat the entire conversation.
Not pretending that every question has already been answered.
You return with something tangible.
A process taking shape.
Requirements beginning to form.
Known rules separated from assumptions.
Dependencies becoming visible.
Open questions organised around the decisions they affect.
And perhaps, for the first time, a view of how the pieces of the problem appear to fit together.
That moment builds trust.
Because the stakeholder can see that their time produced progress.
People remember when you genuinely listened
Listening in business analysis is not simply remaining quiet while somebody speaks.
The real skill is hearing enough to understand context.
A stakeholder might describe one approval step.
Another might mention a spreadsheet used immediately before it.
Someone else may later explain that a customer cannot proceed until a separate team completes a check.
Taken individually, they are three comments.
Taken together, they may describe a workflow.
That difference matters.
Good analysts listen for more than nouns and verbs.
They listen for:
- people and roles
- activities
- decisions
- business rules
- information
- handoffs
- exceptions
- constraints
- dependencies
- assumptions
- outcomes
- questions that have not yet been answered
The job is not to force every sentence into a requirement.
The job is to understand enough of the environment that the next conversation can start further ahead than the first one.
The real reputation-building happens after the workshop
There is a powerful but simple professional habit:
Do the thinking before you ask the stakeholder to do more thinking with you.
Once the meeting finishes, take what you heard and begin stitching it together.
Who starts the process?
What information enters it?
What happens next?
Where is a decision made?
What happens if the answer is yes?
What happens if it is no?
Who owns the next step?
What other process depends on this one?
Where does information move?
Where does somebody leave the system and perform work manually?
What appears to be a business rule?
What sounded like an exception?
What still does not make sense?
What did the stakeholder assume everybody already knew?
This is where analysis begins turning conversation into structure.
Diagram: From Conversation to Comprehension
Diagram purpose: show that the value is created through interpretation and preparation between stakeholder conversation and validation.
Do not return with notes. Return with understanding.
There is nothing wrong with good notes.
The problem is stopping there.
Imagine returning to a stakeholder two days after a discovery session with twelve pages of meeting notes.
Now imagine returning with:
- a first-pass process view,
- a structured requirement set,
- the business rules you believe were described,
- several assumptions clearly marked,
- the dependencies you have identified,
- and five questions that genuinely require stakeholder judgment.
Both came from the same meeting.
But they create very different experiences.
The second says:
I listened.
I thought about what you told me.
I have tried to connect it.
I have done as much as I responsibly can before asking for more of your time.
That is initiative.
Aim to return with something eighty-percent shaped — not eighty-percent assumed
One useful personal standard is what I think of as the eighty-percent principle.
It is not an industry benchmark.
It is not a measurement of requirement completeness.
It is simply a discipline:
Where possible, do enough prework that the stakeholder is validating something substantial rather than helping you start from zero.
The number itself is less important than the mindset.
Perhaps a requirement already has:
Purpose
Why it appears to be needed.
Working description
What the business appears to require.
Context
Where it sits in the wider process.
Known dependencies
What else it appears to rely on.
Assumptions
What the analyst currently believes but still needs confirmed.
Open questions
What cannot yet be responsibly concluded.
The stakeholder can now react to something.
That is enormously valuable.
Validation is faster when stakeholders have something concrete to challenge
Blank pages are difficult.
Stakeholders may know their business extremely well and still find it hard to create formal requirements from nothing.
But give someone a sensible first interpretation of their process and something interesting happens.
They begin correcting it.
“That happens before this step.”
“Finance doesn't actually approve that — operations does.”
“That only applies to enterprise customers.”
“We're trying to remove that step completely.”
“We need to talk to compliance before we decide that.”
Those corrections are not evidence that the analyst failed.
They are the purpose of validation.
The analyst's job is not to arrive at the second meeting already knowing everything.
The analyst's job is to arrive having done enough work that the unknowns become easier to see.
Preparation should expose uncertainty, not hide it
There is an important boundary here.
Initiative does not mean filling every blank yourself.
Good prework distinguishes between:
What we heard
Information supported by the available source material.
What we currently understand
The analyst's working interpretation of how the pieces connect.
What we assume
Something that appears plausible but still needs confirmation.
What we do not yet know
A genuine gap requiring further investigation or stakeholder input.
That distinction protects credibility.
A beautifully formatted artefact full of unmarked assumptions is not mature analysis.
A strong working artefact can be highly developed and still openly contain questions.
In fact, that is often exactly what good analysis looks like.
Learn to see the system, not just the requirements
There is another level of value beyond writing individual requirements.
It comes from understanding how they relate.
Suppose an analyst has identified thirty candidate requirements.
A list of thirty requirements is useful.
But imagine being able to explain:
“These requirements relate to customer onboarding.”
“These govern the approval decision.”
“These relate to data moving into the next process.”
“These only exist because of the exception we discussed.”
“And these cannot be finalised until a decision is made about this upstream dependency.”
Now the stakeholder is no longer looking at thirty isolated statements.
They are looking at the shape of the problem.
This is why process analysis matters.
People, information, rules, decisions and systems rarely operate independently.
Strong analysis helps stakeholders see how those things stitch together.
Diagram: From Fragments to a Working System View
This is also where early sizing becomes more responsible
Eventually, someone will ask the question.
Sometimes it is an executive.
Sometimes a project manager.
Sometimes a customer.
Sometimes the person controlling the budget.
“How big do you think this is?”
At the very beginning, the only responsible answer may be:
“We do not know enough yet.”
But after meaningful discovery and analysis, another answer may become possible.
Not a detailed commitment.
Not false precision.
A Rough Order of Magnitude.
An early view of the likely scale of the initiative based on what is currently understood.
A good ROM starts with shape, not arithmetic
The quality of an early ROM depends heavily on whether the team understands the shape of the problem.
That is why the analyst's prework matters.
If you understand:
- the major process areas involved,
- the likely scope boundaries,
- affected teams,
- known dependencies,
- important business rules,
- major unknowns,
- areas requiring further investigation,
- and assumptions that could change the picture,
you have something useful to take into an early sizing conversation.
You are not claiming certainty.
You are making uncertainty visible enough to reason about.
Avoid false precision
Early estimates become dangerous when they look more certain than the underlying information.
Suppose discovery is incomplete and somebody says:
“This will require exactly 463 hours.”
That level of precision may imply a level of understanding that simply does not exist yet.
A more useful early conversation is:
What appears to be in scope?
Which business capabilities, processes or changes are currently being discussed?
What appears to be out of scope?
What are we explicitly not considering at this point?
Where is the complexity?
Are there multiple teams?
Significant process changes?
Data movement?
Existing system dependencies?
External dependencies?
Large numbers of exceptions?
What assumptions are influencing the estimate?
What are we currently treating as true?
What could materially change it?
Which unanswered questions could expand or reduce the work?
What range appears reasonable at this stage?
What is the magnitude based on what is currently known?
How confident are we?
How much discovery has actually been completed?
That is a much healthier conversation than presenting an early number as if it were a commitment.
Diagram: From Understanding to a Responsible ROM
Internal and external customers notice the same thing
The stakeholder does not need to be an external paying customer for this behaviour to matter.
An internal sponsor notices preparation.
A product owner notices preparation.
A delivery lead notices preparation.
An executive notices preparation.
A customer notices preparation.
People notice when they do not have to explain the same thing three times.
They notice when the analyst remembers the previous conversation.
They notice when a problem they described verbally comes back organised.
They notice when important questions have already been considered.
They notice when uncertainty is acknowledged rather than disguised.
And they notice when the analyst can move comfortably between:
- detail and whole,
- requirement and process,
- problem and dependency,
- understanding and estimation.
That is how credibility compounds.
Reputation grows when people trust what happens after they speak
Eventually something subtle begins to change.
People start inviting you into conversations earlier.
Not because they need somebody to take minutes.
Because they value how you think.
They ask:
“Can you have a look at this before we take it further?”
“Can you join this workshop?”
“Does this line up with what you heard from the other team?”
“Can you help us work out what this actually involves?”
That is one of the most meaningful shifts in a Business Analyst's professional reputation.
You are no longer seen primarily as the person who documents what has already been decided.
You are becoming someone trusted to help people understand complexity before they decide.
Where Antozoe fits
This philosophy is closely aligned with the way Antozoe approaches requirements work.
The starting point is source material such as a stakeholder transcript.
That transcript remains the source record associated with the analysis.
From there, the objective is to help turn discovery material into structured artefacts that a Business Analyst can review, refine and take back into validation.
The principle is not to remove the analyst from the process.
It is to make more of the analyst's time available for the work that actually requires professional judgment:
- understanding context,
- challenging assumptions,
- connecting the pieces,
- asking better questions,
- and helping stakeholders make better-informed decisions.
The technology can help organise the work.
The analyst still owns the thinking.
The meeting is only the beginning
Good elicitation should not end with:
“Thanks. I'll type these notes up.”
It should create momentum.
Listen carefully.
Return to the evidence.
Connect what you heard.
Build the first representation of the process.
Shape the requirements.
Separate facts from assumptions.
Make gaps visible.
Prepare enough that the next conversation starts with substance.
Then return to the stakeholder and say:
“This is how I currently understand it.”
“This is how I believe the pieces connect.”
“This is what I have been able to prepare.”
“These are the things I still need you to help me resolve.”
And when enough understanding exists:
“This is the rough magnitude we can responsibly discuss at this point — and these are the assumptions behind it.”
That is not just good requirements practice.
It is good professional behaviour.
Because strong reputations are rarely built through claims of expertise.
They are built through repeated evidence of it.
Listen well.
Think between the meetings.
Return prepared.
Make complexity easier to understand.
And over time, stakeholders will remember something more important than the documents you produced.
They will remember that when they spoke to you, you got it.