The Career Story:
Ten Years of Building Decision Systems
A chronological account of how one PM's thinking evolved across four companies, five industries, and ten years — and the single architectural pattern that connects every initiative.
Download PDFAuthor
Larry Hackney
Companies
USAA · iPROMOTEu · Tend · Productable
Chapters
5 companies + Conclusion
Read Time
~20 minutes
"Ten years. Four companies. Five industries. One pattern: fragmented signals making inconsistent decisions."
Every initiative in this document is a variation on the same architectural problem. In every case, the fix was the same: build the layer that normalizes the inputs before the system makes decisions. This is the career story behind the white paper.
Learning to See the System
Every product problem is a system problem in disguise. At USAA I learned to stop solving symptoms and start mapping the architecture underneath them — the behavioral thresholds, the data silos, the decision moments that no one had connected before.
TL;DR
Four roles across five years at USAA taught me that the most valuable product work is invisible: it's the onboarding journey no one designed, the cross-sell signal no one connected, the content system no one built a template for. The pattern across every initiative was the same — find the fragmented signal, unify it, and let the system make better decisions.
5 yrs
Across 4 roles at USAA
$975K+
Combined incremental revenue impact
25%
Reduction in deposit-related support calls
Chapter I complete
“Every product problem is a system problem in disguise.”
Next: iPROMOTEu (First Tour) — Scaling the Platform
Scaling the Platform
A platform that can't deploy fast can't learn fast. At iPROMOTEu I learned that the most important product work isn't always visible to users — sometimes it's the infrastructure that lets you ship, test, and iterate at the speed the market demands.
TL;DR
Six months at iPROMOTEu's first tour was a masterclass in platform modernization. A monolithic architecture was throttling deployment velocity. A fragmented sales process was limiting revenue. Manual vendor workflows were capping scale. The pattern: find the constraint, remove it, and let the system breathe.
2×
Deployment frequency increase
$275K
Annual cost savings from API automation
4%
ARR increase from CRM platform
Chapter II complete
“A platform that can't deploy fast can't learn fast.”
Next: Tend — Compliance as Architecture
Compliance as Architecture
Compliance is not a constraint on product design. It is a system state. When you treat regulatory requirements as feature patches, they accumulate into technical debt. When you treat them as architecture, they become a foundation for trust.
TL;DR
Five months at Tend was a concentrated lesson in cross-border product complexity. Building across a Mexico banking entity and a U.S.-regulated institution meant every product decision had two compliance interpretations. The insight: compliance conflicts discovered late are expensive. Discovered early, they're just requirements.
$400K+
Rework prevented through compliance alignment
+27%
Activation increase from state-driven onboarding
+8%
30–60 day retention improvement
Chapter III complete
“Compliance is not a constraint on product design.”
Next: Productable — Designing the Innovation System
Designing the Innovation System
Innovation doesn't fail because people lack ideas. It fails because the system that processes ideas lacks structure. A well-designed innovation pipeline is a decision system: it normalizes inputs, applies consistent evaluation criteria, and produces predictable outputs.
TL;DR
Productable was a different kind of product problem. The product wasn't a consumer app or an enterprise platform — it was an innovation management system. The challenge was the same pattern I'd seen everywhere: fragmented inputs, inconsistent decisions, and a system that couldn't compound. The fix was the same too.
+12%
Innovation Advancement Approval increase
+10%
Innovation Review Request increase
6%
Reduction in off-ramping
Chapter IV complete
“Innovation doesn't fail because people lack ideas.”
Next: iPROMOTEu (Senior) — Unifying the Platform
Unifying the Platform
The most expensive problems in enterprise software are not bugs. They are architectural decisions made by default — systems that grew organically, each maintaining its own version of the truth, each making decisions based on incomplete information. The fix is always the same: build the decision layer.
TL;DR
The second tour at iPROMOTEu was the synthesis of everything that came before. Five major initiatives, all variations on the same theme: fragmented systems making inconsistent decisions. Identity signals living in five places. Payments flowing through intermediaries. Legacy architecture creating defects. Vendor data trapped in one-off integrations. The pattern was clear. The solution was architectural.
25-35%
Support volume reduction from identity unification
40%
Defect reduction from platform rationalization
3×
Vendor integration scale increase
The Through-Line
Ten years. Four companies. Five industries. One pattern.
Every initiative in this document is a variation on the same architectural problem: fragmented signals making inconsistent decisions. The USAA onboarding system didn't know where a member was in their 90-day journey. The Tend KYC system didn't know a user's verification state. The iPROMOTEu identity system had five different versions of the same user. The vendor integration framework had no common data model.
In every case, the fix was the same: build the layer that normalizes the inputs before the system makes decisions.
This is not a coincidence. It is the nature of complex systems. They grow organically. Each team solves its own problem. Each system maintains its own version of the truth. And then, at some point, the inconsistencies accumulate into a class of problems that can't be solved at the feature level — they can only be solved at the architectural level.
The work I'm most proud of is not the features I shipped. It's the systems I designed that made the features possible — and the decisions I made about what to build versus what to architect.
That's the through-line. That's the argument. And that's what I bring to every product problem I work on.
Five Principles
Find the fragmented signal
Every expensive problem has a data architecture problem underneath it. Before you solve the symptom, find the signal that the system is missing.
Normalize before you decide
Inconsistent inputs produce inconsistent decisions. Build the normalization layer first — the decision quality follows from it.
Design for state, not steps
Static flows assume every user follows the same path. State-aware systems know where each user is and deliver the right intervention at the right moment.
Move validation upstream
Whether it's compliance requirements or user intent signals — catching it early is always cheaper than catching it late. Upstream validation is a product quality investment.
Fix the system, not the symptom
The most expensive problems in enterprise software are architectural conditions masquerading as bugs. The only fix is architectural.
The Thematic Argument
Read the White Paper
The Career Story is the chronological argument. The White Paper is the thematic one — synthesizing all 10 case studies into a single architectural thesis about decision systems at scale. Together they tell the complete story.
The Decision Layer: White PaperThe Operating System
A System of Systems
ibuildsystems.io
Four frameworks. One repeatable system. Applied across banking, fintech, government, and B2B SaaS to turn broken workflows into scalable revenue engines.