AI-native product transformation
Turn your SaaS app into an AI-native product.
I help SaaS teams rethink complex workflows—so AI can connect the right context, prepare useful work, and keep people in control.
Start with one focused workflow. Expand when the direction is clear.
Senior-led product strategy, UX architecture, and AI interaction design.
3 blockers.
One recovery plan.
Illustrative result: A clear path back to progress. Here’s a draft plan based on the current project state. Review required.
Explore other examples
Scripted example. No live AI, connected product data, or external actions.
The workflow shift
Same product. A different way to work.
The information is already in your product. The work is connecting it, understanding what matters, and deciding what happens next.
Contract → review → release
One connected next step.
People decide what happens next.
Today, people connect the dots.
Contract → review → release
One connected next step.
The product brings the context together.
Contract → review → release
One connected next step.
AI prepares a useful next step.
Contract → review → release
One connected next step.
People decide what happens next.
Contract → review → release
One connected next step.
Illustrative workflow · Sample data. A design possibility, not measured product results.
A better starting point
Start with the work. Not the AI.
Before choosing a model or adding a chat window, define the job, the context, and the decisions people need help with.
Which chatbot should we add?
Which job should the system complete?
Which model knows our product?
What can it know, retrieve and remember?
How many agents do we need?
Which actions can this role safely take?
Should everything become a chat?
Where should this decision happen?
Sometimes the right answer is a simpler workflow—not more AI.
What informs these decisions
User journeys, friction, product rules, permissions, feedback, analytics, information architecture, data relationships, and existing design patterns.
The product blueprint
A useful experience needs more than a model.
Behind a simple interaction are decisions about what AI can know, what it can do, where it belongs, and when a person needs to step in.
01Product model
Grounded in your product.
Define the objects, roles, and rules the experience needs to respect.
Project Atlas connects tasks, their owners, permissions and the rules that apply to a change.
02Knowledge & retrieval
Connected to the right knowledge.
Identify useful sources, their freshness, and how people can inspect the evidence.
The task board, dependency records and team capacity keep their source references. Retrieval supplies context; it does not grant permission.
03Capabilities
Clear about what it can do.
Separate predictable checks, AI reasoning, and the actions a role is allowed to take.
Compare dependencies and draft a plan. Updating tasks is a separate capability, bounded by permissions and approval.
04Interaction & role
Placed where work happens.
Choose the right interaction: an inline action, a guided workflow, an assistant, or another suitable surface.
A contextual review surface shows the proposed next step where the operator already works—not in a detached chat window.
05Controls & signals
Accountable at every step.
Design approvals, visible changes, recovery paths, and human fallback.
Signals produce proposals. People validate and release changes, then evaluate the result. Nothing silently improves itself in production.
One experience. A connected system.
Product context and knowledge enable bounded capabilities. They meet people through an interaction—and stay inside clear controls.
Select a subsystem to inspect its role. These are architectural relationships, not five steps in a model’s reasoning.
Explore the technical blueprint
Agent Harness design: the product-specific architecture behind the experience—not a production AI runtime.
Signals inform proposals. People review changes before release.Human control, built in
More capable. Still under control.
Let AI prepare the work without hiding the decision. Make the proposal, the expected changes, and the approval point clear.
Three blockers.
One dependency path.
- AT-12API contract pendingBlocked
- AT-18Dependent review waitingBlocked
- AT-24Release check overlapsBlocked
Task board · Dependencies · Team capacity
A clear path back to progress
- 01Confirm the API contract
Maya · API owner
First · unblock implementation - 02Review the dependent changes
Leo · engineering
After contract approval - 03Move the release check
Sam · project lead
After review · confirm capacity
Owners approve before task or schedule changes.
Show how to recover where recovery is supported—or how to hand the issue to a person.
Interactive illustration. No changes are made to a real product.Selected product work
Built on real product work.
My approach comes from designing complex B2B workflows, contextual AI interactions, and reporting systems—not just imagining new interfaces.
Contextual AI, inside the workflow.
I designed a context-aware assistant across planning and content workflows, from discovery and prototypes through usability testing and implementation handoff. The interaction model included contextual tools, source selection, and apply/replace actions.
Explore the AI integration caseThe case covers design decisions and usability findings. Post-launch performance metrics are not available.
Making complex reporting usable.
I redesigned reporting flows and shared widget patterns, and designed and prototyped a Custom Widget Builder to support more flexible analysis.
Explore the reporting caseFrom exploration to a clear next move
A direction your team can build from.
Start with a clear view of the opportunity. Go deeper into the workflow, prototype, or system design when the scope calls for it.
Recovery planning
Keep the judgment.Connect the context.
01 / FRICTIONContext is spread across the work.
02 / AI FITPrepare a plan. Keep approval human.
03 / NEXT STEPMake dependencies reviewable.
Audit report and recommendations
Know what to change.
A focused assessment of the workflow, its friction, where AI fits, and which alternatives deserve consideration.
Review recovery plan
Review required
Available through prototype or UX design engagements
See how it could work.
A representative coded prototype or redesigned workflow makes the proposed experience concrete before a larger build.
Available through Agent Harness Design
Align the system behind it.
A product-specific blueprint defines the context, capabilities, interactions, and control boundaries the experience depends on.
Deliverable depth depends on the selected engagement. Confirm the included artifacts before work begins.
- 01
Frame
Understand the workflow and the decision it needs to support.
- 02
Design
Explore the experience and the boundaries around it.
- 03
Review
Align on the recommendation and the next step.
Choose your starting point
Start focused. Go deeper when it makes sense.
Begin with one meaningful workflow. Choose a focused audit, explore a prototype, or scope a deeper design engagement.
Before we start
A focused start.
Clear expectations.
The audit excludes new user research, production implementation, certification and guaranteed KPI uplift. A deterministic or no-AI direction is a valid outcome.
The next move for your product
Your SaaS.
A clearer AI-native direction.
Start with the workflow that matters. Define what should change, what should stay human, and what your team can build next.
One focused starting point. A scope agreed before work begins.