ANDRES GARCIA
SENIOR PRODUCT MANAGER
Product Philosophy — How I Think. How I Build. What I Won't Compromise.
How I Think.
How I Build.
What I Won't Compromise.
0+
Years in Product
FinTech · AI · EdTech
$0T
Assets Migrated
Industry record
0M+
Users Served
Across platforms
$0B+
Payments Volume
Annual
5 Core PrinciplesSystems ThinkingFailure-First DesignCompounding Capabilities
13 slides · arrow keys
Core Belief
Most PMs manage features. I govern systems.
What That Means
Understanding how decisions, data, operations, and technology behave together under real conditions — not just in demos
System coherenceDesigning for failure before designing for success. Acceptance criteria must describe wrong behavior, not just correct behavior
Failure-first designTreating measurement as architecture. The signal you define on day one determines what the system can learn for years
Signal architectureOwning the consequence map — not just what we build, but what breaks when it doesn't work at scale
Consequence ownership
What It Does NOT Mean
Avoiding features or roadmaps. Features matter — but only as expressions of the system, not as the goal themselves
Ignoring user needs for technical elegance. The user experience IS the system, visible at the surface
Slowing teams down with process. Velocity is a product of clarity — not caution, and not effort
Pretending complexity doesn't exist. My job is to convert it into decisions — not manage it around teams
Teams optimize each metric independently, each team hits their number, and the product fails. Governing them separately is how you introduce systemic risk.
The Operating Model — How Every Product Decision Is Made
Five stages. One continuous loop.
Every product I've built operates on this model — technology, operations, and customer experience as one integrated system.
01
PRODUCT STRATEGY
What & why
Define failure first
→
02
DATA & SIGNAL
Signal architecture
Risk = backlog filter
→
03
SYSTEM DESIGN
How it works + fails
Measurement first
→
04
EXECUTION & TEAMS
Who owns what
Clarity = velocity
→
05
MEASURED OUTCOME
What actually changed
Capabilities compound
↻ FEEDBACK & LEARNING LOOP — System improves from real-world signal back into strategy
Five Governing Principles
P1
Define the failure mode first
P2
Risk is the real backlog filter
P3
Measurement before models
P4
Clarity drives velocity, not effort
P5
Capabilities compound; features don't
Principle 01
01
Define the Failure Mode Before the Feature.
THE PRINCIPLE
Most product teams write acceptance criteria that describe what should happen when everything goes right. I require two types on every product I own:
HAPPY PATH
What correct behavior looks like when everything works
FAILURE PATH
What the system does when it breaks — error states, rollback conditions, edge cases
REAL EXAMPLE — USAA TDV INTEGRATION
Before writing a single user story for the Trusted Device Verification system, I documented:
Q: What happens when a legitimate Zelle payment triggers a false-positive block at 2am?
→ Defined: member message, support escalation path, transaction state, rollback protocol
Q: What is the system state if ML scoring service goes down mid-transaction?
→ Defined: fail-safe default behavior, graceful degradation, no money in limbo
Q: What happens when a device switches from mobile to web mid-session?
→ Defined: session continuity rules, re-scoring triggers, trust score inheritance logic
Failure-First vs. Happy-Path Only — Impact
"At $200B payment volume, 0.01% wrong behavior means thousands of irreversible financial decisions."
Principle 02
02
Risk Is the Real Backlog Filter. Not rank. Not pressure.
What Teams Optimize For
Backlog priority (story points)
Feature rank drives roadmap — downstream risk is invisible
Stakeholder pressure & loudest voice
Stakeholder preference ≠ user consequence
Sprint velocity (output)
Output without outcome = waste at scale
Engineering "done" definition
"Eng done" + operationally not ready = production crisis
What I Optimize For Instead
Downstream dependency risk
One wrong priority cascade = regulatory exposure
System consequence if this fails at scale
Connected consequence map before sequencing
Decision velocity (outcomes)
Clarity eliminates the re-work that kills speed
Multi-dimensional readiness criteria
Engineering + operational + risk must all clear
Thinkorswim: Three Escalations. One Hold.
Business pressure was real: integration costs were high, and every week of delay had measurable financial impact. I received three separate escalations to compress wave sequencing timelines. I held everyone — because at $1.9T in assets, a cascading failure from rushing wave 2 doesn't have a clean rollback.
Final wave: 1.8M accounts, $350B — zero disruptions. Every wave that launched, worked.
Principle 03
03
You Can't Measure What You Didn't Design For.
THE MISTAKE MOST TEAMS MAKE
Ship AI features → discover they can't measure if they worked → ship more features → model trained on noise → system gets worse over time, not better.
WHAT I DO INSTEAD
Build measurement infrastructure first. Define the interaction taxonomy — which events signal intent vs. noise — before 500K users begin generating them. The model can only learn from what you designed it to receive.
Real Example — AI Personalization: 500K+ Users
STRONG Signal
Completion: content watched >80% with avg dwell ≥ threshold
MEDIUM Signal
Click-through: surface-level interest; NOT preference signal alone
EXCLUDED
Autoplay complete: passive — explicitly EXCLUDED from training signal
NEGATIVE Signal
Skip pattern: negative signal — weighted against content affinity
The Compounding Effect of Signal Quality
The signal architecture you choose on day one determines what the system can learn — for years.
Principle 04
04
Velocity Is a Product of Clarity — Not Effort.
What Slows Teams Down
Ambiguous acceptance criteria
"Done" means different things to engineering, QA, and risk
Competing priorities with no ranking
Every team optimizes locally — no shared consequence map
Undefined launch readiness
Teams declare "ready" independently with no shared criteria
Stakeholder misalignment at launch
Discovered at launch — not resolved during planning
What I Do About It
Written product decisions with explicit trade-offs
Documented, not discussed. Shared before sprint begins.
Risk-ranked backlog with dependency map
Downstream impact visible before prioritization decisions
Multi-dimensional readiness gates
Engineering + operational + risk must all clear before launch
Shared decision forums with defined escalation paths
Hours to resolve, not weeks. Speed is a structural outcome.
Evidence It Works
Thinkorswim: 3 orgs that had never shipped together. Zero post-launch emergency rollbacks across 17M accounts.
USAA Payments: $200B platform. Major capability changes. 99.99% uptime maintained throughout.
AI Platform: 500K users. Every personalization feature shipped with a defined experiment. Zero unvalidated AI shipped.
Speed is not a culture trait or a hiring decision. Speed is what happens when teams share the same model of the problem.
Principle 05
05
Capabilities Compound. Features Don't.
FEATURE THINKING — Linear value
✗ Ships once, delivers value once
✗ Equal effort for each new feature
✗ Creates technical debt that compounds
✗ Cannot learn without manual intervention
CAPABILITY THINKING — Compounding value
✓ Experimentation platform: every decision validated forever
✓ Signal architecture: every model trained on clean data
✓ Readiness gate framework: never redefined per project
✓ Fraud model: gets more accurate with every transaction
Proof — Life Leadership: 10 Years, One Compounding System
0TB+
Monthly Data
Processed
Compounding vs. Linear Value Over Time
The PM question is not "what should we ship?" It is "what should we build that makes every future ship better?"
The Hard Calls — What I've Learned to Refuse
After 18 years, certain compromises always cost more than they save.
I won't define "done" as engineering complete — even under launch pressure
Technically complete but operationally broken is the most dangerous state in production. It's a system that functions in QA and fails in the real world.
USAA: held waves multiple times on operational signals. Every wave that launched, worked. Zero post-launch emergency rollbacks.
Zero rollbacks. $1.9T in assets. All waves performed.
I won't ship AI features without measurement infrastructure — even when stakeholders want visible AI progress
At 500K users, a model trained on noise doesn't produce bad recommendations — it produces a system that actively gets worse over time.
Building the measurement system first isn't slow. It's the only way to know if the AI is working.
+25% engagement, +65% progression. Measurement came first.
I won't optimize one platform metric at the expense of connected metrics — even when the primary metric looks excellent
Completion rate, fraud rate, and authorization rate at $200B volume are one integrated system. Tightening fraud controls looks good on the fraud metric and breaks completion rate. All three governed simultaneously — never independently.
+17% revenue. -12% fraud. 99.99% reliability. Simultaneously.
I won't accelerate migration wave sequencing beyond risk tolerance — even with significant business pressure
At $1.9T in assets, a cascading failure from rushing wave sequencing doesn't have a clean rollback path. The accounts enter a split state — partially migrated, partially on legacy — with undefined behavior across auth, funds, and trading.
Final wave: 1.8M accounts, $350B. Zero disruptions. Held every time.
The Tradeoff Framework — How I Navigate When Objectives Conflict
The ML answer optimizes the model. The product answer optimizes the system.
TENSION
ML / ENG ANSWER
PRODUCT ANSWER
REAL-WORLD EVIDENCE
Move fast — every week of delay has measurable financial cost
Risk of changing must always be lower than cost of not changing. Reliability is non-negotiable; velocity is optimized within that constraint
Thinkorswim: Held 3 acceleration requests. Final wave: 1.8M accounts, zero disruption
Deeper models produce higher offline accuracy scores — always worth the extra compute
A recommendation that arrives 800ms late is worse than a slightly less accurate one that arrives instantly. Usability can never be sacrificed for sophistication
<200ms latency SLA. Hard constraint. Model design had to operate within it
Standardization vs. Continuity
Force new patterns at launch — simpler architecture, less dual-path code maintenance
Forcing new patterns at the moment of highest disruption creates a second layer of friction. Trust is the product. Continuity is the feature
TDV / Thinkorswim: Preserved familiar flows at launch. ~85% RIA adoption post-stabilization — organically
Experiment Speed vs. Validity
Fast experiments = faster learning cycles. Call it early on trending data
A false positive at 500K users is expensive to reverse. Minimum sample size and confidence thresholds defined before any experiment launches. Speed never over validity
Zero experiments called early. Every AI feature shipped with a measured, validated experiment attached
⚖️
The PM principle:
The ML answer tells you what the model can optimize. The product answer tells you what the system must optimize — under real constraints, real latency, and real trust. These are rarely the same thing.
How I Assess a Product Environment
Within two sprints, I can tell whether a product org will scale.
None of these signals are about talent. They're about the operating model. Operating models can be fixed.
Signals of a Healthy System
✓ Teams argue about priority — not about what "done" means
✓ Shared definition of readiness already exists
✓ KPIs are connected, not siloed — no team owns just one metric
✓ System thinking is already embedded in the culture
✓ Engineering and risk attend the same launch criteria meeting
✓ Launch readiness is a shared responsibility
✓ The rollback plan exists before the go-live date
✓ Consequence awareness is part of the product process
✓ Post-launch monitoring was designed before the feature shipped
✓ Observability is a product requirement, not an afterthought
Signals That Require Immediate Attention
✗ "Done" is defined as engineering complete
✗ Operational readiness, user behavior, and risk are invisible in launch decisions
✗ Metrics are owned by separate teams with no shared success definition
✗ Local optimization will break global system coherence
✗ Roadmaps are outputs — not inputs to decisions
✗ Teams are shipping, not deciding
✗ Post-launch is when monitoring begins
✗ Failure discovery happens after customer impact, not before
✗ Stakeholder alignment is discovered at launch, not during planning
✗ Design reviews are a formality, not a decision forum
"The fastest intervention I can make in a struggling product org is to define what 'done' means, connect the metrics, and make the consequence map visible to every team."
18 Years of Outcomes — The Philosophy In Evidence
The work is the argument. Not this slide.
Principle-to-Outcome Map — All Programs
Compounding vs. Feature Value Over 10 Years (Life Leadership)
Five Principles — Cross-Platform Evidence
ZERO
Day-One Disruption
$1.9T · 17M accounts
+65%
AI Progression
500K+ users
Product Philosophy — Andres Garcia
The work is the argument.
Not this slide.
ZERO
Client Disruption on Day One
$1.9T migrated. 17M accounts. Auth, trading, and fund movement all operational simultaneously.
+25%/+65%
Engagement & Progression
500K+ users. Measurement came first. Signal architecture determined model quality.
99.99%
Platform Reliability
$200B+ volume. Three mandates governed simultaneously. No tradeoffs. One integrated system.
Product management at scale isn't about features.
It's about designing systems that don't fail.
ANDRES GARCIA
SENIOR PRODUCT MANAGER
Full Portfolio · Thinkorswim · TDV · AI · Payments · CX Systems