There are plenty of articles that list dozens of "essential" tools for Business Analysts. Most of them give the impression that you need to master half the software market to do your job properly.
I prefer a different approach: start from the tools I use or would favor, understand what they concretely bring, and add the rest only when a real need justifies it.
So here is the stack I'd choose to work as a BA in 2026. It's not meant to be universal. The tools available to you, your company's constraints and your team's habits matter enormously. But if I had to start from scratch, this is where I'd begin.
The foundation: documentation and specs
1. Notion
Notion has become the center of gravity of my documentation. Functional specs, knowledge bases, workshop notes, decision tracking: everything can be centralized there.
What I like is its flexibility. You can organize it as a wiki, as a database or as a collaborative workspace. A BA can build a structure suited to their project without having to follow a rigid template.
And unlike a Word document shared somewhere on a server, documentation that's well organized in Notion is easy to find, to link to other pages and to evolve.
In practice, it can look like this:
One page per project, with the specs, the decisions made, their context and the questions still open.
A database to track user stories before they're moved into the backlog tool.
A knowledge base space to capture learnings from one project to the next: what worked, what got stuck and the pitfalls to avoid.
This organizational memory becomes even more valuable when a team grows or people change. You avoid rediscovering the same problems every six months.
Another benefit in 2026: the AI features available in Notion can help produce drafts, summarize long pages or reword specs without leaving your working environment. Their availability does depend on the plan you're on, though.
Who it's for: BAs who want to centralize their documentation in a modern, flexible tool.
Is it essential? No. If your company already uses Confluence, SharePoint or another properly structured tool, switching to Notion won't necessarily bring much. What matters is having documentation that is accessible, maintained and actually used.
Tracking: backlog and ticket management
2. Linear
For backlog management and tracking development work, Linear is my top choice when the team is free to pick its own tools.
It's an alternative to Jira that I find particularly pleasant day to day. The interface is fast, managing cycles and priorities is intuitive, and the experience feels lighter when you want to focus on the work rather than on configuring the tool.
Jira nevertheless remains very present in large companies, and for good reason: it can meet the tracking, governance and configuration needs specific to large organizations. If your team already works with Jira, it isn't necessarily worth trying to replace everything.
For a BA, what matters most is understanding where the user stories live, how the backlog is organized and how exchanges with the development teams are structured.
A backlog tool isn't just a list of tickets. It's also a space where needs get clarified, priorities get discussed and decisions are made visible.
Who it's for: product and tech teams who want a smooth backlog management experience. Linear is my choice if I get to decide. Otherwise, I'd rather master the tool the team has already adopted than create a parallel system.
Technical exploration: APIs and integrations
3. Postman or Bruno
Here's a category of tools you don't always find in lists aimed at Business Analysts, and that's precisely why it deserves a place here.
Postman and Bruno let you explore and test APIs. They're often associated with developers, but they're also very useful for a BA working on integration projects.
Why? Because there's a difference between reading what documentation claims an API returns and observing what it actually returns.
Documentation can be incomplete, outdated or fail to cover certain edge cases. By making a few calls, you can check the available data, see which fields are present, spot null values and identify some unexpected behaviors.
Let's take an example.
You receive the documentation for an API provided by a partner. Rather than relying solely on what's written and discovering the gaps in the middle of the integration phase, you prepare a few requests in Bruno or Postman. You look at the responses, compare the results with the documentation and note down the questions to clarify with the technical team or the partner.
This upfront exploration can save several back-and-forths and reduce the risk of starting from a wrong understanding of the need.
Bruno is notably interesting because it's open source and lets you store request collections locally, which can make it easier to version them alongside the rest of the project in Git.
There is, however, one important precaution: testing an API doesn't mean you can call any endpoint with any data.
You need the necessary access, you need to follow your organization's security rules and you need to use the right environment. In particular, tests must avoid affecting production data or triggering unwanted real-world operations.
Who it's for: BAs who work on integrations, data exchanges or products that include APIs. It's not mandatory for every BA, but it's a skill that can really make a difference.
The copilot: AI in your day-to-day work
4. Claude
It's hard to propose a BA stack in 2026 without talking about generative AI. But rather than simply saying "use AI," here's how I'd concretely build it into daily work.
For writing, AI can produce a first draft of specs, user stories, meeting notes or summary emails. You give it the material, it helps you structure the content, then you take back control to correct, clarify and validate.
For analysis, it can help synthesize user feedback, connect scattered pieces of information or work through voluminous technical documentation.
For technical exploration, it can also play the role of a teacher available at any time: explaining an API concept, helping you understand a snippet of code or clarifying the principles of an architecture.
My personal pick is Claude. But the most important thing isn't to choose the same tool as me. It's to find an assistant that fits your tasks, your constraints and the tools your organization allows.
The key caveat stays the same: AI is an accelerator, not a replacement for the BA's judgment.
A well-written text isn't necessarily correct. A user story can be elegant and still miss an essential business rule. A summary can seem coherent while missing an important contradiction.
So you have to check the results, bring the business context and challenge the suggestions. AI can speed up the work, but it doesn't carry responsibility for the decision.
You also have to respect confidentiality rules. Sensitive information, personal data and internal documents shouldn't be pasted into a tool without first checking that its use is authorized and suited to the sensitivity level of the data. The guarantees and terms of processing can vary depending on the tool and the plan.
Who it's for: any BA who can use an AI assistant in an appropriate setting. In 2026, seriously experimenting with these tools strikes me as a worthwhile investment. Not using them may mean missing out on some time savings, but the right approach also depends on your company's constraints and on the nature of the data you handle.
What's missing from this list, and why
You won't find a process modeling tool like Miro or Lucidchart here, nor an automation tool like Make or Zapier.
Not because they're useless. They can be very relevant. But their value depends heavily on context.
If your work involves a lot of visual modeling, a dedicated tool can become central. If you need to automate repetitive tasks or exchanges between applications, Make or Zapier may deserve a place in your stack.
I'd rather not add them to a baseline list just to make it look more impressive, though.
An additional tool has to solve a real problem. Otherwise, it mostly adds complexity, maintenance and one more environment to master.
These topics deserve their own analyses anyway, with concrete use cases rather than a simple catalog of features.
The stack at a glance
| Need | My top pick | Alternative or note |
|---|---|---|
| Documentation and specs | Notion | Confluence, SharePoint or whatever tool is already in place |
| Backlog management | Linear | Jira or the tool the team has adopted |
| API exploration | Bruno | Postman |
| AI copilot | Claude | An assistant that fits your use cases and your organization's rules |
Four tools. Not fifty.
The effective BA isn't the one with the most subscriptions or who knows the most software. It's the one who knows how to pick the right tools, master them well enough and use them to better understand needs, reduce ambiguity and make decisions easier.
How to build your stack gradually
No need to install everything at once. If I had to start from scratch, I'd build my stack around my real needs.
Step 1: documentation and AI.
Start with a documentation tool and an approved AI assistant. Notion and Claude would be my personal starting point.
The first helps structure information and keep a memory of the project. The second can speed up writing, help explore a topic and make some analysis tasks easier.
These tools are complementary, but they only create value if you know what you're trying to document or understand.
Step 2: the team's backlog tool.
When you work with a development team, learn to use its tracking tool. Linear if that's the team's choice, Jira if that's the organization's, or another solution if it already meets the need.
A backlog is only valuable if it's adopted collectively. An extra personal tool won't fix a coordination problem if nobody else uses it.
Step 3: API exploration.
Add Postman or Bruno when you're working on a project that involves integrations.
It's the best time to learn: you have a real API in front of you, specific questions to resolve and concrete results to compare against the documentation.
No need to master every feature of the tool. Start by knowing how to send a request, read a response and identify the information that's useful for your analysis.
So the right order isn't to collect software before you have a need. It's to run into a problem, then learn to use the tool that helps you solve it better.
Going further: when you want to cross over to the dark side of tech
The following tools aren't essential for every BA. But if you want to better understand the technical environment you work in, they're good directions for growth.
GitHub
GitHub is a platform used by many teams to host code and collaborate on its evolution. As a BA, you don't need to know how to code to get value from it.
Knowing how to navigate a repository, read a Pull Request or understand what a commit changes gives you an extra window into the technical team's work.
You can better understand what's changing, follow the evolution of a feature and ask more precise questions when you look at a gap between the need and what's being built.
That doesn't mean reading a Pull Request is enough to validate a feature. Code can be technically correct without meeting the business need, and functional validation is still necessary.
The goal isn't to become a developer. It's to reduce the distance between what you analyze and what the team builds.
Swagger / OpenAPI
When an API is documented in the OpenAPI format, its specification describes, among other things, its endpoints, its parameters and the expected responses.
Swagger is a set of tools that let you, among other things, visualize and explore these specifications interactively.
For a BA, knowing how to read an OpenAPI specification helps you understand what an API is meant to allow, which parameters are available and which responses are documented.
It's the natural complement to Postman or Bruno: the documentation on one side, the real calls on the other.
A word of caution, though: documentation isn't automatically complete or up to date. You still need to compare what it describes with the observed behavior and clarify the gaps with the technical team.
SQL: just the basics
No need to become a DBA.
But knowing how to write a simple SELECT query, filter data, join two tables or count occurrences can open up new possibilities.
You can check certain data, explore a result set or prepare an analysis without systematically depending on a developer for every question.
The benefit obviously depends on your context: data access, available permissions, the complexity of the model and how often you need analysis. The first basics can be learned fairly quickly, but gaining autonomy on real data takes practice.
In my view, SQL is one of the technical skills a BA looking to strengthen their autonomy should seriously consider.
The real topic isn't the stack
At the end of the day, tools don't make the profession.
Notion doesn't guarantee good documentation. Linear doesn't guarantee a clear backlog. Postman doesn't guarantee a good understanding of an integration. Claude doesn't guarantee a correct analysis.
What makes the difference is how you use these tools: the questions you ask, the assumptions you verify, the information you keep and the decisions you help make.
A simple stack, well mastered and suited to your environment, is often worth more than a collection of sophisticated tools used halfway.
And you, which tools do you really use in your day-to-day BA work? Which ones save you time, and which ones mostly seem to add complexity?
Reply directly to this email. I'm curious to know what works in other contexts.
Subscribe to the newsletter to regularly receive analyses, concrete tools and prompts you can use right away in your day-to-day BA work.