Requirements Engineering Without a Dedicated BA: How I Make It Work
Most of the teams I've worked with couldn't afford a dedicated Business Analyst. At a startup, "BA" is whoever is willing to stay in the room until the requirements are clear — usually the PM, the most senior engineer, and whoever from the business side has the most patience.
This isn't a failure mode. It's the normal operating condition for most software organizations below a certain scale. What it requires is a PM who can do BA work well enough that the absence of a dedicated specialist isn't the thing that sinks the project.
Here's how I approach it.
The Fundamental Shift: Outcomes Over Solutions
The most common failure mode in requirements gathering without a BA is that the PM collects solutions rather than requirements.
Business stakeholders are problem-solvers. When they come to a requirements conversation, they've usually already solved the problem in their head — they've just solved it in business terms, not technical ones. "We need a dashboard" is a solution. "We need to stop being surprised in steering committee meetings" is a requirement.
The question I use to force this: "If this works exactly as you're imagining it, what's different about your work six months from now?" The answer to that question is almost always closer to the actual requirement than anything that preceded it.
My Lean Framework
Discovery — before anything is written
I run structured conversations with stakeholders focused on three things: what they're doing today that they shouldn't have to do, what they're afraid of if nothing changes, and what success looks like to them specifically. No requirements are captured at this stage. I'm building a model of the problem.
I also try to understand who else has a stake in this. Requirements captured from one stakeholder in a multi-stakeholder environment are requirements that will surprise someone later.
Translation — from outcomes to specifications
Once I have a model of desired outcomes, I translate them into structured specifications: user stories with explicit acceptance criteria, supplemented by wireframes or prototypes for anything with a UI component, and data models or flow diagrams for anything involving data transformation.
The wireframe step is often skipped when there's no dedicated designer. I've found it's almost always worth doing anyway — even rough sketches — because visual representations of system behavior surface misunderstandings that text descriptions don't.
Validation — before engineering starts
Before a single line of code is written, I walk through the specifications with both the business stakeholder and an engineering representative in the same session. My explicit goal: verify that the document means the same thing to everyone in the room.
It rarely does, on the first pass. That's the point.
The Tools That Help
• Figma for wireframes and prototypes — stakeholders can interact with prototypes in ways that expose requirements gaps that static specifications miss • User story mapping for complex features with multiple user types • Given / When / Then format for acceptance criteria — forces specificity; requirements that can't be expressed in this format usually aren't specific enough yet
What to Watch For
A few patterns that indicate requirements work isn't done yet:
Passive voice in acceptance criteria. "The report will be generated" — by what? When? Passive voice usually means someone hasn't made a decision yet.
Superlatives without metrics. "The system should be fast" means nothing. "The page should load in under 2 seconds" means something. Any requirement with "fast," "easy," or "intuitive" in it needs to be decomposed until those words are replaced by measurements.
Requirements that specify implementation. "The data should be stored in PostgreSQL" is usually an engineering decision, not a requirement. When requirements specify implementation details, they're encoding assumptions that should be made explicit and challenged.
The Honest Limitation
Working without a dedicated BA has a real cost that process can reduce but not eliminate: the PM doing BA work is context-switching between two cognitively demanding modes. The way I manage this is to time-box them. Requirements work happens in concentrated blocks. When I'm in requirements mode, I'm not fielding status update requests.
It's an imperfect solution to a real constraint. Most solutions in this job are.