Business Analyst

As your analytical partner, I focus on making complex work clear, structured, and actionable. I translate ideas, constraints, and stakeholder needs into well-defined problems, scenarios, and requirements that teams can confidently design and build against.

My approach is collaborative rather than directive: I work alongside product, design, and engineering to surface assumptions, validate intent, expose risks early, and keep everyone aligned on what we are actually solving. Whether shaping scope, testing feasibility, or clarifying decision points, my aim is to reduce ambiguity and support the team with analysis that is grounded, technically aware, and genuinely useful.

The core of my practice includes:

  • Bridging conversation and implementation through precise, testable specifications
  • Requirements gathering that uncovers intent, constraints, and dependencies
  • Scoping and prioritisation aligned with both business goals and system realities
  • Stakeholder alignment across product, design, engineering, and operations
  • Developing user stories and use cases that reflect real user behaviour
  • Extracting business rules, acceptance criteria, and test scenarios that reduce ambiguity
  • Supporting Agile delivery through cross-functional collaboration
  • Applying systems thinking to find clarity in complexity
  • Documentation and modelling that make decisions explicit and traceable

Tech-Agnostic Requirements Informed by Technology

I write requirements that are tech-agnostic in form, but informed by deep technical understanding in substance.
The neutrality prevents premature solutioning.
The technical awareness prevents unrealistic or incoherent scope.
The space between the two is where good decisions happen.

There’s a persistent tension in the BA role: you’re expected to write requirements that are tech-agnostic, while also being expected to understand the technical landscape well enough to avoid proposing unbuildable or inefficient solutions.

This isn’t a contradiction; it’s part of the work.

Why the Paradox Exists

Teams want:

  • requirements that don’t prematurely constrain engineering
  • room for developers to choose the right implementation
  • clarity on what the system must do from a business and user perspective
  • confidence that the solution is technically realistic

So a BA can’t prescribe the implementation — but also can’t be naïve about the implementation context.

How I Navigate This in Practice

I treat “tech agnosticism” not as the absence of technical understanding, but as the separation of intent from implementation.

In practice:

  1. I keep the problem definition, rules, and acceptance criteria neutral
    • they describe behaviour, outcomes, states, and constraints
    • not data structures, endpoints, or architecture
  2. But I use technical understanding to shape those neutral definitions
    — spotting assumptions that won’t hold
    — avoiding requirements that cause system debt or unnecessary complexity
    — framing scenarios in ways that map cleanly to how the system actually works
    — validating that the scope aligns with the platform’s capabilities
  3. I avoid “solutioneering,” but I don’t avoid technical influence
    — I don’t dictate how to build it
    — but I ensure the requirements don’t inadvertently push engineering into a corner
  4. I surface options, constraints, and trade-offs early
    — without picking a winner
    — so product, design, and engineering can make an informed decision together

It’s a balancing act: neutral on paper, but technically aware in approach.

Why This Tension Is Not a Problem — It’s the Job

There’s often an unspoken message to BAs:

  • “Don’t design.”
  • “Don’t choose technology.”
  • “Don’t specify solutions.”
  • “Don’t overstep engineering.”

But at the same time:

  • If you don’t understand the design constraints, you create invalid flows.
  • If you don’t understand the system, you write requirements that break architecture.
  • If you don’t understand the data, your acceptance criteria won’t be testable.
  • If you don’t understand the technical trade-offs, you create unintentional debt.

So the job isn’t to be less technical, it’s to be technical in the right way. A business Analyst seeks to outline a position where clarity is created not by choosing solutions, but by:

  • understanding what the system can currently do
  • understanding what the business needs it to do
  • understanding what designers intend it to do
  • and articulating the intersection in a way that preserves flexibility
    while minimising ambiguity

I don’t position myself as a designer, product owner, or engineer – but I work in close proximity to all three. Throughout my career I have performed all those roles and am familiar with the requirements for them all.

My contribution is:

  • structuring intent so designers can explore valid options
  • defining behaviours and states engineering can implement cleanly
  • translating technical constraints into business-meaningful trade-offs
  • ensuring requirements don’t accidentally predetermine architecture
  • keeping a coherent thread across all three perspectives

The tension is not a flaw; it’s the mechanism that keeps the work grounded and feasible.