I spent seven years on the discovery end of product — research, positioning and MVP definition for banks and fintechs at EY and Fifty Thousand Feet, then product strategy and delivery for Capital One Travel while it grew 84% in a year. For the last twenty months I've done all four stages myself on Prox, an AI product, including the evaluation program that tells me when I'm wrong.
Looking for a product team that needs AI features customers will trust. Product strategy, design strategy, AI product, or research-led roles — Chicago or remote.
01Discover
Find out what's actually worth building — interviews, surveys, personas, coding competitors like transcripts.
02Build
Define the bet, sequence the MVP, and make the thing — the interface and the system behind it.
03Evaluate
Check my own work before it goes out: rubrics, failure taxonomies, a locked judge, a gate I committed to in advance.
04Ship
Release with a named rollback, then keep measuring — shipping is where the real evaluation starts.
Selected work · 2019–2026
Four projects, and what I learned by checking them.
WEX Corporate Payments-as-a-Service. Ran brand and positioning development with WEX and Mastercard; assessed 20+ enterprise competitors to land on "the most complete cloud-based B2B payment technology and services stack."
Also · Fifty Thousand Feet, 2021–22
Sesami. Value proposition and messaging framework for an AI-driven cash-management platform, grounded in quantitative research with 550+ participants; aligned six to ten stakeholders on go-to-market.
Also · EY for Morgan Stanley, 2019–21
Wealth management. Owned research across six product lines, synthesizing findings into prioritized feature recommendations for executive stakeholders.
How I work
Things I keep relearning.
Rubrics are discovered by labeling, not designed up front.
The first cases tell you which observables to key on and where the boundaries sit. You label until your hand keeps reaching for the same words, and those words become the dimensions.
Attribute a failure to where it became inevitable, not where it became visible.
Without that rule every failure lands on the last component that touched it, and the distribution tells you to fix the one layer that was doing what it was told.
Write the near-miss, not just the example.
A category defined only by positive examples expands silently until it means nothing. The row that looks like it belongs and doesn't is what makes a definition falsifiable.
Commit to the gate before the results come in.
Then run it on your own work. The one time it returned HOLD on a redesign I'd built is the best evidence I have that the gate is real.
I've spent my career on the discovery half of product: finding the problem worth solving, defining the bet, and checking the result. At EY and Fifty Thousand Feet that meant discovery and positioning for banks and fintechs. At Capital One it meant product strategy and delivery for Capital One Travel during its fastest growth. Since 2025 it has meant doing all of it at once on Prox — and learning that shipping an AI feature is the easy part; knowing whether it works is the job. I built Prox to learn that loop. I'm not founding again.
I design as well as define — the Prox interface is mine — and I'm most useful where the two meet: deciding what to build, making it usable, and finding out honestly whether it works. Chicago is home.
Education
MBA + Master of Design, Illinois Institute of Technology (Institute of Design), 2019 · BS, Indiana University
Certification
Microsoft AI Product Manager Professional Certificate, 2026
A conversational discovery product for people furnishing a home, over a catalog of 300K+ products — and the evaluation program that found out where it was actually failing.
DiscoverBuildEvaluateShip
What it is
Chat → clarify → curated set → save to a project board. proxdesign.co — ask me for a walkthrough.
Stack
Next.js on Vercel · Neon Postgres + pgvector · Voyage AI embeddings · Claude · Braintrust · Stripe
Status
Live, paid tier on Stripe since July 2026, pre-traction. Built to learn the whole loop; not founding again.
My role
Everything: strategy, research, interface, release governance, and the evaluation program.
Context
Furnishing a home is a dozen linked purchases over three to nine months, made by someone who comparison-shops by default and does not want an AI to decide for them. Search engines answer one query at a time; marketplaces answer with ten thousand results. Prox sits in between: you describe the room, it asks the one or two questions that matter, returns a small set with reasons, and remembers the project.
I built it solo — the product decisions, the interface, the retrieval system, and the release process. The part I'm proudest of is not the build. It's that I can tell you, with evidence, what's wrong with it.
The product
The retrieval layer is a RAG pipeline: a user turn is extracted into structured context (room, budget, style, intent, confidence), turned into search terms, fused against vector and keyword retrieval over the catalog, filtered, and handed to the model to explain. Migrating the first keyword search to semantic retrieval cut the typical session from six search turns to two.
The interface decision that mattered most was the clarifying panel: when extraction is uncertain, the system asks a short structured question instead of guessing — purpose, style direction, budget — and only then retrieves. The panel is the deliberation surface, not a modal interruption. Whether the system fires it at the right moment turned out to be the central quality question of the whole product.
Saved items go to a project board with decision states (Interested / Considering / Decided / Rejected). I shipped the four-column structure as an explicit hypothesis with a falsification trigger in telemetry: if 80%+ of items never leave the default column, the board collapses to a flat list in v2.
The clarify flow in production: three structured questions, then a small curated set with reasons and a chat bar to refine. Left to right: purpose, style, budget, results.
Release governance
Taking the paid tier live was designed as a single reversible switch: allowlist-gated on real Stripe billing, checkout-to-entitlement validated at $0, then public GA on July 12, 2026. Every production change is a separately authorized step with a named rollback. A ten-assertion security gate — tenant isolation, ownership-scoped access, consent signals (GPC/DNT), right-to-erasure — runs on every release.
Before flipping three new surfaces on at once, I ran a pre-GA dogfood against a production build with production flags: automated boot and read-path checks on every surface, and a written manual checklist for the write flows that would have created junk rows in the live database if automated.
The evaluation program
My first instrument was an overall quality score. It told me the system got worse; it never told me which component to open. So I rebuilt the program around a different question: when it fails, where did the failure originate?
Persona and dataset. I wrote a versioned persona — the trigger-window homeowner — with operational definitions, explicit exclusions, and ten falsification triggers. From it I generated a 60-query iteration set stratified across eight persona cells plus an edge cell, each query carrying the claims it tests and the behavior expected.
Labeling. I hand-labeled all 60 rows against a four-dimension rubric (Relevance, Specificity, Factuality, Actionability), writing a rationale for every score. Categories emerged bottom-up from what I saw, not from a textbook list. Each tag got an operational definition, a positive example, a near-miss, and a boundary rule, and each failure was attributed to the most upstream layer at which it became inevitable.
The finding. Taxonomy v1.1 locked at 25 tags and 163 failure instances across 47 of the 60 rows. 71% of instances attributed to one layer — context extraction — up from 47% in the eight-row discovery sample. The fix target was not the generator, not retrieval, and not the panel-firing rule I'd suspected.
L2 · context extraction116
L7 · retrieval fusion33
L8 · generation12
L9 · post-filters2
Failure instances by originating layer, Foundation baseline run (n = 163 instances, 60 queries, single rater). Layers 1, 3–6, 10–11 recorded no attributable instances in this single-turn harness.
The distribution only concentrates like this because of the attribution rule. Naively, most of these would have landed on the generator.
Falsifying my own hypothesis
Three near-identical queries in the same cell — homeowners closing on a house, same need, slightly different phrasing — got three different decisions about whether to fire the clarifying panel. My hypothesis: the rule keyed on help-seeking phrasing ("where do I begin?") rather than genuine vagueness.
Instead of writing that into the taxonomy, I ran a 60-row cross-tab over six candidate features. Help-seeking phrasing had no signal. What actually drove panel firing was the extracted confidence and intent — which meant the panel rule was calibrated correctly and the bug was one layer upstream, in how the extraction prompt assigns confidence to entire persona cells. I rewrote the findings to match the evidence and moved the fix.
0.93×lift from help-seeking phrasing — my hypothesis. No signal.
4.0×lift from extracted confidence = low
2.5×lift from extracted intent = exploratory
Panel-firing lift by feature, 60-row cross-tab. Re-run after the full sweep produced identical values.
Judges and gates
Choosing a judge. Before trusting an LLM-as-judge for head-to-head comparisons, I measured self-disagreement on identical re-runs. A newer, more capable model flipped its own verdict 17% of the time; I locked an older model at temperature zero instead. Reproducibility beat capability.
Running the gate on my own work. I pre-committed a ship/hold rule, then tested a board-context prompt I'd redesigned against the shipped version: 15 head-to-heads under the locked judge plus a deterministic zero-products tripwire. It lost 10–4–1. I retired it. The same run exposed a retrieval bug in the live version — a board's stated needs never reached retrieval — which I fixed in code, taking off-target recommendations from 4 of 7 to 0 of 7.
Restating an unreachable bar. An advisor set recall@10 ≥ 0.80 as the retrieval acceptance criterion. I built 150 ground-truth queries in two disjoint sets, certified them within 0.02 of each other, and found 31% of gold items were reachable only by direct catalog draw — the ceiling was around 0.5. We restated the bar as ceiling-aware rather than shipping against a number that couldn't be hit.
Killing a bad gate. For the room-render feature, a pixel-drift quality gate rejected 89% of good renders and scored the true failures best. The real failure mode was collateral object removal. I replaced it with an object-level guard — inventory furnishings before and after, flag what vanished outside the request — at roughly two cents a render.
CandidateBoard-context prompt v2 (mine)VerdictHOLD · lost 10–4–1
Side effectRetrieval bug found in shipped v1After fixoff-target 4/7 → 0/7
JudgeOlder model, temperature 0, 17% flip rate avoidedTripwiredeterministic zero-products check
What it changed
The taxonomy alone is a backend-prioritization artifact. Read together with the persona brief, it became the case for a redesign: several failures that looked minor in the counts were load-bearing interface gaps, because the single-turn harness couldn't measure surfaces that didn't exist yet — project memory, room-segmented results, plans as objects the user can edit. That mapping drove the next epic, with a quantified target of cutting extraction-attributed instances by at least half before any prompt experiments resume.
The method is public: the categories, the attribution rule, the judge prompt, and a runner you can execute without an API key. github.com/proxdesign ↗
Limits
Single rater, so the categories are internally consistent and not independently validated. Single-turn synthetic queries, so anything a follow-up would recover still counts as a failure, and turn-two behavior is under-measured. And Prox is pre-traction: this is a case study about how a product was built and how I know what's wrong with it — not about growth.
Capital One Travel · 2022–2024 · Design Strategy Manager
From 30 competitor screens to a travel hub vision
Competitive analysis usually produces a screenshot deck nobody opens twice. I ran it like qualitative research instead — coded, counted, then translated into a structure the team could build toward.
DiscoverBuildEvaluateShip
Setting
Capital One Travel, growing 84% year over year, with a mobile hub that had accreted features faster than it had been designed
Method
30 competitive and comparative home screens · thematic coding of every content block · prevalence by type · directional framework · vision prototype
My role
Initiated and ran the analysis; built the framework and the vision; presented to product leadership
Outcome
Fed the team's product-vision work; the methodology earned formal company recognition and became a repeatable process
Context
Travel is a category where people start on one platform and book on another, so the hub is judged against everyone else's. Our market analysis was ad hoc — someone would pull up a competitor when a question came up and the answer would live in that one conversation. I wanted a way to learn from the market that was systematic enough to point a roadmap at.
Coding the screens
I collected the home screens of 30 platforms — online travel agencies, airlines, card-issuer travel portals, and a few comparative apps outside travel — and coded them the way you'd code interview transcripts. Every content block on every screen got a tag: welcome, service or offering type, search, promotional content, brand content, important information, account and rewards information. Open coding first, then consolidation into a stable set, then a count.
Counting is the step most competitive analyses skip, and it's the one that turns opinion into a finding. Seventy-eight percent of platforms led with their offering types; roughly half put search on the home screen at all; only a third spent hub real estate on brand content. Account and rewards information was rare in the set — and it was the one thing a card issuer could do that an OTA couldn't.
Service / offering type78%
Promotional content59%
Important info59%
Welcome56%
Search56%
Brand content37%
Share of the 30 home screens carrying each content type. Account/rewards information was coded separately as the issuer-specific differentiator.
The directional framework
Prevalence plus position became a framework: a stacked structure of what belongs on a travel hub, in what order, and which blocks are table stakes versus where Capital One could differentiate. It's deliberately not a wireframe — it's the argument for one, with a number behind every row. That made it usable by product and business partners who'd never open a Figma file, and it made the conversation about what to leave out as concrete as the one about what to add.
The vision
I translated the framework into a vision for the mobile hub: quick actions for the four things people come to do (book, lounges, trips, price alerts), search up top, a resume-where-you-left-off module, upcoming trips, inspiration, then the issuer-only layer — rewards and credits, card benefits — followed by offers, support, and editorial. Each section maps back to a row of the framework, so the vision could be defended block by block rather than as a matter of taste.
The prototype was presented as a walkthrough to product leadership and fed the team's product-vision work. The coding-and-counting method was written up as a repeatable process and earned formal company recognition.
Left: the three steps on one slide — a coded competitor screen, the directional framework with prevalence, the vision. Right: the full hub vision.
What I'd tell you in the room
The transferable part isn't the travel hub. It's that competitive analysis becomes evidence the moment you code and count it, and evidence is what lets a strategist move a roadmap without a title that says "product." I've used the same move since — on Prox, the failure taxonomy is the same discipline pointed at model output instead of competitor screens.
A vision is a direction, not a spec. Parts of it fed the roadmap and the framework outlived the deck; I'm careful not to claim more than that.
Capital One Travel · 2022–2024 · Design Strategy Manager
Keeping the experience honest through 84% growth
Hyper-growth is when quality quietly slips. Three pieces of work that kept the user's voice in the roadmap while revenue nearly doubled.
DiscoverBuildEvaluateShip
Setting
$45M → $83M in a year; NPS 47–51 against a travel-industry norm of 18–32
Cadence I ran
1:1 roadmap planning with two product teams; cross-functional design reviews with product, engineering and partners including Hopper, Legal and Compliance
Outcome
38 insights → 17 roadmap-ready proposals, several adopted into the 2024 roadmap; traveler-profile MVP shipped; itinerary research became a year-long build
1 · The usability study
Usability showed up as a theme among NPS detractors, but survey verbatims didn't say what was hard. I co-led an open-ended usability study in Q3 2023 — 13 observed 30-minute sessions with Capital One associates across the flight and hotel funnels — to establish an experience baseline and find what the surveys couldn't.
Five things came out of it that shaped how the team talked about the product: people explore elsewhere and book with us for the earn rates, so we had to make exploring worth doing here; they need to trust the value of a booking on both price and quality; they need to trust the platform broadly enough to find and use the features they value; they expect loyalty to be rewarded; and they expect personalization and are willing to answer questions to get it.
Underneath the themes were 38 specific insights, synthesized into 17 prioritized opportunities with a set of design heuristics — explore, compare, book — that gave the team evaluation criteria rather than a list of complaints. Several made the 2024 roadmap with full stakeholder consensus.
13observed 30-min sessions with associates, flight + hotel funnels
5experience themes
38actionable insights
17prioritized roadmap opportunities
2 · Unblocking the traveler profile
A traveler-profile feature had stalled on prioritization: too many candidate features, partners across two companies, and no shared way to decide. I ran the experience planning: a feature audit from existing research, then a 2×2 that separated what we were confident about from what needed more discovery, then a Now / Next / Beyond sequence tied to quarters.
The mapping did the political work. Features with strong evidence and high importance went to Now; things we liked but couldn't yet defend went to discovery. Cross-company stakeholders aligned on the sequence, and the MVP shipped.
High confidence · high convenienceReady for final design — into Now
High confidence · low convenienceDesign it, sequence it — Next
Low confidence · high convenienceNeeds discovery before commitment
Low confidence · low convenienceParked with a stated reason
NowQ4 / Q1 · portal-focused intent
evidenced, high-importance profile fields
saved-traveler basics
NextQ2
preferences that need one more round of testing
BeyondQ3 / Q4 · portal, offers, experiences
personalization-driven ideas pending discovery
Reconstructed from the experience-planning deck; feature-level detail withheld.
3 · Itinerary research
Post-booking was the least-examined part of the journey. I led itinerary validation research — a 122-person survey followed by eight in-depth interviews with concept testing — in partnership with product and design. The findings separated MVP updates from post-launch exploration and led to a year-long development initiative: three new screens and a data integration with Hopper.
What it added up to
None of these were dramatic. Together they meant that through the fastest growth the platform had seen, roadmap decisions stayed tied to evidence and NPS held at 47–51. I learned to use research less as validation and more as the thing that builds consensus across two product teams and a partner company.
Capital One materials are confidential; frameworks on this page are redrawn and figures are as reported internally.
EY for Barclays · 2020–2021 · UX Research & Strategy Manager
Discovery for a freelancer banking platform
A Fortune 500 bank saw 57 million US gig workers with no one serving their money, their work and their community together. We found out what they'd actually want.
DiscoverBuildEvaluateShip
Question
Is there a unified banking-and-jobs platform freelancers would trust a bank to build — and what goes in the MVP?
Method
29 moderated interviews across 3 cities · storyboarded concepts · card sorting and points-to-features · 51-question survey, 450+ responses
My role
Led the research plan end to end and co-authored the platform strategy point of view
Outcome
Three platform pillars, user modes, partnership models and a prioritized MVP feature set
Context
The gig economy was growing at roughly 10% a year, freelancers were carrying more financial risk than employees, and the tools they used — for finding work, managing it, and managing money — were scattered across a dozen apps. The bank had an opening, a lot of established competitors, and no evidence yet about what a differentiated product would be.
Approach
We ran qualitative discovery into quantitative validation. Interviews and storyboarding refined five candidate concepts down to three — Find Your Gig, Coaching & Insights, and Finances — which 29 freelancers reacted to across four activities, including card sorting and a points-to-features exercise that forced trade-offs. The survey then tested the concepts and feature interest at scale, with willingness-to-buy questions to separate "nice" from "would pay."
The research journey: kick-off and sense-making, interview prep, concept testing and validation, quantitative survey, analysis and recommendation.
What we found
The insight that defined the MVP was simple to say and hard to see without the research: freelancers can't connect what they earn to how they get paid — job data and financial data live in different apps, and the anxiety lives in the gap. That was the thing a bank could uniquely close. Three more themes carried the rest of the strategy. Trust: a bank behind the platform was itself the differentiator — freelancers valued security and trustworthiness competitors couldn't easily replicate. Community: coaching and mentorship mattered for professional and financial growth, not just networking. Guaranteed payments: a specific, monetizable pain for freelancers waiting 30+ days to get paid.
The participant analysis produced a segmentation that shaped feature priority: four user modes on axes of experience and network dependence — Nest, Maintain, Wander, Build — each wanting a different first feature.
User modes and the survey's feature-interest read by mode, which let us see how interest shifted between segments.
The strategy
The point of view landed on three platform pillars — finance management, work management, and a freelancer community with cross-platform insights — and named the competencies a platform needs to be worth building: facilitating multiple sides, generating network effects, and the ability to scale. We evaluated four partnership models (marketplace, extended core, strategic alliance, software-as-a-service) with the partners each would require, so leadership could choose a path rather than a feature list.
The MVP surface and the ecosystem it would need. Client anonymized in the deck as "a Fortune 500 bank."
What I took from it
This is where I learned to move from qualitative discovery to quantitative validation without losing the thread — and that a strategy document earns its keep by making the trade-offs visible, not by hiding them. Both habits show up directly in how I built Prox's persona and iteration set five years later.
The honest limit of consulting work: the strategy earned a three-month extension and shaped the MVP definition, and then we handed it over. I can tell you what we recommended and why; I can't tell you how much of it Barclays built.
The working method behind the Prox program, written so someone else could run it. None of this is novel; most of it is UX research discipline applied to a system that talks back.
1 · Start from a person, not a metric
A versioned persona with operational definitions, explicit exclusions ("what they are not"), and falsification triggers that would invalidate it. The iteration set is generated from the persona and stratified by cell, so every row carries the claim it tests. When the persona is wrong, the dataset tells you.
2 · Read rows before naming anything
Label by hand, write a rationale per score, and let categories emerge. The fourth question on every row — "what's here that has no name yet?" — is where the taxonomy comes from. A category isn't real until it has an operational definition, a positive example, a near-miss, and a boundary rule.
3 · Attribute upstream
Every failure is assigned to the most upstream layer at which it became inevitable. This is the rule that makes the distribution mean something: without it, failures pile onto the generator and you fix the wrong thing. With it, they concentrate, and concentration is what makes the result actionable.
4 · Test your own hypothesis at population scale
A single row gives you a symptom; a scenario pair gives you a hypothesis; a cross-tab over the whole set gives you the root cause. Skip any of the three and you ship the wrong fix. Say what you expected before you measured.
5 · Lock the judge, pre-commit the gate
Measure an LLM judge's self-disagreement on identical re-runs before trusting it, and prefer reproducibility over capability. Write the ship/hold rule before the results exist, add a deterministic tripwire the model can't argue with, and run it against your own work first.
6 · Name the limits
Single rater. Single turn. Sample size. Synthetic share. Naming them plainly is what makes the number believable; an unqualified result reads as marketing.
The artifact from an actual pass — categories, method, judge prompt, schema, and a runner — is public at github.com/proxdesign ↗.
Product strategist in Chicago. Discovery, prioritization and delivery for seven years; the last twenty months building and evaluating an AI product on my own.
Path
Prox (2025–) — Founder, Product & Design. Strategy, interface and evaluation for an AI discovery product; live with a paid tier, pre-traction.
Prudential Financial (2024) — Contract UX research lead for enterprise product discovery.
Capital One (2022–24) — Design Strategy Manager on Capital One Travel: discovery, MVP prioritization and delivery through 84% growth.
Fifty Thousand Feet (2021–22) — Lead Brand Strategist: positioning and go-to-market for WEX and Sesami.
EY (2019–21) — UX Research & Strategy Manager: product discovery for Barclays and Morgan Stanley.
IIT Institute of Design (2019) — MBA + Master of Design.
The honest version
I've spent my career on the discovery half of product — find the problem, define the bet, check the result — and I design as well as define; the Prox interface is mine. If your team needs someone who can figure out what an AI feature should do, make it usable, and tell you honestly whether it's working, that's the job I'm good at.
I built Prox to learn the whole loop, and it did that. I'm not founding again.
Chicago is home. Outside work I build furniture; the modular shelf I designed and prototyped in my Lincoln Park workshop is where Prox started — as a physical product, before it became a discovery problem.
