From Scribe to Consultant — Sharing Session Series
Research consistently shows that 60-70% of software projects fail to meet stakeholder satisfaction — not because of technical issues, but because of misunderstood requirements. The Standish Group's CHAOS report has been telling us this for decades. But the problem isn't the requirements — it's how we discover them.
The failure is not in documentation. It's in discovery. When a client says "I need a dashboard," they're not giving you the requirement — they're giving you a symptom. They're telling you about a problem they've already attempted to solve in their head, and the solution they landed on is a dashboard. Your job is not to document the dashboard. Your job is to discover what problem the dashboard is supposed to solve.
A physician doesn't prescribe antibiotics when a patient says "I have a fever." They investigate: What kind of fever? How long? Any other symptoms? What's the infection? The BA equivalent is accepting "I need a dashboard" as the final requirement instead of the starting point.
The typical BA approach follows a familiar pattern:
This scenario plays out so often that we've normalized it. We call it "scope creep," "unclear requirements," or "client doesn't know what they want." But the truth is more uncomfortable: we didn't ask the right questions.
The real cost of surface-level BA work:
The shift from scribe to consultant begins with two questions. These questions are the foundation of everything else you'll learn in this series. They seem simple — almost too simple — but they are the most powerful tools in a consultant-minded BA's toolkit.
This question sounds obvious, yet most BAs never ask it directly. Instead, they hear "I need X" and immediately start documenting X. The problem is that the client has already done the solution design in their head — and they're probably wrong.
When you ask "what problem are you trying to solve?" you:
This question reveals the client's true success criteria — which are often different from what they initially describe. A client who says "I need a dashboard" might reveal that success means "my team stops asking me for status updates" — a problem that could be solved in many other ways.
When you ask "how will you know this is successful?" you:
Together, these two questions shift the conversation from solutions to outcomes. They turn a feature request into a discovery conversation. They change your role from "documenter" to "investigator." And they give you the foundation for everything else: the Iceberg Principle, the 7 Levels of Needs, and the communication stances you'll learn in later sessions.
A BA who consistently asks these two questions will never again build the wrong thing — because they'll understand the real problem and the true definition of success before a single line of code is written.
Before we dive deeper, let's take stock of where you are right now. The following self-assessment measures your current BA mindset along the dimensions that matter most for the consultant approach. Rate each statement honestly — there are no wrong answers, only a baseline to measure your growth against.
| # | Statement | Score (1-5) |
|---|---|---|
| 1 | When a client makes a request, I ask "what problem are you trying to solve?" before documenting the request. | |
| 2 | I regularly challenge stakeholders' assumptions about what they need. | |
| 3 | I look for emotional cues (frustration, excitement, hesitation) during requirements conversations. | |
| 4 | I distinguish between what a client says they want and what they actually need. | |
| 5 | I feel comfortable asking "why" multiple times to get to the root of a request. | |
| 6 | I consider the human needs (recognition, autonomy, belonging) behind feature requests. | |
| 7 | I spend more time on discovery than on documentation. | |
| 8 | I help clients articulate success criteria in measurable terms. | |
| 9 | I see myself as a consultant and investigator, not a scribe or order-taker. | |
| 10 | I proactively look for the story behind the requirement — the context, the people, the history. |
The Iceberg Model was developed by Virginia Satir (1916-1988), a pioneering American family therapist and author. Satir believed that human behavior — what we can see on the surface — is only a small fraction of what drives us. Beneath the surface lies a vast complex of emotions, perceptions, expectations, and deep human longings that shape every interaction.
Satir's insight was that you cannot change surface behavior without addressing what lies beneath it. This principle applies directly to BA work: a client's feature request (surface behavior) cannot be properly addressed without understanding the needs, fears, and aspirations beneath it.
Only about 10% of an iceberg is visible above the waterline. The remaining 90% — massive, powerful, and often dangerous — is hidden beneath the surface. In BA conversations:
Traditional BA training focuses entirely on the 10% above water. The consultant-minded BA learns to explore the 90% below.
Traditional requirements gathering treats the client as a source of information to be extracted. The consultant-minded BA treats the client as a person to be understood. This shift is not about being "soft" — it is about being more effective. When you understand the full iceberg, you design solutions that address the real need, not just the surface request.
The Satir iceberg model identifies several layers beneath the surface. Each layer represents a deeper level of human experience. For BAs, understanding these layers helps us know what kinds of questions to ask and what to listen for.
1. Behavior (Above Water): What the client says and does — the feature request, the complaint, the demand.
2. Coping: How the client has learned to deal with the situation — workarounds, manual processes, avoidance.
3. Feelings: The emotions beneath the request — frustration, anxiety, embarrassment, fear of failure.
4. Perceptions: How the client sees the situation — beliefs about what's possible, assumptions about technology, views on their own team.
5. Expectations: What the client expects from you, from the project, from themselves — often unspoken and often contradictory.
6. Yearnings: Deep human desires — to be heard, to be competent, to be respected, to be safe, to make a difference.
7. Self: Identity — "Who am I in this situation?" The client's sense of their own role, worth, and capability.
Each layer informs the one above it. A client's coping mechanism (workaround) is driven by feelings (frustration), which are shaped by perceptions (I can't change this), which stem from expectations (IT should fix this), which connect to yearnings (to feel competent), which touch on identity (I'm a professional who delivers results).
When you understand these layers, you don't just understand the requirement — you understand the person. And when you understand the person, you can design solutions that actually work for them.
Building on the Iceberg Principle, we can map feature requests to a hierarchy of human needs in the BA context. This framework helps you identify which layer of need a given request is addressing.
BA response: Don't document. Probe. "What happens when you click that button? What comes before? What comes after? Who else is involved?"
BA response: "How often does this happen? What's the impact on your work? How does it affect your team?" The real need is not "fix the crash" — it's "I need to trust the system I rely on."
BA response: "Walk me through the current process. Where do you get stuck? What would make this feel smooth?" The real need is competence — "I want to do my job well without fighting the tool."
BA response: "What decisions do you need to make independently? What's blocked? What would freedom look like?" The real need is not "more permissions" — it's "I need to feel capable and trusted in my role."
BA response: "What does having this feature signal to your market? To your leadership? To your team?" The real need is often identity — "I want to be seen as innovative/competent/modern."
BA response: "What does collaboration look like today? What's missing? How would this change your team dynamics?" The real need is relatedness — "I want to feel connected to my colleagues and contribute meaningfully."
BA response: "What impact would this have on your customers? On your industry? On you personally?" The real need is transcendence — "I want my work to matter beyond the quarterly report."
When a client makes a request at L1, the BA's job is to explore down through the levels to find the real need. Most of the time, the real need is at L4-L7. The feature request at L1 is just the client's best guess at how to satisfy that deeper need.
Knowing the iceberg layers is one thing — knowing how to ask about each layer is another. The art of the consultant-minded BA lies in framing discovery questions that gently guide the client deeper beneath the surface.
Below are example questions for each layer. Use these as a starting point, not a script. The key is to listen to the client's response and follow the thread they give you — not mechanically work through a checklist.
Behavior (Above Water): "Walk me through what happens today. What exactly are you trying to do?"
Coping: "How have you been dealing with this so far? What workarounds have you put in place?"
Feelings: "How does this situation make you feel? What's the most frustrating part of this for you and your team?"
Perceptions: "How do you see this situation? What do you think is causing this? What have you tried before?"
Expectations: "What do you expect this solution to do for you? What would a good outcome look like from your perspective?"
Yearnings: "What would this solution mean for you personally? What difference would it make in your day-to-day work?"
Self: "How does this situation connect to your role and your goals? What kind of professional do you want to be in this context?"
The most important skill is knowing when to stop probing a layer and when to go deeper. If a client gives you an emotional response ("I'm so frustrated because I can't do my job"), follow the feeling — don't jump back to behavior. If a client stays analytical, meet them there. The goal is not to force depth but to create space for it.
There is a fine line between probing and interrogating. If a client feels like they are being interviewed for a crime, they will shut down. Your tone matters: stay curious, not clinical. Use phrases like "help me understand" and "I'm curious about" instead of "explain" or "justify." The difference is the difference between a consultant and an interrogator.
One of the most powerful shifts a consultant-minded BA makes is moving the conversation from features (what the system will do) to outcomes (what the user will achieve). This shift changes everything — the questions you ask, the solutions you consider, and the value you deliver.
Feature-focused language is about specifications. Outcome-focused language is about results. Compare the two approaches:
When you reframe features as outcomes, several things happen:
For your next feature request, take every "I need [feature]" statement from the client and rewrite it as "The goal is to [outcome]." Then show the client both versions and ask: "Which one feels more true to what you're trying to achieve?" The answer will almost always be the outcome version — and it will open a much richer conversation.
The 5 Whys is a root cause analysis technique originally developed by Sakichi Toyoda and used by Toyota Motor Corporation as a critical component of their problem-solving methodology. Despite its simplicity — ask "why" five times to get from symptom to root cause — it is remarkably powerful when applied to BA discovery.
In BA work, the 5 Whys helps you move from a surface-level feature request to the deeper need. Each "why" peels back one layer of the iceberg, moving you from Behavior toward Self.
Let's take the classic example — "I need a dashboard" — and run it through the 5 Whys:
In just five questions, we moved from "I need a dashboard" (Behavior/L1) to "I want to be seen as competent and in control" (Self/L5-L7). The solutions that emerge from this understanding are radically different and more targeted than simply building a dashboard.
Apply what you've learned to these three scenarios. For each one, read the context and the client's stated request, then answer the questions. Write your answers in a notebook or discuss with a colleague.
Questions for reflection:
Questions for reflection:
Questions for reflection:
This comprehensive self-assessment measures your readiness to apply the Iceberg Mindset in your daily BA work. Rate each statement on a scale of 1 (Strongly Disagree) to 5 (Strongly Agree). Be honest — this is for your own development, not for anyone else.
| # | Statement | Score (1-5) |
|---|---|---|
| 1 | I consistently ask "what problem are we trying to solve?" before discussing solutions. | |
| 2 | I can identify when a stakeholder is proposing a solution rather than describing a problem. | |
| 3 | I actively look for the emotions behind a stakeholder's words during discovery conversations. | |
| 4 | I understand the 7 Levels of Needs and can identify which level a request is addressing. | |
| 5 | I use the 5 Whys technique (or a similar method) to uncover root causes. | |
| 6 | I distinguish between feature requests and outcome statements in my requirements documentation. | |
| 7 | I help stakeholders define success in measurable terms before defining scope. | |
| 8 | I am comfortable probing beneath a stakeholder's stated request without damaging the relationship. | |
| 9 | I design questions based on the iceberg layer I want to explore. | |
| 10 | I see my role as uncovering real needs, not just documenting requirements. | |
| 11 | I consider the human needs (recognition, autonomy, belonging) behind every feature request. | |
| 12 | I can reframe a feature-focused conversation into an outcome-focused conversation. |
The defining shift from scribe to consultant is understanding that every feature request is a symptom of a deeper need. The iceberg model gives you a framework to explore that depth systematically.
Functional (L1) through Meaning (L7). Most surface requests live at L1-L3. The real need is almost always at L4-L7. Your job is to ask the questions that take you deeper.
In Session 2, you'll dive deeper into the 7 Levels of Needs with a more detailed framework and practical tools for mapping requests to needs. In Session 3, you'll apply the MHUI model (Motivation, Hopes, Uncertainty, Identity) to real-world case studies. And in Session 4, you'll master the 5 Communication Stances that complete the consultant transformation.
Share one insight from this session with a colleague before Session 2. Teaching is the fastest path to mastery.