← Business and Systems Analysis from Scratch
Lesson
What the analyst is NOT: problem vs solution and common myths
The learner can separate a problem statement from a proposed solution and recognize the limits of the role, debunking myths such as 'the analyst just writes documents' or 'the analyst decides what to build'.
Problem vs solution — and what analysts are not
Don't bake the solution into the need
One of the most common traps in requirements work is confusing a problem with a proposed solution. A problem statement describes a gap between the current state and a desired state: 'Our sales team cannot see customer purchase history during a call, which causes them to repeat questions the customer has already answered.' A solution statement describes a specific way to close that gap: 'We need a CRM module with a customer timeline view.' The analyst's job is to hold the problem statement open long enough to explore it properly — because the right solution might not be the first one suggested.
When a requirement arrives already dressed as a solution ('We need a dashboard'), the analyst should ask: 'What is the underlying need this dashboard would satisfy?' This unlocks better options and prevents building something that technically meets the stated request but misses the actual problem.
Several myths about the analyst role persist in organizations. Myth 1: 'The analyst just writes documents.' In reality, documentation is only one of four core activities; eliciting and validating requirements often take more time. Myth 2: 'The analyst decides what to build.' The analyst clarifies options and trade-offs; the business decides. Myth 3: 'Any smart person can do analysis without training.' Requirements work has proven techniques, and skipping them leads to rework, scope creep, and project failure. Myth 4: 'The analyst only talks to the client, then throws requirements over the wall.' Good analysts stay engaged through delivery — clarifying, re-validating, and catching drift early.
The anti-pattern of jumping straight to a solution — sometimes called 'solutionizing' — is expensive. It narrows the solution space before the problem is understood, making it easy to build the wrong thing perfectly.
Lesson notes
Don't bake the solution into the need
One of the most common traps in requirements work is confusing a problem with a proposed solution. A problem statement describes a gap between the current state and a desired state: 'Our sales team cannot see customer purchase history during a call, which causes them to repeat questions the customer has already answered.' A solution statement describes a specific way to close that gap: 'We need a CRM module with a customer timeline view.' The analyst's job is to hold the problem statement open long enough to explore it properly — because the right solution might not be the first one suggested.
When a requirement arrives already dressed as a solution ('We need a dashboard'), the analyst should ask: 'What is the underlying need this dashboard would satisfy?' This unlocks better options and prevents building something that technically meets the stated request but misses the actual problem.
Several myths about the analyst role persist in organizations. Myth 1: 'The analyst just writes documents.' In reality, documentation is only one of four core activities; eliciting and validating requirements often take more time. Myth 2: 'The analyst decides what to build.' The analyst clarifies options and trade-offs; the business decides. Myth 3: 'Any smart person can do analysis without training.' Requirements work has proven techniques, and skipping them leads to rework, scope creep, and project failure. Myth 4: 'The analyst only talks to the client, then throws requirements over the wall.' Good analysts stay engaged through delivery — clarifying, re-validating, and catching drift early.
The anti-pattern of jumping straight to a solution — sometimes called 'solutionizing' — is expensive. It narrows the solution space before the problem is understood, making it easy to build the wrong thing perfectly.