You can't automate
what you can't articulate.

My approach to AI, problem-solving, and why the most useful thing I've ever done before implementing technology was to just go talk to people. These aren't theories — they're patterns I've tested across 15 years and five domains, and I genuinely love finding where they apply next.

Same pattern. Every project. Every domain.

This isn't a framework I invented and named. It's what I noticed I was already doing, after 15 years of doing it.

01
Go toward the people
Real conversations before anything else
02
Find the real problem
The presenting problem is rarely the actual one
03
Build the fix
Ship things that actually work
04
Validate & iterate
Come back. Check. Ask again.
01
Go toward the people
Before I touch a product, I talk to the people who will use it. Not surveys — real conversations. I listen for the gap between what they say they need and what they actually do. Most people have never had someone sit with them long enough to find that gap.
In practice: Interviewed 50+ public health professionals before building PH360. Mentored by GRASS GIS creator Jim Westervelt on day one at the Army Corps: "Go talk to the users first." I've done that ever since.
02
Find the real problem
The presenting problem is rarely the actual problem. I trace pain points to root causes — which are usually organizational, not technical. "Everything is slow" is not a problem. "Our complaint categorization system hasn't been updated in 15 years and routes cases to the wrong department" is a problem.
In practice: Public health wasn't adopting AI because of policy ambiguity, not tech gaps. Peapod's demand model had never been validated — nobody had asked. Cemetery mapping took days because of a CAD conversion nobody had questioned.
03
Build the fix — and ship it
I don't just recommend. I build. Whether it's an AI platform, a data governance framework, an automation workflow, or a strategic plan — I ship things that actually work. The library automation I built for my own family wasn't a prototype. It runs every week.
In practice: Built PH360 on AWS Bedrock. Automated Puerto Rico power data from 8 hours to 30 minutes. Built ENSITE, the military's first global site location tool — then watched it deploy to Iraq, Afghanistan, and Poland.
04
Validate and iterate
I bring solutions back to real users, test assumptions, and iterate. My qualitative research background means rigor and curiosity aren't in tension — they're the same thing. I follow up. I check. I ask again.
In practice: Ran PCA to validate Peapod's demand model — something the original consultants had never done. Followed up with every PH360 interviewee to validate features before building. User-tested ENSITE across DOD theaters.

Map the process first.
Choose the technology second.

Process mapping is the practice of breaking a workflow into its individual steps so you can see exactly what's happening, who's doing it, and where the real bottlenecks are. It's not bureaucratic. It's the foundation that separates successful AI adoption from expensive failures.

Elimination beats simplification. Simplification beats automation. The order matters. Automating an unnecessary step just makes you do something unnecessary faster. Automating a broken process just makes it fail faster.

"You can't automate what you don't understand. And you definitely shouldn't automate what's already broken." — Juliana McMillan-Wilhoit

I use process mapping with every client before any technology recommendation. It's how I found that Sauk County's environmental health bottleneck wasn't intake — it was that staff were spending most of their day on information lookup tasks that required no specialized judgment. That insight led to the AI implementation. The implementation didn't lead to the insight.

At Sauk County, I mapped their environmental health workflows before recommending anything. What I found: staff were spending most of their day on information lookup tasks that required no specialized judgment — pulling policies, cross-referencing regulations, formatting standard responses. That was the AI opportunity. The implementation followed the insight, not the other way around.

At Peapod, I mapped how the demand model outputs were actually being used. Nobody trusted the conclusions. So I ran PCA — the first validation the model had ever received. Speed wasn't the problem. Credibility was.

The question is always the same: does this step require human judgment or human connection? If the answer is no — that's your opportunity zone.

A framework I developed
for putting AI to work.

Process mapping tells you whether to reach for AI. MAP is how I get teams to actually use it well once they do. I lead trainings on it in our AI Community of Practice and at AOHC, and it's the same method behind the tools I ship.

M
Map your workflow
Lay out the actual steps and find the bottleneck before anyone reaches for AI. Most failed AI projects skip this and automate the wrong thing.
A
Add context
Give the model what it needs to be useful and safe: the source documents, the community it serves, and the constraints it has to respect.
P
Prompt & polish
Write the ask with structure, then check the output. I teach two prompting patterns for this: APE (Action, Purpose, Expectation) and CORE (Context, Objective, Role, Example).
"Treat AI like a confident but mistake-prone intern in its first week. It drafts, you decide. It suggests, you verify." — Juliana McMillan-Wilhoit

A 2024 RAND study found that 80% of AI projects fail. The reason is almost never the technology. It's that no one defined the problem first. MAP starts there, which is why the AI tool I built for Sauk County's inspectors cut the time to answer a routine food-code question from 30 minutes to 5, with 83% of them reporting a lighter workload.

I use AI every day.
I'm also clear about what it can't do.

AI predicts the next word. That's genuinely powerful for synthesizing information, and it's also the limit. A model doesn't know your values or understand what you're actually trying to do. Ask it to write a Facebook post cold and it will, but it will miss everything that made the post worth writing. It gets useful the moment you pair it with your own judgment about what matters.

The way I think about the human role is a creative director. The skill that lasts isn't doing every task yourself. It's being able to define the goal, communicate it clearly, and say what a good result looks like along the way. Communication and persuasion get more important in an AI era, not less.

"Not everything should be offloaded. I catch myself telling AI 'make me sound like this,' then stop and ask whether that's a skill I actually want to keep sharp. Some things you stay good at only by doing them yourself." — Juliana McMillan-Wilhoit

This is also how I think about it as a parent. In our house, AI is a set of intentional guardrails, not a blanket yes or no. At my kids' age, learning to read and spending time in the physical world come first: cooking, making things, being outside before being on a screen. Those are our rules for right now, not a prescription for everyone. The through-line is the same one I bring to work. Know what the tool is for, and know what it can't replace.

I build communities around
the problems I care about.

Not as a side project. As part of the work. The pattern is the same one I bring to product development: find where people are isolated, confused, or stuck — and create the thing that brings them together.

I grew a 2,000-person geospatial audience under the Tabulae Spatial brand — built around my own ideas and voice. I hosted Mappy Hours, a recurring community gathering for the geospatial world. I co-founded the Bulgarian English Speech Tournament Foundation during my Fulbright year — grew it from 6 schools to 35+ and 1,000+ students.

At F&T Labs I run a monthly AI for Public Health Community of Practice — peer learning for health professionals navigating AI, with guest speakers and real questions. I've led multiple storytelling with data trainings for clients. I've spoken at national conferences three times as a keynote.

The through-line: I find where people need a gathering point and I build it. The medium changes — a newsletter, a community call, a training, a keynote. The instinct doesn't.

Geospatial Community
~2,000
person email audience — Tabulae Spatial brand
BEST Foundation · Bulgaria
6 → 35+
schools · 1,000+ students · co-founded during Fulbright
AI for Public Health CoP
Monthly
peer learning community · guest speakers · no hype

Most AI failures aren't technology failures. They're process failures. Organizations jump to solutions before they've understood their problems. They automate broken workflows and wonder why it didn't help. My job is to slow that down — map the process, find what's actually broken, then figure out where AI fits.

AI also doesn't fix bad data. It amplifies it. Models are confident by default — they'll give you an answer whether or not the input deserves one. I've spent 15 years asking the same question across every role: can the data actually support the conclusion being drawn from it? That instinct doesn't get easier to apply when AI is involved. It gets more necessary.

I'm not interested in AI for AI's sake. I'm interested in where it actually fits — and where organizations aren't ready for it yet.

I'd rather tell you where I'm still growing than pretend I'm finished. I'm a listener by instinct, and my blind spot is the flip side of that. I sometimes assume a shared understanding I haven't actually said out loud.

So the discipline I'm building is making the implicit explicit early: naming the goal, the scope, and the plan plainly, even when I think everyone in the room already knows it.

Want a product leader who thinks this way?

If this is how you'd want someone approaching problems on your team, I'd love to talk about where I could help.

Let's talk → See the case studies