At a glance
- Role
- Product Manager, owning product direction, requirements, backlog and roadmap
- Period
- 2022 – 2024
- Company
- AI and software product studio building enterprise B2B SaaS and consumer products
- Product
- Enterprise LLM legal assistant embedded in Microsoft Word and Outlook, built for a client
- Users
- Legal teams, administrators and enterprise buyers
- Team
- Three engineers, with design and QA
Context
At Frontline Labs, I owned product direction across AI and software products, working with founders on priorities, scope and release decisions.
This case study focuses on an enterprise legal assistant built for a studio client. It worked inside Microsoft Word and Outlook, supporting the tools legal teams already used.
The problem
Legal teams needed help with drafting and review, but accuracy, confidentiality and accountability shaped whether they would adopt the assistant.
Discovery with enterprise buyers and users surfaced three recurring concerns, alongside the complexity of the legal workflows.
It might invent facts or citations
The assistant drafts, reviews, verifies facts and analyses filings on behalf of lawyers. If it invents a citation, the lawyer carries the liability.
Client documents might leave the firm
Legal teams would not adopt a tool if client documents could leave the firm or be used to train a model.
No record to defend the work
Without a record of what the tool did, its work could not be defended later.
Dense, ambiguous workflows
Drafting, compliance review, fact-verification and regulatory-filing analysis each had to be understood before it could be specified.
Finding the cause
Discovery with users and buyers
I ran discovery workshops and interviews with enterprise users, buyers, and compliance and legal stakeholders, to understand their buying criteria and what stopped them adopting.
Learning the domain
I developed a working understanding of the legal workflows and documented the agreed requirements, giving engineering a clear reference for product decisions.
Alpha and beta programmes
Each full release was preceded by alpha and beta programmes with real users.
Product decisions
Require human review, and accept the cost
I defined what the assistant could do on its own and when a person had to review. Nothing is sent or filed externally without a person approving it.
The cost of an unreviewed error falls on the lawyer, not the software.
Trade-off: Mandatory review made the tool slower. We kept it.
Decline to answer instead of guessing
The assistant refuses to give a legal conclusion with no source to support it, and refuses to answer from outside the documents in the user's workspace.
A visible limit helps users understand when they can rely on the assistant and when they need to review the source themselves.
Ground every output in a source the user can check
Outputs were grounded in a retrievable source, with verification the user could do for themselves.
A lawyer cannot rely on a claim they cannot trace. This answered the fear of invented citations directly.
Spend engineering time on trust before features
The audit trail, workspace data boundaries and admin controls were built ahead of new capabilities.
These controls addressed specific adoption barriers raised in discovery. I prioritised them before expanding the feature set.
Trade-off: With three engineers, that was time features would have used.
Agree the rules with compliance before building
I facilitated agreement between users, compliance stakeholders and engineering on data handling, human review and the audit trail.
All three groups had to agree. Agreeing early was cheaper than rebuilding after a compliance review.
Make output quality a release gate
A fixed set of test prompts ran on every release. Outputs were scored for accuracy and for whether each claim traced to a source, and a legal stakeholder reviewed a sample.
Model behaviour changes between versions, so quality was checked every time, alongside security and risk reviews.
What shipped
Four legal workflows
Drafting, compliance review, fact-verification and regulatory-filing analysis, each turned into user journeys, PRDs and acceptance criteria.
The trust layer
Citations, source verification, workspace data boundaries, human review, an audit trail and admin controls.
Documentation
FAQs and user documentation for the people using and administering the product.
Delivery
I worked with three engineers and design in short Agile cycles: sprint planning, backlog refinement, sprint demos and release scheduling.
Every release passed QA, security, privacy and risk reviews, and a launch-readiness check.
I presented product demos to client stakeholders and explained model behaviour and limits to non-technical audiences.
Measuring success
A fixed set of test prompts was run on every release.
Outputs were scored for accuracy and for whether each claim traced to a source.
A lawyer or legal stakeholder reviewed a sample before release, and quality was tracked over time.
Outcomes
Delivered an enterprise legal assistant embedded in Microsoft Word and Outlook.
The assistant was adopted by enterprise legal teams.
Its controls addressed the accuracy, confidentiality and accountability concerns raised during discovery.
Lessons learned
In regulated AI, limits are a feature
Clear boundaries helped legal teams understand where the assistant could support their work and where their own judgement remained essential.
Answer the buyer's objection before adding a feature
The controls addressed specific objections raised by buyers. I now make those objections an explicit part of enterprise discovery.
Give the team a shared domain reference
Documenting legal workflows and agreed constraints gave engineering a clearer basis for decisions and reduced repeated clarification.
Slower can be the right product decision
Human review added time, and verification work reduced the capacity available for new features. I accepted those costs because they addressed the risks users had identified.
Explore the product
Three objections, and what answered each
Each part of the trust layer exists because of something a buyer said. Pick an objection.
“It might invent a citation.”+
Answered by citation-grounded outputs and source verification: every output points to a retrievable source the user can check.
“Client documents might leave the firm.”+
Answered by workspace data boundaries and admin controls: each workspace's documents stay inside that workspace.
“We could not defend its work later.”+
Answered by human-in-the-loop review and a full audit trail of what the system did and why.
What the assistant refuses to do
Limits were designed in and shown to users.
A conclusion with no source+
It will not give a legal conclusion with no source to support it.
Answers from outside the workspace+
It will not answer from outside the documents in the user's workspace.
Sending without approval+
It will not send or file anything externally without a person approving it.