Legal engineering
How legal processes can be redesigned using technology, automation and human centred product thinking.
Areas I am intentionally learning, studying and applying. I am not presenting these as expertise. They are the direction of my practice.
Certified on Harvey, the AI platform built for legal work, which is where my interest in legal engineering and responsible AI becomes practical.
How legal processes can be redesigned using technology, automation and human centred product thinking.
How organisations can develop and deploy AI responsibly, transparently and with appropriate oversight.
Building working prototypes with AI tooling so an idea can be tested with real people in days rather than months.
Reading product data properly: instrumentation, cohort behaviour and the metrics that should drive a decision.
What I am learning and building across legal engineering, ethical governance and go-to-market. These are studies and prototypes, not client work, and they are labelled as such.
Where does a routine legal request lose the most time between the person who needs help and the lawyer who answers?
Most legal delay is process delay, not legal difficulty. Intake is where clarity, expectations and risk get set.
Structured intake questions remove more back and forth than automation does. Standardising the question set matters before any tooling is introduced.
A mapped intake flow, a structured question set and a triage rubric for routing requests by risk and urgency.
Service blueprinting, journey mapping, Notion, no-code forms
Intake data is sensitive. The design keeps collection minimal and escalates anything that needs professional judgement to a human.
Legal engineering starts as a product problem: understand the user, then decide what technology genuinely earns its place.
What is the smallest governance step a startup can take before shipping an AI feature?
Small teams rarely have a governance function, yet they make the design choices that later become compliance problems.
Governance is more useful as a set of product questions at design time than as a document written after launch.
A one page pre-launch review covering purpose, data sources, failure modes, human oversight, disclosure and rollback.
NIST AI Risk Management Framework, EU AI Act reading, ISO 42001 overview
The review foregrounds transparency to users and a clear owner for any automated decision that affects a person.
Responsible AI is not a blocker. Framed well, it is a product quality practice that makes trust visible.
Can a structured assistant help a non-legal product team spot AI risk earlier in the build?
Risk is cheapest to fix at the specification stage, but the people writing specifications rarely have legal training.
Prompted assistants are good at surfacing questions and poor at giving conclusions. The output should be a checklist for a human, not an answer.
A prompt set that turns a feature description into risk themes, oversight questions and documentation prompts.
Claude, ChatGPT, Lovable
Explicitly labelled as decision support, not legal advice, with a human reviewer required before any decision.
The interesting design question is not what the model can answer, but which decisions should never be delegated to it.
How does the way a product is explained change whether people adopt it?
Adoption often fails at explanation, not at capability. Positioning is the bridge between what is built and what is understood.
Positioning improves fastest when it is tested with real users in their own words rather than refined internally.
A positioning canvas, message tests and a launch narrative template used on my own products.
Customer interviews, message testing, analytics
Claims are held to what the product can actually do today, with roadmap language kept separate from current capability.
Go-to-market is a product discipline. The story is part of the product experience.