It was also the means by which fabulous images like this came to be:

This is almost too perfect.

Pokémon Go became so popular that, as I type this, autocorrect is providing me with grammatically correct suggestions for Pokémon names. You go, autocorrect!

I conducted a brief love affair with Pokémon Go. Constrained to the nightmarish public transport system on my commute, many an hour was spent catching Pokémon. Favourite Pokéstops were established. Screengrabs of particularly fabulous specimens were shared. Many a discussion was had about my Pokédex, the benefit of a well-timed raspberry throw when endeavouring to catch particularly stubborn Pokémons, and all manner of other incredibly nerdy topics that probably wouldn’t have happened if I elected to do more with my spare time.

I feel somewhat better about my fandom right now.

But the whole premise of Pokémon Go reminds me of a bug bear that I have with product development; namely (not always, of course – but frequently) the perception of the BA role within the team. A red flag is signposted to me as soon as I hear the term ‘requirements capture‘. To some, the BA role is that of Ash Ketchum, frantically trying to catch all of the requirements before they disappear.

Requirements are not Pokémon, and should not be captured. The idea that product requirements can be captured suggests that they’re simply lying scattered around, waiting to be collected, or locked in someone’s head awaiting liberation. Requirements ‘capture’ defines an administrative task, sidelining what a BA should really be offering within the cycle of product development.

Within a product team, the BA sits as a bridge between the businesses need and the development cell, helping to articulate and define a business goal which can subsequently be achieved with the implementation of code. The solution to this requirement should be arrived at via a process of collaborative analysis, the BA providing insights around marketplace, competitors and the problem area in order to help facilitate the team and the business in arriving at a potential solution. ‘Capture’ is not the term for this; it negates the whole ‘analysis’ element we’re talking about. Let’s look at the definition of the word for a minute:

capture
ˈkaptʃə/
verb

record accurately in words or pictures.
“she did a series of sketches, trying to capture all his moods”

Capture implies that we are transcribing something that is already definite. This suggests BA involvement at the wrong stage of the process; once a solution has already been arrived at. Sure, solutions should be ‘captured’ once we get to that stage, but the primary function of the BA in your team should be geared towards analysis of the problem and the end-goal rather than the documentation of a predefined solution.

I want to build a contact form.

Is not a requirement, it is a solution. The real requirement here looks more like:

I want to make it easier for customers to get in touch with our company.

There are many solutions to the actual requirement: maybe a more prominent telephone number on your website is more appropriate, or maybe a live chat facility might be more fitting if the type of contact you’re encouraging requires more immediate attention?

Katch ’em and Kill ’em

The most common signs of an uneven BA function within your product team are twofold:

Loss of the ‘so that’

As a customer
I want this specific feature
So that…(?)

In this instance, the actual connection between what is being built and the user need is becoming lost, so we’re struggling to work out the benefit of what we’re building. This is a common by-product when a feature becomes pre-packaged, rather than driven by a problem statement and analysed as a collaborative process.

Finding our user becoming a solution architect

As a customer
I want a contact form…

The definition of a requirement is ‘a thing that is needed or wanted’. Why would a customer ‘want’ a contact form? What value does this actually add for them? Have you ever sat in front of a website bemoaning the lack of a contact form? It’s more likely you’ve sat in front of your computer frustrated that it is prohibitively difficult to get in touch with a company. This is the problem statement here.

This tends to happen when the business and customer needs are confused. As a customer, I want an easy means of contact. As a business, I may have decided a contact form is the easiest way to achieve this, but this is forgetting the fundamental requirement which is to fulfill the customers need. We should not lose sight of this, and we should be leveraging the skills that our BA has to assist in the identification of the most appropriate solution to the requirement; losing site of your ‘why’ negates any possibility to improve on the solution that has already been arrived at.

So, what are the principles that we should be adhering to to ensure that we’re nailing down the requirement, and not a solution?

1. Ensure we’re asking why

If we’re not asking why on a daily basis, then we should start. As a BA, the most vital part of your day to day is ensuring that you’re driving out these fundamental problem statements, and ensuring that for every predefined solution you’re presented with, you are tracking it back to the core need that it is trying to meet. If the ‘so that’ is becoming hard to define, ensure that those conversations to drive out the ‘why’ are happening.

My sentiment exactly, why-cat.

2. Ensure we’re involved as early as possible in the process

The problem of requirements ‘capture’ is a symptom of a process where BA involvement is coming too late. If you are finding yourself presented with a solution that is predefined, encourage those providing it to involve you in those conversations where that solution is being arrived at; in order to ensure that the appropriate analysis can be conducted before that predefined feature is dropped on your desk. No solution is so certain for success to not benefit from further interrogation.

This is you. Wielding the terrible sword of why.

3. Ensure your role is one of facilitation, not transcription

If you find yourself feeling like a PA, try setting up an example problem-solving workshop to collaboratively define a solution with involvement from the entire development team, and encouraging the provision of a problem statement rather than a feature definition from your product representatives to drive the session. This can be an effective and eye-opening means for demonstrating the benefits of collaborative analysis in action. Furthermore, coming armed with data and insights based around the problem area can add weight to the entire team’s collaborative output, and ground any potential solution in fact. And then? Rinse; repeat.

A shiny, manageable solution is something we can all enjoy,

Let’s hone our catching skills with Pokemon rather than our requirements; there are better ways to spend our time as BAs within a product team.