From Scribe to Consultant — Sharing Session Series
MHUI is a structured discovery framework that transforms how Business Analysts uncover stakeholder needs. The acronym stands for Masalah (Problem), Harapan (Hope), Usaha (Effort), and Ide (Idea) — four lenses that guide the BA from surface-level requests to deep-rooted needs.
Each quadrant in the MHUI framework answers a specific question about the stakeholder’s situation. Together, they form a complete discovery map that goes beyond feature requests to uncover the real human and business needs driving the project.
| Quadrant | Focus | Key Question |
|---|---|---|
| M — Masalah | Root causes, pain points | What is really broken? |
| H — Harapan | Wants vs deeper needs | What do they truly need? |
| U — Usaha | Existing attempts, effort | What have they tried? |
| I — Ide | Co-creation, solutions | What could work together? |
MHUI is not a linear checklist — it is a flexible exploration framework. The skilled consultant-minded BA weaves between quadrants naturally during conversation, using each lens to deepen understanding before moving toward solutions.
Masalah is about understanding the true nature of the problem. Stakeholders often present symptoms as requirements. “We need a dashboard” might mean “I cannot see what my team is doing.” The consultant-minded BA resists the urge to accept the stated problem and instead investigates three categories of root cause:
Environmental: External factors beyond the stakeholder’s control — regulatory changes, market shifts, organizational politics, competitor moves. These create pressure but cannot be solved by software alone.
Systemic: Internal process, workflow, or system gaps — broken handoffs, manual workarounds, data silos, approval bottlenecks. Often this is where the BA can make the biggest impact.
Personal: Individual skill gaps, role confusion, fear of failure, lack of confidence, or political vulnerability. These are the most sensitive and the most important to uncover.
BA: “You mentioned you need a real-time dashboard. What tells you the current reports aren’t working?”
Stakeholder: “By the time I get the weekly report, it’s too late. We’ve already lost the opportunity.”
BA: “What kind of opportunity specifically?”
Stakeholder: “We had a campaign that underperformed last month. We only found out after it ended.”
BA: “So the real need is being able to make in-flight corrections to campaigns?”
Stakeholder: “Yes — exactly. Not just a dashboard. I need to be able to act, not just see.”
Harapan addresses the gap between what stakeholders say they want and what they actually need. Every request is a hypothesis about a solution. The consultant-minded BA treats it as such, exploring the need behind the request rather than simply documenting the requirement.
The classic 5 Whys technique is adapted here to distinguish wants from needs. Instead of asking why five times mechanically, the consultant-minded BA uses each “why” to peel back a layer of context:
Stakeholder: “I need a mobile app for our field agents.”
BA: “Why does it need to be a mobile app specifically?”
Stakeholder: “Our agents are always in the field. They never come to the office.”
BA: “What do they need to do that they currently cannot?”
Stakeholder: “They need to submit reports after each visit, but they wait until end of week.”
BA: “Why do they wait?”
Stakeholder: “The form requires desktop access — they cannot fill it on their phones.”
BA: “So the core need is a mobile-friendly report submission, not necessarily a full app?”
Stakeholder: “That would solve 80% of the problem, yes.”
Usaha uncovers what the stakeholder has already tried. Every attempt — successful or failed — reveals valuable information about effort invested, frustration accumulated, lessons learned, and the stakeholder’s commitment to solving the problem.
This quadrant is often skipped by conventional BAs, but it is one of the richest sources of insight. Stakeholders who have tried multiple solutions without success are often closer to the real problem than they realize.
BA: “Have you tried solving this problem before?”
Stakeholder: “We built a prototype last year. It never went live.”
BA: “What happened?”
Stakeholder: “We outsourced development. The vendor delivered something that didn’t match what we needed. We didn’t have clear requirements.”
BA: “What did you learn from that experience that could help us now?”
Stakeholder: “We need to be more involved in the design. We cannot just hand off a spec and hope for the best.”
Ide is about moving from requirements-gathering to solution co-creation. Instead of asking “what do you want” and walking away to design a solution, the consultant-minded BA invites the stakeholder into a collaborative design process where ideas are tested and refined together.
BA: “Based on our conversations, I think the real need is giving your team visibility into campaign performance while campaigns are running, not after. Is that accurate?”
Stakeholder: “Yes, that’s exactly right.”
BA: “Let’s think about how we could solve that. One option is a dashboard. Another could be automated alerts. A third might be a daily email summary. What resonates with you?”
Stakeholder: “I like the dashboard idea, but alerts would help my team act faster.”
BA: “What if we started with alerts and built a dashboard later for deeper analysis?”
Stakeholder: “That feels right. Let’s start there.”
E-Commerce • Senior Product Manager
Vika is a senior product manager at a mid-size e-commerce company (200+ employees, annual revenue ~$50M). She manages the merchant platform team and reports directly to the COO. Her team of 12 engineers and 3 designers is responsible for the tools that power the company’s 5,000+ merchant partners.
Her stated request: “I need a real-time dashboard with 15 KPIs.” She has already drafted a wireframe and a detailed specification document. The COO has approved the project budget. The engineering team has allocated 3 months for development.
A conventional BA would review the spec, confirm the 15 KPIs, document acceptance criteria, write user stories, and hand off to development. The project would deliver on time and on budget. Three months later, Vika would have her dashboard — but would she actually use it?
A consultant-minded BA pauses. Instead of accepting the spec, they explore: “Vika, you mentioned real-time. What happened recently that made real-time feel urgent?” The answer reveals that a major merchant threatened to leave after discovering a pricing error that went unnoticed for 3 weeks. Vika’s real need isn’t 15 KPIs — it’s early warning signals to prevent merchant churn.
Vika’s deeper driver is Level 5 (Status & Recognition). She was publicly blamed for the pricing error incident. A dashboard is her way of regaining control and demonstrating competence to the COO. The real solution involves just 5 critical alerts, not 15 KPIs — and early conversations with the COO about realistic monitoring expectations.
InsurTech • Claims Operations Manager
Rudi manages a team of 40 claims processors at a fast-growing insurtech startup. The company processes 15,000 claims per month. Rudi’s team manually enters claim data from PDF forms into the core system. He requests: “Automate the claims intake process using OCR and AI.”
He has already evaluated three OCR vendors and has a budget of $200,000. The CEO is supportive and wants this implemented within 6 months.
BA: “Rudi, you’ve done a lot of research on OCR vendors. What’s driving the urgency?”
Rudi: “My team is overwhelmed. We have a backlog of 2,000 claims. Processors are working weekends.”
BA: “What happens when claims are delayed?”
Rudi: “Regulators fine us for late payments. Last quarter we paid $50,000 in penalties.”
BA: “So the real priority is reducing processing time to avoid penalties?”
Rudi: “Yes. But also — my team is burning out. I’m losing good people.”
BA: “If we could reduce manual data entry by 60%, would that solve the bottleneck?”
Rudi: “That would be huge. But I also want to make sure my team feels supported, not replaced.”
Rudi’s needs operate at multiple levels: L2 (Pain Relief) — reducing penalties and team burnout; L4 (Autonomy) — regaining control over his operations and protecting his team. The solution is not full AI automation, but targeted OCR for the top 3 most error-prone fields, combined with workflow changes that reduce manual handoffs by 40%.
Digital Banking • Head of Digital Products
Ayu is Head of Digital Products at a challenger bank with 500,000 customers. Her team is responsible for all customer-facing mobile features. She requests: “Build a mobile app for micro-loans.”
The request seems straightforward. Competitors offer micro-loans. Customer surveys show demand. The executive team wants quick execution. Ayu has a budget of $500K and a target launch date of 4 months.
A conventional BA would run a competitive analysis, define features (application form, credit check, disbursement, repayment schedule), write PRDs, and start sprint planning. The app would launch on time with all promised features. Adoption would be moderate, but something would feel off.
The consultant-minded BA asks: “Why micro-loans, Ayu? What do you want this to mean for the bank?” The conversation reveals that Ayu recently presented at a fintech conference and felt embarrassed when competitors showed innovative products while her team had nothing new to showcase. Her real need is relevance and identity (L7 — Vision & Meaning). She wants the bank to be seen as innovative, not just functional.
The solution is not just a micro-loan app. Ayu needs a narrative of innovation that her team can own and the market can recognize. The consultant BA helps her reframe the project as a “financial inclusion platform” — where the micro-loan is just the first feature. This aligns with the bank’s mission, gives her team a compelling story, and attracts positive attention from regulators and investors.
BA: “If this micro-loan app succeeds, what does success look like for you personally, Ayu?”
Ayu: “I want people to see that this bank can lead, not just follow. I want my team to be proud of what we built.”
BA: “So it’s not just about loans — it’s about establishing your identity as an innovator?”
Ayu: “Exactly. I want us to be known for something.”
EdTech • Academic Director
Pak Budi is Academic Director at an online learning platform serving 100,000 students across Indonesia. The platform offers vocational courses in partnership with industry certifications. He requests: “Add gamification features — badges, leaderboards, and levels.”
He cites research showing gamification improves engagement. A competitor recently launched a gamification feature. His CEO is pushing for it. The engineering team estimates 2 months of work.
BA: “Pak Budi, what makes you feel gamification is the right solution?”
Pak Budi: “Our course completion rate is only 15%. Students start but don’t finish. Gamification worked for Duolingo.”
BA: “Have you spoken with students who dropped out to understand why?”
Pak Budi: “Not systematically. We assume it’s because the content isn’t engaging enough.”
BA: “What if the issue is not engagement but relevance — students don’t see how the course connects to their career goals?”
Pak Budi: “That’s a different problem entirely. But honestly, I worry our courses don’t make a real difference in students’ lives. That keeps me up at night.”
Pak Budi’s deeper need is meaning and contribution (L6 — Contribution, L7 — Vision). He doesn’t need badges — he needs evidence that his platform transforms lives. The consultant BA helps him design a “Career Impact Framework” that tracks job placement, salary increases, and student testimonials after course completion. Gamification is considered as a minor feature, not the core solution.
GovTech • Dinas Kominfo • IT Department
A provincial government IT department (Dinas Komunikasi dan Informatika) requests: “Build an integrated data dashboard for all SKPD (regional agencies).” The project is mandated by a new provincial regulation requiring data transparency across 25 agencies.
The IT department has attempted this project three times in the past 5 years, each time failing. Two vendors were fired. One internal project was abandoned. Total sunk cost: approximately $300,000.
BA: “I understand there have been previous attempts at this dashboard. What happened?”
Kepala Dinas: “Every agency has their own data format. Getting them to standardize is like pulling teeth. The last vendor built something that only worked for 3 agencies.”
BA: “What is the political pressure behind this project?”
Kepala Dinas: “The Governor promised this in his campaign. If we fail again, there will be consequences. My job might be on the line.”
BA: “So the real priority is showing progress and building trust, not necessarily a fully integrated system right away?”
Kepala Dinas: “Exactly. I need something to show in 3 months, even if it’s limited. And I need the agencies to feel included, not forced.”
The real needs are L2 (Safety & Security) — the Kepala Dinas fears losing his job — and L4 (Autonomy) — agencies resist being forced into a system they don’t control. The consultant BA proposes a phased approach: a lightweight data-sharing agreement first, a pilot with 3 willing agencies, and a public dashboard showing progress for just 5 key indicators. This reduces political risk and builds momentum.
In government projects, the real stakeholder is often not the person in the room — it is the political pressure they are responding to. Success requires understanding the ecosystem of power, trust, and fear that drives decision-making. Technical solutions alone cannot solve political problems.