Requirements Gathering

What is Requirements Gathering?

Simply put, Requirements Gathering is the process whereby you need to intentionally gather requirements. Requirements Gathering tools, techniques and questions should be used in this process.

It is an iterative process where your team is proactively asking relevant questions, rather than simply asking for a list of features from stakeholders or users. In this process, you should avoid making major decisions purely based on subjective opinions.

What is Product Conceptualisation? Why is it important to me?

Product conceptualisation is an experimental phase for your team to try different possible solutions to problems prioritised during the problem discovery stage. This comes before committing to the agile development of your digital product or service.

At this stage, you should:

• Explore new approaches and challenge conventional methods

• Create prototypes that experiment with different solutions

• Test the riskiest assumptions

• Build to the fidelity necessary to learn; no need for production-ready code

Information gathered at this stage helps your team to decide whether possible solutions are worth taking into agile development.

Examples of product conceptualisation include:

• Looking at how a possible solution would affect your wider service journey

• Gaining an understanding of how you can make the product journey viable

• Exploring possible solutions to meet user needs within identified constraints

• Defining the product vision and roadmap

• Gathering sufficient evidence for budget, resourcing and time estimates to deliver a Minimum Viable Product (MVP)

What is Service Blueprint? How can it help me?

A Service Blueprint is a requirements gathering technique which allows your team to know who are the beneficiaries of your project.

It is useful to develop narratives and storyboards that define your end-users’ journeys. Your team could gain greater insights into user interactions and reactions -  from performing a task, to how they use the product as a solution.

Your service blueprint should consist of:

• Your inner operations and support structures that create the user’s experience

• Responsibilities of your internal actors, processes and policies for regulatory purposes

A Service Blueprint helps you to unite many stakeholders and team players (with different KPIs, fundings, etc) to agree on common goals and objectives.

What is Prototyping? Why is it important to me?

Prototypes are used to validate hypotheses about your product’s problem and solution space with actual users.

You should always start building low-fidelity prototypes since they are much cheaper to build, modify and iterate. Starting with high-fidelity prototypes is not encouraged because it takes up more of your time and money.

Consider progressing to high-fidelity prototypes only when your product gains more certainty in features. You can be certain after continuously reviewing your low-fidelity prototypes.

Am I ready to move past Product Conceptualisation?

There is no set time period for conceptualisation, but teams usually take 3 to 4 months in this process.

You should let the complexity of the problem space and potential solutions dictate how long your team spends on it. If your team is still not confident at the end of the timeline, it may be wise to repeat discovery or conceptualisation.

You can move past the conceptualisation stage when the prototype is substantial enough to help your team make a decision about whether you should invest in the agile development of a Minimum Viable Product (MVP).

What should I work on after Product Conceptualisation?

1. Minimum Viable Product (MVP)

An MVP is a product with sufficient features to test an idea out in the market. It helps you and your team to learn quickly what works and what doesn’t. The process allows your team to learn how to deliver maximum business or customer value with the least amount of features.

In the construction of your MVP, we recommend frequent iterative releases because the continuous feedback helps to finetune your user-centric design features and technical infrastructure.

Before starting work on your MVP, you should consider:

• Are there better commercial/industry solutions out there?

• Is the impact of your product worthy of your invested effort and costs?

• Do your partner stakeholders have the capability to run agile, user-centred practices?

• Is your full-scale implementation viable from a policy, ops or service perspective?

• Are your dependent agencies able to support the operationalisation of your solution?

If your team is confident to move to beta, it is time to partner with other product, tech and business leads (and agency stakeholders) to work on a funding proposal together.

2. Prioritisation Matrix

A prioritisation matrix helps you to prioritise product features, and plan your project’s roadmap.

A well-defined matrix also helps your stakeholders to agree on what the team should work on, minimising future disputes.

Last updated 04 December 2021