The Minimum Viable Product, an approach to maximize your value as a BA?

In the startup world and in many Agile methodologies, the minimum viable product (also known as an MVP) is a key concept that helps contributors to focus on building features that create the most value to customers early in the product creation process. It provides guidance to the implementation team so that they don’t forget the customer objectives toward the product and fall for the HDD (hype-driven development).

Through their different activities, Business Analysts create a lot of documentation. However, it’s often hard to tell if these artifacts are really useful for our stakeholders. Can the MVP approach be applied to Business Analysis deliverables to make them more valuable to our stakeholders? I explore the question in the following article.

1. First, what is a Minimum Viable Product?
2. The Minimum Viable Product of the Business Analyst
3. How can the BA Minimum Viable Product help you to be a better Business Analyst?
4. Building your own Business Analyst Minimum Viable Product

First, what is a Minimum Viable Product?

Wikipedia describes the Minimum Viable Product as “a product with just enough features to satisfy early customers, and to provide feedback for future product development.” Therefore, in order to build an MVP, you need to identify who are these early customers and what are their objectives toward the product, in order to identify what does “just enough features” mean to them.

This common example is often used to illustrate the Minimum Viable Product concept.  Let’s say I’m one of these early customers looking for a mean of transportation to go to work every day. Building an MVP can follow 2 different paths which can be illustrated like this:

Obviously, the second approach is better because it focuses on generating value early in the process, not only at the end of the process.  It also allows customers (ie me) to provide feedback faster and prevent useless development; what if a bicycle is the perfect product for me?

In the end, the Minimum Viable Product approach relies on a really good knowledge of your customers. This should be our starting point to apply the concept to Business Analysis.

The Business Analyst MVP

Like I explained above, Business Analysts create a lot of different, more or less valuable artifacts through their activities in organizations.  This is true no matter which methodology you rely on (waterfall or agile).

Applying the Minimum Viable Product approach to Business Analysis artifacts requires that we first identify who are our customers and what are their objectives for our deliverables.

As BAs are often seen as bridges between “Business” and “IT” departments, I think that defining our early customers as business stakeholders & implementation teams is a safe bet to work on the MVP of the Business Analyst. As for their primary objective toward our deliverables, I would roughly state it like this:

Get a shared understanding of the solution to solve/capture my already identified issues/opportunities, in order to implement it properly (business- and technical-wise).

With this information in hand, it gets easier to identify what key features (or deliverables) you should deliver as a Business Analyst in order to generate value for your customers (ie business stakeholders & implementation teams).

How can the BA MVP help you to be a better Business Analyst?

While the MVP concept comes from the lean/agile world, you can use it in any context to improve your work as a Business Analyst.

The key value in your MVP is to get you on track faster than by completing full-fledged documents since you start with small iterations of your deliverables first. It also allows your stakeholders to get the appropriate knowledge required for your BA activities in a quicker way since they build their understanding of the context gradually through the iterations of your BA MVP, not by reading a 200 pages document.

This is not only useful in an Agile context, but also in a traditional waterfall environment. It can indeed provide your stakeholders with a clearer view of the big picture faster than by using conventional, completed BA deliverables. You then have a better foundation to explore the various dimensions of the solution using a waterfall approach.

In a situation where your value as a Business Analyst is not strongly established, using a Minimum Viable Product approach could also help you to sell your contribution as a Business Analyst to non-believers. Since you focus on generating value early in the process, your stakeholders will be able to see your added value to the process faster.

Building your own Business Analyst Minimum Viable Product

The first steps to build your own MVP as a Business Analyst are to clearly identify the customers of your own artifacts, as well as their primary objectives when consuming these artifacts (like I did earlier in this post).

Keeping in mind the objective identified earlier (ie “getting a shared understanding”), your MVP should first focus on setting the boundaries of the solution to be implemented, so that your stakeholders know what to expect from it. A good way to do it is to start by documenting the two core components of a solution, ie business processes & supporting systems.  From this foundation, you will be able to add additional “features” to your MVP as your stakeholders provide you feedback.

In my next blog post, I’ll share with you what my usual BA MVP looks like. If you don’t want to miss this post, simply sign up for my newsletter!

Photo by Jess Watters on Unsplash