In a proper open market, due to competition and innovation, customers will demand more from your products. They require you to deliver at minimum the same quality as your competitors. If you want to stand out and be a market leader, you should out-run your competition. If you want to stand out and be a market leader, you should focus on what drives your customers.
Well, it is not as easy as you might think. For example, how do you know the needs of your customers? And do they all want the same? Likely not… How can you make sure that you know exactly what your customers want? In a way that the experience of your products is as high as they expect? Or even beyond? Let me bring the business analyst into the spotlight!
The role of a business analyst
Well, let’s focus on the needs. In order to find out what customers want, it is firstly of crucial important to know your customers. Typically, a business analyst is in the lead to find out what the needs of the business is. And in the end translates this in understandable user stories for the development teams.
The business analyst is the link between business users with their needs and investment and a development team with their programming and facilitating skills.
As you can see, the business analyst is like a spider in a web and communicates with all different kind of people in an organisation. It is because of the organisation knowledge, communication skills, process and system awareness that he or she can function well on this level. Being fully aware of the interactions, working methods and individual and corporate needs, the Business Analyst uses this knowledge to:
Identify the (unidentified) needs of the business users,
Translate the needs into the best possible solution directions
Communicate the solution across all stakeholders
Test and implement the solutions into existing processes
But before the business analyst can do this, there are some steps to be taken for which a toolbox containing some interesting tools is available. In this blog, I would like to mention 3 of them: the persona, the customer journey and process flows. These 3 tools contribute in defining the requirements of a user (or customer).
The toolbox: persona’s, customer journey and process flows
Before true requirements can be defined, it is of crucial importance to identify the needs of a customer. Often this is done with a so-called inside-out focus, where the internal organisation think they know what their customers need.
A good way to prevent assumptions about this is by asking the customers. This sounds logical, but this is often one of the biggest mistakes made whilst capturing the needs. Make a good questionnaire or talk to them and find out what they want. And in the end try to group the needs together and label it. This can be done by defining personas representing a group of customers that share the same needs and behaviour. Finding out what these personas feel, think, say and why they act and behave, can be done via empathy maps.
Once this persona is ready, the next step is to define the ideal journey that they go through. Not only with your company, but identify also extra moments in this journey that customers really find important in taking decisions. You might end up in defining such moments in which you are not involved yet, but where you are perfectly able to help your customer. The steps in this journey should be made explicit and pain points should be identified as well. Once pain points are known, you can start thinking about solutions to cover these.
Another tool in the toolbox is drawing process flows. This is done once personas and customer journeys are known. How do the processes work and what stakeholders are involved? Via swimming lanes the involved stakeholders can be incorporated in the process flow. A good way to draw up process flows is via the BPMN method (Business Process Modeling Notation). This standard makes sure everybody is talking in the same ‘language’.
An example of such a BPMN flow:
Once all above is clear and checked with the business users and owner, it is time to define the solution to cover the pain points. This is described as a feature (capabilities that a solution must possess and can be further broken down into requirements.
A commonly used definition of a requirement is (as defined by IEEE):
A condition or capability needed by a user to solve a problem or achieve an objective
A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document
A documented representation of a condition or capability as in 1 or 2.
A good way to structure and define the requirement is by defining 1 or more user stories per requirement. User stories help to explain what the purpose of a requirement is for a person(a) and why it helps. The definition of such a user story can be described via the following sentence:
As a <user>, I want to <do something> in order to <achieve my goal>.
As a sales manager, I want to have a weekly overview of the sales figures of my team, in order to keep track of the progress of my team targets.
These user stories can be used to communicate and explain requirements to the development teams. And these elements can then be picked up in an agile way of working for example in scrum teams via sprints.
So finally the solution can be built in which the business analyst performs the role to organize tests with the business users and to make sure the wanted and tested requirement will be brought to production in order to use it.
All in all, the business analyst plays an important role in driving the customer experience, as a good foundation definitely is of crucial importance in giving customers not only want they want, but even more, give them what they need. And there are some good tools available out there…