How a Business Analyst can save your product from hell?
In today’s fast Agile world the business has to be sure that the final product meets market expectations. But not always the product meets those expectations. There could be various of reasons: poor market research, undefined product OKR, not elaborated value proposition, undescribed target user. Then imagine that product manager transfers such vision requirements to delivery team. In fact 50% of failed projects relate to “poor” vision requirements. Here is where BA takes part to minimize the risk that final solution won’t meet the actual business needs.
“Minimize the risk that final solution won’t meet the actual business need”.
I will get back to this statement later.
So how can a BA help here? And you might say that each competency has it’s own approaches and practices so just read the guidance and go ahead. Well yes the business analysts professionals have their own “bible” as “A Guide to the Business Analysis Body of Knowledge” (BABOK) and you can find there various techniques for each particular area on how BA can perform. No doubt they are all valuable and came from various professionals from different domains and industries.
But here is the thing, not BABOK guide or any other standard will give you holistic view with actual steps on how to bring the value to the business. So I strongly believe that depending on business case the BA should be flexible enough by using those techniques to adapt on client, business, market, team or anyone or anything that impacts on the product.
As I said there is no clear steps that will fit to each project in order to solve all current problems. So here is my top 3 areas where a business analyst must have be involved:
1. Define the Problem
We are all trying to be problem solvers. No matter if you work on the current project or from the scratch we trying to solve the clients problem. But what actually problem we facing with? Are we sure that this something that we should focus the next 4 months or for the next sprint? That’s a key question that we should validate with our stakeholders in order to make sure that we need to focus on the most important areas that market really waiting for.
The prioritized list of well-defined features and it’s successful delivery do not guaranty the overall success. That is why on the product discovery we should validate if those features really solve the users problem. And earlier we figure this out then less resources and most importantly time we loss.
You’ve just joined to the Team where there is a product vision. Does it mean that we should not focused on problem anymore? No, never stop keep an eye on it. Is it just the next feature kick off elaboration or release discovery.
Product owners or Product managers often focused on features itself instead of actual value to user we want to bring. I often hear that this for MVP but this is out of MVP scope. And you know what when new release starts no one even cares about those features anymore because it’s a new release and new expectations are set by sales, marketing and key stakeholders. If you work with that approach what your product will look like after a couple of releases? BA should make gap analysis and compare current and to be states of the product, feature, process etc. and bring those key areas to the stakeholders to avoid the risk that MVP does not really cover the actual business need.
2. Analyze impact
Each release the amount of features that are requested by PO is usually more than actual delivery team capacity. And this is normal since there is a strategic plans, market demand, sales requests etc. But the more business value we add more dependencies with existing system might occur. This is where BA shines and save client’s resources. Because the key skill for BA is to define the dependencies that can be exist on strategic or tactical level.
Client wants to embed the new capabilities for his enterprise. But do we realize how those capabilities will live within existent system? Is there any risk that those needs are won’t give us more effort and wasting of time then actual value?
Adding one more feature to release? Do we actually assess the possibility how that one feature can conflict with existent requirements? Are those dependencies worth to put it to the one more sprint and prolong the release?
Make impact analysis on the enterprise level and look at the feature requirements in the context of the whole product. Because requirements that covered only happy path will cost a lot after actual implementation. So help your PO to find out those dependences which will save the resources and most importantly time.
3. Validate Expectations
Remember?
“Minimize the risk that final solution won’t meet the actual business need”.
As I mentioned before the business should be sure that final product will solve the user problem. And with constant features requesting we just losing the holistic picture of value that we trying to bring.
Fore sure there some options which can help you to minimize that risk. For example trace you requirements from business to functional and keep track all in one place. Or use story mapping technique to reflect the user journey and map it to your existent product in order to figure out if we actually solve user’s problem.
The main challenge I would like to emphasize here is to make sure that initial plan is aligned with anyone who has impact or interest in your product. No matter what kind of stakeholder is: CTO, VP of Product Management, Subject matter expert, head of market or end user. You have to manage those expectations in order be sure that at the end of the release the product will fit with those needs. So you have to know your stakeholders. Define their expectations and make sure that they are prioritized based on approved plan. Face to face collaboration is the best way you can do it. Is it the strategic workshop with key stakeholders or User Acceptance Testing (UAT) or user interview. You need to elicit all pain points of each stakeholder who can somehow impact to the product.
As soon as you have get the vision with target market and value proposition make sure that all stakeholder are aligned with that. Involve those stakeholder in the current progress and validate those implemented capabilities with them whatever is project initiation or general feature kick-off elaboration.
Some time ago I’ve heard the quote of Dag Hammarskjöld, secretary-general of the United Nations, so he said:
“United Nations was not created to take mankind to heaven, but to save humanity from hell”.
The same situation with a Business Analyst, using relevant approach BA will do everything to make sure that your solution will give the actual value to your product in order to avoid any “hell” when time “X” comes…
