Your first week in a startup after years in a large company, you go looking for the templates. The documentation repository. The spec validation process. The person in charge of governance.
They don't exist. Or if they do, nobody really knows where they are, or whether anyone has used them lately.
It's both scary and incredibly exciting. Welcome to being a BA in a startup.
Speed, first
In a large company, a decision can go through several levels of validation, committees and reviews. In a startup, the same decision can sometimes be made in ten minutes in a Slack thread or around the coffee machine. What seemed to require three weeks of process can be settled in an afternoon.
At first, it's unsettling. You instinctively look for safeguards, sign-offs and people to align. Then you realize that things work differently, and that it's often up to you to take the initiative to move forward. You have to unlearn the reflex of waiting and learn the reflex of acting.
This speed is powerful fuel. It shortens the distance between analysis and impact: what you define in the morning can be in production a few days later. You see the result of your work quickly and concretely. A luxury that can feel rare when you've been through eighteen-month projects in a large organization.
But that same speed has a downside.
Fast decisions are sometimes made with little perspective, little documentation and little thought for the medium-term consequences. A solution that works today can create new constraints tomorrow. A convenient choice made under pressure can become hard to question once the product grows.
A BA in a startup quickly learns to strike a balance between moving fast enough not to kill the momentum and stepping back enough not to create problems you'll pay for later.
The goal isn't to slow down for the sake of better documentation. It's to know when to move immediately and when a few extra questions can save a lot of work down the road.
Having no process: freedom or ticking time bomb?
No mandatory templates, no governance committees, no methodology office checking that your deliverables comply. In a startup, you do things the way you think is right.
It's a real freedom and, for someone who likes to build, a rare opportunity.
But this absence of process has an expiry date.
When the team is small and everyone talks to each other every day, a lack of formalization isn't necessarily a major problem. Everyone more or less knows what's going on, adjustments happen naturally and information flows easily.
The problem appears when the organization grows.
A team of five can run on informal conversations. At twenty, some things start slipping through the cracks more often. At fifty, depending on the organization and the complexity of the product, the lack of structure can seriously complicate the work.
Decisions made verbally a year ago are no longer interpreted the same way by everyone. Newcomers have no reference to understand how things work. Essential information stays in the heads of a few people, who become mandatory checkpoints in spite of themselves.
It's often at that point that you realize you should have documented earlier.
The same thing happens on the technical side, and it's even more insidious.
In the beginning, the founding developer knows their codebase inside out. They know why a given piece of code was written that way, for which customer and with which constraints in mind. A good part of that knowledge stays in their head, and as long as the team is small, that may be enough.
But as the product evolves, business specificities multiply, edge cases become intertwined and technical choices get harder to understand without their original context.
A change can then have an unexpected effect on an existing feature. Onboarding a new developer becomes more complicated. Debugging an unexplained behavior can turn into an archaeological investigation.
The problem isn't simply the number of lines of code. It's the accumulation of decisions, dependencies and business rules whose logic is no longer sufficiently documented or shared.
This is where the BA can play a role that is often underestimated: not only documenting business processes, but helping preserve the link between what the product does and why it does it.
Why does this business rule exist? Why is this edge case handled differently? What constraint led to this decision? What is likely to happen if we change this behavior?
The BA doesn't carry sole responsibility for the product's technical memory. It's a collective effort with developers, product owners and the other people involved. But they can help make explicit part of that knowledge which, otherwise, risks disappearing.
The most valuable BA in a startup is the one who understands this paradox and knows how to find the right dose: enough structure for the organization to last, not so much that it kills the speed that is its strength.
The hats nobody told you about
In a startup, the BA doesn't just do BA work. It's a reality you often discover on arrival, rather than by reading a job description.
Defining processes from scratch
There's no existing process to analyze and improve. Sometimes you have to create them.
How do we handle incoming requests? How do we prioritize development? How do we document product decisions? Who signs off on what? How do we make sure everyone has access to the same information?
These questions often sit in a blind spot of the organization. And it's frequently the BA who ends up taking them on, because they're well placed to spot the friction and the gaps.
In a startup, execution is often what works best: we ship fast, we iterate, we keep moving. But what's sometimes missing is the layer that comes next: quality, standardization and industrialization.
We've built something that works for ten customers. Will it hold up at a hundred?
The edge cases handled by hand at the beginning: how do we structure them so they no longer depend on a single person? The customer onboarding that relies on one colleague's expertise: how do we document it so a newcomer can reproduce it? The delivery process that works because everyone knows each other: how do we formalize it so it survives the growth of the team?
These are questions the BA can help raise before they become urgent problems. Not to slow the team down, but to make sure that what has been built can be repeated, controlled and improved.
Moving from craft to industrialization without losing the speed that makes a startup strong is one of the most interesting challenges of the job. And this work isn't always explicitly assigned to anyone.
It's an intellectually stimulating exercise, but one that requires a different stance from classic analysis. You're no longer just describing what exists. You're building something that didn't exist yet.
Getting your hands dirty with the tech
This one, nobody always tells you about in job descriptions.
In a startup, the boundary between BA and technical role can be porous. You may find yourself exploring APIs, understanding data structures, testing integrations and talking with developers about topics where you need to have a technical opinion to move forward.
Concretely, it means being able to read an API response and understand what it contains, without needing a developer to walk you through it end to end.
It means understanding why an integration flow needs three calls rather than one, and what that implies in terms of performance or error handling.
It also means being able to reproduce a bug in a test environment, read an error message and extract the useful information from it before going to the tech team.
Not to do the developer's job, but to show up with a problem already diagnosed rather than a vague description of unexpected behavior.
It isn't development, and you don't necessarily write code. But you need to understand how the product works well enough not to be a mere messenger between the business and the tech side.
The level of technical proximity expected depends on the startup, the product and the makeup of the team. In some contexts, this skill becomes especially valuable, particularly when integrations are numerous and teams have little time to dig into each request.
A BA who masters this dimension can quickly become a go-to person for both sides. Someone who understands both the business and technical constraints, without having to belong to one camp rather than the other.
What a startup teaches you that a large company can't always teach you in the same way
A startup teaches you to build something from nothing and to own the consequences of your choices quickly.
There are sometimes fewer hierarchical levels to validate your decisions, fewer processes to frame your work and less room to wait until all the conditions are met. You learn to trust yourself, to test and to adjust.
You also discover a philosophy particularly suited to this environment: test & learn.
Rather than spending weeks, sometimes months, analyzing, scoping, validating and revalidating before touching anything, the team can choose to quickly test a hypothesis. It builds an imperfect version, puts it in the hands of real users, observes what happens and adjusts.
Learning comes from the field, not only from slides.
That doesn't mean you should do away with upfront analysis. It's more about focusing the effort on the questions that really matter, then confronting hypotheses with reality as early as possible.
In large companies, I've seen some projects spend months in scoping, with dozens of meetings and an approved budget, before a proof of concept made it possible to concretely check certain technical or functional hypotheses.
When this confrontation with reality comes late, correcting course can become expensive.
In a startup, resources are often limited and uncertainty is high. Testing early can therefore be an effective way to avoid investing too long in the wrong direction.
We test, we learn, we sometimes fail, then we start again.
You also learn to communicate differently.
In a large company, you can spend hours preparing well-structured presentations and organizing meetings where decisions don't always move forward as much as planned.
In a startup, you sometimes have to grab five minutes of attention from someone who is already running off to something else, then convince them in a few sentences.
Not necessarily a context slide or a long recap of previous decisions. You come with your point, explain it, propose a direction and leave with an answer, if conditions allow.
Clarity of thought is no longer just a nice quality to have. It becomes a particularly useful skill for getting things moving.
Finally, you learn to look at the product as a whole.
Because teams are often smaller and responsibilities overlap more, you may find yourself exploring several dimensions of the product, from business processes all the way to technical integrations.
This closeness fosters systems thinking. You get a better sense of how decisions made in one place can affect the rest of the product and the organization.
It's not impossible in a large company, but siloed teams can make this view harder to build.
So a startup exposes you to another way of working. It teaches you to move forward amid uncertainty, to take initiative and to adapt your level of structure to the situation.
And that's probably where the main lesson lies: it's not about choosing between speed and rigor, but about learning to find the right balance between the two.
What's next
These two articles, large company and startup, present two contexts in which a BA can work. Neither is perfect, and each develops different skills.
In the next article, we'll talk about what is transforming both: AI, and how it could change the Business Analyst role.
Are you a BA in a startup, or thinking about making the jump? Subscribe to the newsletter to regularly receive analyses, practical tools and field stories on how the profession is evolving.