BlogTank LabGameAboutContactBook a call
Work With Me
Notice

From now on we will use our new official domain thetanklog.com instead of tankbaclass.com.

Navigation
  • Blog
  • Tank Lab
  • About
  • Contact

© 2026 The Tank Log. All rights reserved.

Back to Articles/Requirements & Analysis

Assumptions in Business Analysis: How to Avoid "Jumping to Conclusions"

TM
Tank
Product builder · Mentor BA
|
January 6, 2025
|
2 min read
|
235 reads

In BA work, missing information makes assumptions inevitable — but wrong assumptions lead to incorrect confirmations and rework. This article shows how to minimize risky assumptions and avoid jumping to conclusions.

In the BA world, encountering missing information or situations where gathering information is nearly impossible is a common occurrence. That's why making assumptions is inevitable. However, there are still cases where analysts, despite having collected and analyzed information, still make assumptions. Even I, while analyzing, sometimes make assumptions, leading to incorrect confirmations with clients and requiring rework.

So, how can we minimize this situation when making assumptions is unavoidable? Based on my experience, here are a few ways I can share with you:

1. Validate

This is the easiest and most effective way to determine if your assumption is correct. There are many ways to do this, and they're quite similar to the techniques used for requirement elicitation: interviews, surveys, Q&A sessions, etc. Validation is not only for determining whether an assumption is right or wrong but also to determine if it truly meets the client's needs. Remember, don't just focus on verifying right or wrong.

2. I/O Flow

Those of you who have taken my BA course are probably familiar with this technique. I/O flow helps verify the input and output information of an issue, specifically, in this case, an assumption. If the analysis results during the I/O flow process are unclear – where it's created, how it's used, whether it meets the initial requirements – then the assumption might be heading in the wrong direction.

3. Scenario

This involves outlining specific use cases for the assumption within the system. Use cases should be applied to different roles (different types of users on the system) in happy case, alternative, and exception scenarios. Use this analysis to assess the feasibility of the assumption.

4. Prototyping

Prototyping involves using design tools like Figma, Invision, or even coding a part of the software to give clients an initial visualization of the product – basically, a "sample product." By seeing this "sample product" and performing simple interactions, clients can easily verify if the BA's assumptions align with their expectations.

There are many other approaches depending on the specific case and the project/company. If you have any methods you'd like to share, feel free to leave a comment below!

Chủ đề:
Chia sẻ bài viết này
Lan tỏa kiến thức thực tế đến cộng đồng BA
Did this help?
Buy me a coffee and I'll keep writing ☕
MỤC LỤC
4
1. Validate2. I/O Flow3. Scenario4. Prototyping
CHỦ ĐỀ & THẺ
5
Requirements & Analysis#Assumptions#Critical Thinking#Requirement Validation#Analytical Rigor
0%

Related articles

Requirements & Analysis
#Assumptions
#Critical Thinking
#Requirement Validation
#Analytical Rigor
Previous
Requirement Elicitation - "Evaluating Requirements"
Next
Which Method to Use for Requirement Elicitation and What to Prepare?
Demystifying Analytical Thinking: How to "Divide and Conquer" Any Complex Problem
Requirements & Analysis

Demystifying Analytical Thinking: How to "Divide and Conquer" Any Complex Problem

Mar 9, 2025
Non-Functional Requirement (NFR)
Requirements & Analysis

Non-Functional Requirement (NFR)

Mar 5, 2025
Requirement Prioritization
Requirements & Analysis

Requirement Prioritization

Feb 5, 2025