“On a scale of one to ten, how resilient would you say you are?”, I was once asked in an interview.

I responded: “ooh – a seven – maybe an eight”

“Really? Why not a ten?” came the reply.

“Because, whilst I’m an optimistic person and will always bounce back after a setback,  I’m also a born analyst. That means I see things at many different levels of abstraction, and as such I’m sensitive to things others perhaps aren’t, which means I’ll always see more threats. And actually, for precisely this reason, I think a BA always needs to harbour a healthy element of self-doubt in order to be effective”.

It impressed my potential suitors, and is, I think, what clinched the role for me.

But within that answer – and even the question itself – is a fundamentally important point:

Change is risky, and risk undermines confidence. Therefore successful change is ultimately about generating and maintaining confidence.

Confidence is that reason why, in a waterfall environment, the requirements need to be documented and approved before the design starts. It’s the reason why we plan projects, test solutions, RAG-status updates, and gain approvals to proceed. When we manage the change, we need to give our stakeholders confidence in the to-be state – not only that it will be better, but that nothing will break in the process.

It’s why, as analysts, we draw diagrams to allow stakeholders who are otherwise ‘in’ the change to be able to work ‘on’ the change. It’s why our documentation needs to be manicured – all the ‘i’s dotted and the ‘t’s crossed, the grammar correct – because nothing exacerbates the nervousness associated with change quite like a mistake in the document describing it.

“If you can’t even get that right, what are you going to do to my business area?!”

So in a waterfall environment, promoting confidence means taking extra care (and often extra time) to make sure everything is correct before it goes public.

This is a real challenge for BAs – because Agile and product management have turned this dynamic on its head.

In a fast-moving, ever-changing digital environment, the very concept of waterfall has been invalidated: by the time you’ve dotted the ‘i’s and crossed the ‘t’s, the ‘i’s have become ‘j’s and the ‘t’s have become ‘u’s! It’s quite literally impossible to project out what future needs will be from a static point in time.

Notice how I just used the word ‘project’ as a verb rather than a noun? Actually the noun comes from the verb – not only is the waterfall methodology inadequate for today’s change environment – the same applies to projects (literally named that way because they ‘project’ out a future state). The logic is now fatally flawed.

Hence, Agile and product management: we won’t know exactly what we need, so let’s start with something quickly and see how well it works in reality; then use that feedback either to decide to pivot onto something else, or evolve it to make it better. We build confidence, not by thinking of everything up-front, but by doing something and using the facts it generates to react accordingly. Generating facts from real users is far and away the most effective requirement elicitation technique.

It’s much more effective because in a digital world, often customers don’t know what they will want, because they don’t necessarily know what they can want. Consider current affairs – have you ever noticed how everyone’s a critic, but nobody seems to be able to imagine and articulate a better system for running the country? It’s human nature – we’re extremely bad at ‘projecting’ out what we will want in the abstract, and much better at deciding whether we want something when we see it. Basically, we’re better with buffets than we are with menus!

Again, this is about confidence.

If you’ve ever read a book about self-confidence, you will know that it’s defined as the belief that you can do something, and if you do it something good will happen. And how do you build self-confidence after a knock? By setting and achieving small goals – little and often. And what really helps with this is a growth mindset, where setbacks are recharacterised as learning opportunities; where the desire to get things right every time is replaced by the knowledge that you won’t know what right it until you get real feedback.

For a BA this can be an uncomfortable space. I used to write manicured 250-page business requirements documents with detailed processes and sculpted prose to explain the requirements, before sending out to a list of 50 – often very senior – stakeholders. Every time I did that I’d get a dramatic increase in heart-rate immediately prior to pressing ‘send’ on the email – just one more check of the document and the grammar on the email before I send it! And often required a lie down in a dark room afterwards to try and ‘latibulate‘ from how exposed I felt in those agonising moments waiting for feedback, such was the potential risk to my self-esteem!

But this is very much waterfall. Closed mindset. The expectation of perfection, and the fear of failure.

In an Agile or product environment, I open a blank document on the shared drive. ANYBODY can see what I’ve written at ANY TIME – all those silly first drafts, all those misunderstandings and mistakes! To an oversensitive BA mindset, that’s worse that ‘the fear’ from sending out a document!

But herein lies the required paradigm-shift.

Feedback on something real is far and away the most effective requirement elicitation technique, because it’s based on fact. That means ‘putting yourself out there’, warts and all, for other people’s judgement, knowing that it’s not you being judged, it’s your work. Nobody expects perfection, because it’s an impossible ask.

Developing the growth mindset to get comfortable with this is the single biggest thing a BA can do to adapt to an Agile or product environment.