Technical Business Analyst

About the role

Worth knowing before you apply, because you will meet all of it in your first month.

You support pods, not a single manager's queue. Product managers and engineers

are both your customers, and they will want different things on the same day. So will

real customers!

You have no authority to assign work. Nobody here does. Your influence comes

entirely from the quality of your context and the clarity of your case, which is either

the best part of this job or the wrong job for you.

The domain has depth and complexity. Insurance requirements vary by trade, scope

of work, and state. Compliance rules vary by customer. You will not be able to reason

about our data without learning the domain, and we will give you time to learn it.

Our documentation is uneven. Some things are written down. Many are not, and

finding out is the work rather than a blocker to it.

We are a small company post-acquisition and still forming. Your work is visible, and

so are the gaps you close.

What you'll do

If AI drafts the tickets, the quality of what gets built is decided by the context it

receives. That context is what you’ll optimize.

Understand and write down how the platform actually behaves today - the

workflows, the exception paths, the rules, and the undocumented behavior currently

living in people's heads.

Build and maintain the reference material that our AI tooling and our engineers pull

from, and keep it accurate as the product changes. Stale documentation now

produces bad tickets and bad code automatically, at scale.

Review tickets and specs against reality before anyone builds them. This is the part

that matters most: AI-generated work is confidently wrong exactly where it costs the

most - edge cases, compliance rules, customer-specific commitments, anything that

is not in the repo or the training data.

Capture acceptance criteria, edge cases, failure behavior, and explicit non-goals so a

pod can pick something up and build it without a meeting.

Qualifications

3+ years as a business analyst, technical analyst, product analyst, data analyst,

or in product operations, working closely with engineers.

● Strong SQL. You write your own queries against a real schema, you

understand what a join is doing to your row count, and you sanity-check your

results before presenting them.

● You can read a database schema and work out how a product behaves from it.

● You already work with AI as a daily tool, not an experiment. You know how to

structure context so output is reliable, you iterate on prompts rather than

accepting the first answer, and you know when a model is confidently wrong

and you check.

● You can build a rough working thing with AI assistance. Not production code.

A prototype good enough that people can react to it instead of imagining it.

● You write clearly. In a setup like ours, written clarity is not a soft skill. It is the

input that determines what gets built.

● Analytical honesty. You quantify rather than characterize, you name your

assumptions, and when numbers don't reconcile you stop and investigate

instead of shipping the chart.

● Comfort operating without process scaffolding, and comfort saying “not this

week, here's why” when three people want the same hour.

• Bonus: B2B SaaS with enterprise customers, compliance- or workflow-heavy

products, Python for analysis, or experience maintaining documentation that

AI tooling depends on.