Product Owner · Senior Business Analyst

Turning messy product problems into something teams can actually build.

I work across product, engineering, QA, design, and business teams to turn requirements, workflows, integrations, and legacy behaviour into clear delivery decisions. These case studies show the kind of analysis behind the work.

View case studies View Resume LinkedIn Email me

10+ years SaaS, enterprise platforms, product delivery

BA + Product Ownership Requirements, backlog, UAT, workflows, prioritization

Current focus Modernization, AI-enabled products, delivery-ready analysis

Sample works

Six different kinds of product problems.

Each case starts with the core story, with deeper analysis available if you want to go further.

01 · Property technology · AI

AI Leasing Assistant

Defining what an AI assistant could handle, when it needed clarification, and when a leasing professional had to take over.

AI requirements Conversation flows Escalation

02 · Enterprise SaaS · Integration

E-Signature Integration for Leasing

Working through the workflow, status handling, data mapping, and exceptions between Leasing & Rents and an e-signature platform.

Integration Status mapping Exception paths

03 · EdTech · Modernization

Modernizing an Established LMS

Separating true business rules from legacy UI behaviour so redesigned experiences could improve without losing important functionality.

Modernization Design analysis Requirements

04 · Platform migration · Decommissioning

Third-Party Service Migration

Mapping the applicant journey from an existing provider to a new platform while accounting for integrations, in-flight applicants, history, and cutover.

Migration Decommissioning Cutover

05 · AI-assisted BA · Requirements readiness

BA Pre-Flight Workflow

Using Claude to pressure-test requirements before refinement — surfacing missing rules, assumptions, dependencies, and edge cases before they reach the team.

Claude Requirements readiness Story development

06 · AI-assisted delivery · Estimation

Poker Planning - Estimation Helper

Using comparable Azure DevOps tickets and code analysis to bring historical and technical context into estimation without replacing Engineering judgment.

Azure DevOps Code analysis Estimation support

These case studies are reconstructed from the types of projects and responsibilities I have handled professionally. Proprietary details, implementation specifics, data, and business rules have been modified or replaced with representative examples. The artifacts were recreated specifically for this portfolio and are not original employer documents.

Case 01 · AI product

Environment Property technology / multifamily SaaS

My role Senior Business Analyst supporting discovery through delivery

Focus AI renter engagement, conversation behaviour, escalation

AI Leasing Assistant

The product goal sounded straightforward: automate more renter inquiries. The harder question was deciding which conversations the assistant should handle, when it should ask for more information, and when it should stop and involve a leasing professional.

01 · The problem

Automation was useful — but only if the boundaries were clear.

Prospects can ask repetitive questions outside office hours, but leasing conversations also include incomplete requests, sensitive topics, and situations where someone simply wants to speak with a person.

02 · My role

Turn an AI objective into predictable product behaviour.

I worked through supported intents, missing context, escalation conditions, user-facing behaviour, and the information that needed to follow the conversation when a human took over.

It wasn't an answer-generation problem. It was a boundary problem.

The insight

The important decision was not only what the AI could answer.

It was defining when the assistant had enough information to respond, when clarification could recover the conversation, and when continuing to guess would create a worse experience.

What changed

Escalation became part of the normal journey.

Instead of treating human handoff as an error state, I treated it as one of the expected outcomes the product needed to support deliberately.

How I broke the behaviour down

Prospect sends inquiry

↓

Identify intent + available context

↓

ANSWER — supported intent + enough context

↓

CLARIFY — supported intent + missing information

↓

ESCALATE — unsupported, sensitive, low-confidence, or human requested

Decision 01

Treat escalation as a first-class product journey.

Some conversations should end with human involvement by design. That introduced requirements around trigger conditions, context preservation, user messaging, and ownership after handoff.

Decision 02

Allow clarification, but don't let the assistant keep guessing.

Clarification can recover an incomplete request. Repeated attempts can create incorrect answers or frustration, so the requirements needed a clear point where the assistant stops trying.

View detailed analysis

Representative requirements

Identify likely intent before selecting a response path.
Ask for clarification when required information is missing.
Do not present low-confidence or unsupported requests as confidently resolved.
Allow a prospect asking for a person to leave the automated path.
Preserve relevant conversation context during handoff.

The messy bits

Prospect explicitly asks for a person
Fair-housing-sensitive question
Duplicate or multi-channel prospect
No leasing agent is available after escalation
The assistant has partial but insufficient context

MVP

Supported FAQ and leasing intents
Clarification for missing information
Human escalation with conversation context
Interaction history

Deliberately deferred

Autonomous high-risk leasing actions
Open-ended behaviour without defined controls
Deep personalization using unverifiable context

Looking back: Escalation initially looked like an exception. Treating it as part of the main product journey made the requirements around context, ownership, and user messaging much clearer.

What I owned

I translated an AI product objective into behavioural boundaries, conversation paths, escalation rules, open questions, user stories, acceptance criteria, and MVP decisions.

PDF User Stories & Acceptance Criteria Supported intents, clarification, escalation, context handling and edge cases.

↗

PDF Conversation & Escalation Flow Decision flow from renter intent through response, clarification or human handoff.

↗

Case 02 · Enterprise SaaS integration

Environment Enterprise property management SaaS

Product area Leasing & Rents

Focus Lease execution, external e-signature service, statuses and exceptions

E-Signature Integration for Leasing

From the user's perspective, the feature could look like one simple action: send a lease for signature. Behind that action were two systems, multiple signers, asynchronous status changes, document versions, and several ways the process could fail.

01 · The problem

The button was simple. The workflow behind it wasn't.

Once a lease left the leasing platform, part of the process happened externally. The product still needed to know what had been sent, who needed to sign, what state the request was in, and what to do when something changed.

02 · My role

Define the contract between the leasing workflow and the external service.

I broke the integration into data sent out, statuses coming back, internal state changes, user actions, document handling, and exception paths so Engineering and QA could reason about the same end-to-end behaviour.

It wasn't a “send document” problem. It was a state-management problem.

The insight

The product needed its own understanding of the signing journey.

External provider statuses could not simply become the product experience. We needed clear internal states and rules for what each status meant to leasing staff and what actions should be available next.

What changed

I treated failure and recovery as part of the workflow.

Void, resend, callback failure, duplicate events, signer changes, and lease changes after send were not secondary technical details. They changed the functional requirements.

Target journey

Lease generated

↓

Validate document + signer information

↓

Create e-signature request

↓

Resident(s) sign externally

↓

External status returned

↓

Leasing & Rents updates status + completed document

Decision 01

Map external statuses into product states deliberately.

Provider terminology should not leak directly into the leasing experience. Each external status needed a defined internal meaning, available actions, and expected next step.

Decision 02

Define what happens when the lease changes after it has been sent.

Once a document is already in the signing process, changing the underlying lease creates a version-control problem. The requirements needed to define whether the existing request remained valid, had to be voided, or needed to be regenerated.

View detailed analysis

Integration contract

Direction	Example data
Outbound	Lease document, signer identity, signing order
Inbound	Request ID, signer status, completion status
Stored	External reference, status history, completed document

State model

External event	Internal behaviour
Created	Mark lease as sent for signature
Partially signed	Show remaining signer(s)
Completed	Store completed document + update lease
Voided	Prevent completion against obsolete request

The messy bits

Multiple residents signing in sequence
Signer email or identity needs correction
Lease changes after the signature request is created
Request must be voided and resent
Callback is delayed or never received
Duplicate callback is received
Signing completes externally but internal update fails

Failure handling

Do not create duplicate active signature requests
Make failed or incomplete states visible to staff
Keep status updates idempotent where possible
Retain enough history for troubleshooting and audit
Define recovery rather than relying on manual database correction

Looking back: the visible feature was small, but the state model behind it was not. The requirements became much stronger once data, status, ownership, recovery, and document lifecycle were treated as one product problem.

What I owned

I translated the leasing workflow into integration requirements, field and status mappings, business rules, exception scenarios, user stories, acceptance criteria, and end-to-end validation scenarios.

PDF Integration Requirements Functional requirements, field mapping, statuses, business rules and failure handling.

↗

PDF Integration Flow Leasing-to-signature workflow with callbacks, completion and exception paths.

↗

Case 03 · Product modernization

Environment Established K–12 learning platform

My role Senior Business Analyst supporting quarterly product releases

Focus Legacy behaviour, redesigned experiences, requirements and UAT

Modernizing an Established LMS

Redesigning an established product wasn't just about translating new screens into user stories. The harder part was understanding which existing behaviours were genuine business requirements — and which were simply artifacts of the old UI.

01 · The problem

A cleaner design can still remove something important.

Existing users already had workflows, permissions, validations and expectations built around the current product. A redesigned screen could look simpler while accidentally removing behaviour the business still depended on.

02 · My role

Find the gap between what exists and what the redesign intends.

I compared existing product behaviour with proposed designs and requirements, surfaced missing states and rules, clarified open questions with Product and stakeholders, and translated the decisions into delivery-ready stories and UAT scenarios.

Legacy UI is not the same thing as legacy requirement.

The insight

Every difference between old and new needed a reason.

When behaviour disappeared from a redesign, I didn't assume it should be restored — or assume the new design was automatically correct. The difference became something to classify: preserve, redesign, intentionally remove, or clarify.

What changed

The conversation shifted from screens to behaviour.

Instead of asking whether the new UI matched the old one, we could ask whether the underlying business rule, permission, validation or user outcome still needed to exist — and how it should work in the modern experience.

How I analyzed the redesign

Review existing product behaviour

↓

Compare with proposed design + intended outcome

↓

Identify missing states, permissions, validations and dependencies

↓

Classify differences: preserve / redesign / remove / clarify

↓

Resolve open questions with Product + stakeholders

↓

Translate decisions into stories, acceptance criteria and UAT

Decision 01

Preserve the rule, not necessarily the old interaction.

If an existing warning, permission or validation protected a real business rule, the redesigned experience still needed to satisfy that intent. The UI itself didn't have to remain unchanged.

Decision 02

Don't quietly fill gaps in the design.

When a state or behaviour was missing, I captured it as an open question rather than turning an assumption into a requirement. That made unresolved product decisions visible before development.

View detailed analysis

Representative gap analysis

Existing behaviour	Decision	Requirement impact
Action limited to certain roles	Preserve	Permission rule included in AC
Multi-page navigation	Redesign	Consolidate while preserving underlying workflow
Warning before destructive action	Preserve intent	New UX still requires a safeguard
Legacy field absent from design	Clarify	Resolve business need before story is ready

Questions I looked for

Who can see and perform the action?
What happens when there is no data yet?
What happens with historical records?
Which validations still apply?
Are any actions destructive or irreversible?
What happens when an external dependency fails?

UAT focus

Role and permission differences
Existing and historical records
Validation and error behaviour
Empty and incomplete states
Regression-sensitive workflows
Behaviour changed intentionally by the redesign

Delivery outputs

Current vs future behaviour analysis
Open questions and decisions
User stories and acceptance criteria
Process and interaction flows
UAT scenarios
Release and demo support

Looking back: the useful distinction wasn't “old versus new.” It was understanding which behaviours represented real product rules, which were historical UI constraints, and which still needed a product decision.

What I owned

I analyzed existing and proposed behaviour, surfaced requirement gaps and dependencies, facilitated clarification with Product and stakeholders, and translated the resulting decisions into user stories, acceptance criteria, process flows and UAT scenarios.

PDF Requirements & Gap Analysis Legacy-to-modern behaviour comparison, gaps, decisions and open questions.

↗

PDF UAT Scenarios Permissions, historical data, validation, failures and regression coverage.

↗

Case 04 · Platform migration + decommissioning

Project type Replacement of a background screening platform

Business journey Applicant screening / leasing process

Focus Current/future state, integration impacts, cutover and decommissioning

Replacing a Background Check Platform

Replacing a vendor looked like a straightforward platform change until the surrounding dependencies were mapped. Applicant workflows, integrations, statuses, historical records, support processes and transactions already in progress all depended on the system we were trying to retire.

01 · The problem

You can redirect new work. Existing work is harder.

New screening requests could eventually move to the replacement provider, but historical records and applicants already being processed by the legacy platform still needed a defined path through cutover.

02 · My role

Make the transition visible before anyone switched systems.

I mapped the current and future journeys, traced dependencies, identified migration and integration impacts, and worked through cutover scenarios and the conditions required to retire the old platform.

It wasn't a vendor-switch problem. It was a transition-state problem.

The insight

The hardest user wasn't a new applicant.

It was the applicant whose screening started with the old provider before cutover but would not finish until after the replacement platform was already live.

What changed

Cutover became its own workflow.

Instead of treating migration as a single go-live event, I separated current state, future state and transition state so the team could reason about what happened during the period when both systems still mattered.

Critical transition scenario

Applicant starts screening with legacy provider

↓

Replacement platform goes live

↓

New applicants begin using replacement provider

↓

Legacy screening result returns after cutover

↓

Product must still receive, interpret and preserve the result

↓

Legacy dependency can be retired only after remaining obligations are closed

Decision 01

Don't force every in-flight applicant onto the new provider.

Moving an active screening midway through the process could introduce duplicate checks, inconsistent statuses and support issues. The transition needed explicit rules for work already underway.

Decision 02

Separate go-live from decommissioning.

The new provider being live did not mean the legacy platform could immediately disappear. Historical access, callbacks, credentials, reporting and support obligations needed their own exit criteria.

View detailed analysis

Current → transition → future state

Area	Current state	Transition question	Future state
New screening	Legacy provider	When does routing change?	Replacement provider
In-flight screening	Legacy provider owns request	Can old results still return?	No new legacy requests
Status	Legacy status model	How are both providers interpreted?	New mapped status model
History	Legacy records available	What must remain accessible?	Migrated, retained or archived history
Support	Legacy access and procedures	How long are they required?	Replacement support model

Dependencies to trace

Provider APIs and credentials
Request and callback jobs
Status mapping
User-facing screening states
Configuration and permissions
Reporting and audit history
Support procedures

Cutover questions

What is the final date for new legacy requests?
How are in-flight screenings identified?
How long must legacy callbacks remain active?
What happens when a legacy result fails after cutover?
Who needs access to historical records?
What proves the old integration can safely be disabled?

Decommissioning gates

No new requests routed to legacy provider
In-flight transactions resolved or explicitly handled
Required historical data retained
Reporting and audit needs covered
Support process moved to replacement platform
Legacy jobs, callbacks and credentials can be disabled

Traceability

I used traceability to connect business requirements to impacted integrations, migration needs, validation scenarios, ownership and cutover readiness rather than treating them as separate workstreams.

Looking back: the old platform was not truly gone just because new transactions stopped entering it. Decommissioning only became realistic once in-flight work, history, reporting, access, support and technical dependencies all had an explicit exit path.

What I owned

I mapped current and future workflows, traced system dependencies, documented migration and integration impacts, worked through in-flight scenarios, maintained requirements traceability, and helped define the cutover and decommissioning conditions.

XLSX Requirements Traceability Matrix Requirements, dependencies, validation, migration impact, ownership and status.

↗

PDF As-Is → To-Be & Cutover Flow Provider replacement, in-flight transactions and decommissioning gates.

↗

Case 05 · AI-assisted BA workflow

Problem Requirements reaching refinement with hidden assumptions or incomplete context

Tooling Claude + existing product and delivery context

Focus Requirements readiness, assumptions, edge cases and story development

BA Pre-Flight Workflow

A user story can be perfectly formatted and still contain an assumption nobody agreed to. I built a repeatable AI-assisted review step to pressure-test the requirement before bringing it into refinement.

01 · The problem

Story quality and requirement quality are not the same thing.

Requests often arrive as a mix of confirmed behaviour, shorthand, historical knowledge and unstated assumptions. Turning that directly into a polished story can make the gaps harder to see rather than easier.

02 · What I built

A pre-flight check before story development.

I use Claude to help extract what is actually stated, separate it from possible assumptions, surface missing rules and edge cases, and organize the questions I need to resolve before finalizing the requirement.

It wasn't a story-writing problem. It was a requirements-readiness problem.

The insight

The useful output isn't always a user story.

Sometimes the best result of the pre-flight is a list of unresolved questions and a clear “not ready” decision. That is more useful than generating acceptance criteria around behaviour we have not actually confirmed.

The boundary

AI helps challenge the requirement. It doesn't own it.

Claude can identify patterns, possible gaps and questions worth asking. I still decide what is supported by the source material, what matters to the product, what needs stakeholder input, and what becomes the final requirement.

Pre-flight workflow

Raw request / discovery notes / design / existing ticket

↓

Extract user goal + actors + proposed behaviour + stated business rules

↓

Separate confirmed information from assumptions and inferred behaviour

↓

Surface missing states, permissions, validations, dependencies and edge cases

↓

Generate open questions + decisions needed

↓

Draft story + acceptance criteria from confirmed behaviour

↓

BA review → remove unsupported assumptions → refine wording → ready for discussion

Decision 01

Separate source material from generated interpretation.

I don't want an AI-generated assumption to quietly become a business rule. Confirmed information, inferred behaviour and unanswered questions stay distinguishable throughout the review.

Decision 02

Let the workflow return “not ready.”

Readiness isn't measured by whether the AI can produce a story. If an unresolved rule materially affects behaviour or acceptance criteria, the requirement stays open until that decision is made.

View detailed analysis

Worked example

Source note: “Users should be able to cancel a booking. Obviously not once it has started. Refund handling is the same as today.”

Pre-flight finding	What I do with it
User can cancel a booking	Confirmed behaviour
Cancellation unavailable once booking has “started”	Clarify exactly which status or event defines started
Cancellation automatically triggers a refund	Reject — not supported by the source note
“Refund handling is the same as today”	Review existing behaviour before writing AC
Which other booking statuses can be cancelled?	Open question

A polished draft could easily invent automatic refund behaviour here. The pre-flight is useful because it makes that assumption visible before it becomes part of the story.

Claude helps with

Extracting stated behaviour
Highlighting possible assumptions
Suggesting edge cases worth validating
Comparing source material with a draft
Structuring open questions
Drafting stories and AC once behaviour is understood

Judgment stays with me

Whether an assumption is actually supported
Historical product behaviour
Which edge cases are relevant
Conflicting stakeholder information
Scope and prioritization
Final requirements and acceptance criteria

Possible pre-flight outcomes

Outcome	Meaning
Ready	Core behaviour is understood well enough for team discussion.
Ready with questions	Remaining questions do not block the core requirement.
Not ready	Unresolved rules materially affect behaviour, scope or acceptance criteria.

Looking back: the biggest benefit isn't faster story writing. It's getting to the useful questions earlier. Sometimes the most valuable output of the workflow is knowing that I shouldn't write the story yet.

What I designed

I designed the pre-flight as a repeatable BA workflow for using AI to challenge requirement completeness, surface assumptions and prepare better questions — while keeping product judgment, scope decisions and final requirements with me.

PDF Requirements Readiness Review Assumptions, open questions, readiness checks and a worked requirement moving from not ready to refinement-ready.

↗

Case 06 · AI-assisted estimation support

Problem Estimation starting without enough historical or technical context

AI's role Find and synthesize comparable Azure DevOps work + code context

Boundary AI surfaces evidence; Engineering owns the estimate

Planning Poker - Estimation Helper

Estimation conversations sometimes start with Engineering rediscovering context that already exists in delivery history or the codebase. I started designing an AI-assisted workflow that brings that evidence together before sizing — without asking AI to estimate the work.

01 · The problem

Engineering was sometimes estimating before the useful context was assembled.

A story might look small in isolation while similar work had previously touched several components, introduced regression risk, or depended on logic that was shared elsewhere in the product.

02 · What I started building

An AI-assisted evidence brief before the sizing conversation.

The workflow uses AI to help find and compare relevant Azure DevOps work, review available technical context, and synthesize useful signals into a brief that Engineering can validate before assigning an estimate.

It wasn't an estimation problem. It was a context problem.

The insight

Historical work is evidence, not an estimation formula.

A previous ticket can reveal hidden complexity, affected areas or regression patterns, but two stories that sound similar are not automatically equivalent. The comparison needs context and caveats.

The boundary

AI supports the investigation. Engineering still estimates.

AI can help search, compare and synthesize the available evidence, but it does not assign story points or decide implementation complexity. Engineering validates the technical context, determines the approach and owns the estimate.

Estimation Helper workflow

Proposed story / requirement

↓

Understand functional scope + intended behaviour

↓

Search for genuinely comparable Azure DevOps work

↓

Review what changed in similar work + where complexity appeared

↓

Review relevant code context for components, dependencies and regression signals

↓

Summarize evidence + caveats + unanswered questions

↓

Engineering validates the evidence and owns the final estimate

Decision 01

Show why a historical ticket is comparable.

Matching keywords isn't enough. The useful comparison is whether the earlier work touched similar behaviour, components, integrations or regression-sensitive areas — and where the comparison stops being valid.

Decision 02

Make uncertainty part of the output.

If no genuinely comparable work is found, the output should say so. If a technical signal is only a hypothesis, it should remain a question for Engineering rather than being presented as an architecture fact.

View detailed analysis

Representative evidence brief

Evidence	Why it may matter
Comparable ADO ticket touched the same validation path	Previous implementation required both API and UI changes
Similar workflow change required broader regression coverage	Current story may affect more than the visible screen
Relevant logic appears shared across booking types	Engineering should validate whether the change is isolated
Refund handling may be owned by another service	Potential dependency to confirm before sizing

Useful estimation signals

Likely components or services touched
Shared versus isolated logic
Integration and service dependencies
Data-model or migration impact
Regression-sensitive workflows
Complexity patterns from comparable work
Unresolved requirements affecting implementation

What it deliberately does not do

Assign story points automatically
Treat historical tickets as exact equivalents
Override Engineering judgment
Present code-analysis guesses as confirmed architecture
Hide uncertainty to make the output look more complete

Example output

Comparable work	Relevant historical tickets + why they are or are not comparable
Likely affected areas	Components or services suggested by the available evidence
Complexity signals	Dependencies, shared logic, regression or data impact
Questions for Engineering	Technical assumptions requiring validation
Estimate	Not assigned by AI. Engineering sizes after reviewing the evidence.

Looking back: “no genuinely comparable ticket found” can be one of the most useful outputs. The agent is more valuable when it exposes the limits of the available evidence than when it forces a comparison just to produce an answer.

What I designed

I designed the estimation helper as a way to connect requirements with historical delivery evidence and relevant technical context before refinement — while deliberately keeping feasibility, implementation decisions and estimation with Engineering.

PDF Planning Poker - Estimation Helper Evidence brief Comparable Azure DevOps work, technical signals, complexity indicators, caveats and questions for Engineering.

↗

How I work

A few things I consistently bring into the work.

My strongest work tends to sit between business context and delivery detail.

I look for the rules behind the request.

A stakeholder usually describes the change they want, not every condition around it.

I bring edge cases in early.

Exceptions usually expose missing permissions, states, dependencies, or business rules.

I write for Product, Engineering, and QA together.

If three people can reasonably interpret the same story three different ways, it still needs work.

I am comfortable working inside existing products.

Modernization, integrations, and migrations often require understanding what already exists before deciding what should change.

Contact

Want to talk through the work?

I’m happy to talk through any of these case studies in more detail — what worked, what didn’t, the trade-offs we made, and how the requirements evolved along the way.

Email me View Resume LinkedIn