Loading

What I've Learned

Patterns That Scale from Startup to Enterprise

After building products from initial concept through acquisition and global scale, these are the frameworks and hard-earned lessons that emerged. Not rules to follow—patterns that proved resilient when everything else changed.

lightbulb

Clarity Through Ruthless Simplicity

Make the complex disappear, not just simple

What I Used to Think

Early at Fabric, I thought powerful tools needed to expose all their capabilities upfront. Our analytics engine could do incredible things—why hide any of it? The first versions overwhelmed users with options they'd never use.

What Changed My Mind

Different user types need different experiences. Engineers wanted more flexibility for their tools and dashboards, while C-Suite just wanted answers. We built a personalized generative dashboard with controls to change configs—ops people and engineers loved it. But the C-Suite just wanted an answer that made sense to them.

So we built an evals framework and a simple chat mode to help each type of user get to their answer faster while enabling deeper config for those who wanted it. At MSCI, when 4,000+ engineers adopted our AI tools, the pattern repeated. Engineers don't need another configuration screen—they need the tool to work immediately and get out of their way. The complexity should live in the engine, not the interface.

warning Hard Lesson

We built a personalized generative dashboard with controls to change configs—ops people and engineers loved it. But the C-Suite just wanted an answer that made sense to them, not more configuration options. We learned that different users need fundamentally different experiences. The solution was building an evals framework and a simple chat mode alongside the detailed dashboard, so each type of user could get to their answer faster in the way that worked for them.

The Framework

  • check_circle Start with the outcome: What does success look like for this user, right now?
  • check_circle Remove steps, not just clicks: Every workflow decision is cognitive load
  • check_circle Progressive disclosure: Show power only when it's needed, never before
  • check_circle Test with time pressure: If users can't figure it out quickly relative to the task they're trying to accomplish, simplify more
shield

Autonomy Over Automation

Amplify capability, personalize to the user, never replace judgment

What I Used to Think

Automation is always better. If we can make a decision for the user, we should—it's faster, more efficient, removes friction. The goal was to build a system that "just worked" without user input. One interface for all users was the most efficient approach.

What Changed My Mind

A financial advisor called, furious. Our "smart" portfolio rebalancing had made perfect mathematical sense but violated an unstated client preference we couldn't have known. He needed to control the final decision, not just review our output. That 95% retention rate? It came from giving advisors complete autonomy over their client relationships, not from automating decisions away from them.

But it's not just about autonomy—it's about personalization to the type of user. Some users just want to click the button and get the answer, others want suggestions with more control. Creating an experience that learns user preferences and adapts to who they are means those who want more control get it, while those who want simplicity aren't overwhelmed. At MSCI's AI platform, the same pattern emerged. The 5× velocity improvement came from amplifying what engineers could do, not replacing what they chose to do.

warning Hard Lesson

We built an "auto-optimize" feature that would maximize portfolio performance automatically. Customers hated it. Not because it didn't work—because it took away their agency. They wanted tools that made them better at their job, not tools that did their job for them. We replaced it with "optimization suggestions" that users could review and modify. Adoption went from 12% to 73%.

The Framework

  • check_circle Suggest, don't decide, then learn: Provide intelligence, give users opportunities to approve actions and learn their preferences, then adapt to the specific user
  • check_circle Transparent logic: Users should understand why the system recommends something
  • check_circle Easy adjust: Tweaking should be simpler than starting from scratch
insights

Impact Through Intelligent Focus

Measure what moves the needle, ignore everything else

What I Used to Think

More features = more value. If customers are asking for it, we should build it. Track everything, optimize everything, ship constantly. Growth comes from doing more.

What Changed My Mind

We felt we needed to build the feature that each new potential sale said they needed in order to buy, which sent us whipsawing around trying to solve disparate problems. When we realized what we were doing, we decided to focus on a few focused outcomes. The 8 we kept drove implementation time under 2 hours and retention to 95%. The features we didn't build were just as important as the ones we did—maybe more important, because they let us focus.

At MSCI scale, identifying the metrics that are actually driving client outcomes and actually driving business outcomes became critical. The hardest part is saying no to things that don't focus on those metrics. Intelligent prioritization means understanding the difference between what customers say they want and what actually drives their success.

warning Hard Lesson

We spent 6 months building a beautiful digital report generation solution at Fabric because "everyone wants better reporting." We had to rebuild it to focus on what the clients actually needed. The simple CSV export we thought was "too basic"? Used by 89% of customers. We learned to distinguish between what customers say they want and what actually drives their success. Now we instrument everything and let usage data tell us where to focus.

The Framework

  • check_circle Define success upfront: What are the 1-3 key metrics that actually drive the outcome we're looking for? How and why do we think those will drive the outcome?
  • check_circle Instrument before building: Measure what matters before you do anything—this applies to internal processes, sales, everything, not just code
  • check_circle Kill what doesn't work: If the specific metrics we're tracking aren't driving the outcome in the time relevant for our goal, cut it
  • check_circle Double down on wins: When something works, invest more before exploring new areas

What I've Learned About 0-to-1

These patterns emerged from building Fabric zero to $7.5M raised to acquisition, driving agentic product development within MSCI, and transforming MSCI from waterfall and revenue-driven to OKR and agile. Not theory—what actually worked when nothing else existed.

psychology Live in the Problem Before Building the Solution

After 300+ customer demos at Fabric, I learned more than any market research could teach. Early on, I thought I understood the problem from my finance background. I was wrong about 70% of it. The advisors' real pain wasn't lack of analytics—it was losing hours to manual data entry, client reporting, and not knowing how to apply their own frameworks to each client in a personalized way.

The pattern: Understand the root of the problem through small iterations. Talk to users before writing requirements. Watch them work. Find where they're using spreadsheets and duct tape—that's where the real opportunity hides.

speed Ship Something Embarrassing, Then Iterate

Fabric's first demo was embarrassing. Broken edge cases, no error handling, UI that looked like a programmer designed it (guilty). But it solved the core workflow. We got our first paying customer with that embarrassing prototype. They didn't care about polish—they cared that it saved them 5 hours a week.

The pattern: Ship earlier than you think. Find the people who want to be a part of the process to build. Ship it to real users in real workflows. Watch what breaks. Fix the painful parts. Repeat. Perfect is the enemy of learning.

diversity_3 Build the Team That Can't Not Ship Together

At Fabric, wearing every hat taught me that product isn't a solo discipline. The best outcomes came when engineering, design, and I sat together—not in meetings, but actually building. At MSCI, managing 23 people across 20+ countries, the same truth held: great products emerge from teams that communicate obsessively and trust deeply.

The pattern: Hire for collaborative energy over individual brilliance. Create tight feedback loops—daily standups, shared dashboards, open Slack channels. Remove blockers ruthlessly. Product leadership is 20% vision, 80% removing friction so teams can ship.

query_stats Let Data Inform Your Intuition

Our personalized portfolio creation feature had 4% usage. Meanwhile, the personalized portfolio suggestion approach got 90% adoption. The data didn't overrule intuition—it helped us understand what we were missing and why our initial approach wasn't resonating.

The pattern: Instrument everything from day one. Set up dashboards before launch. Review usage data regularly. When data conflicts with intuition, use that to know there's something you don't understand and find out why. Data augments intuition, providing a critical check on assumptions.

visibility Show Don't Tell

After joining MSCI, a large organization managing things in old-school waterfall style, leadership would ask how our team accomplished what we did. We'd clearly articulate our approach—OKRs, bottom-up empowerment, agile iterations. They'd say they understood, even articulate it back to us in ways that seemed like genuine understanding. Then they'd take actions that completely contradicted those principles.

This was a new lesson for me. In 0-to-1 startups, shared consciousness comes naturally—everyone builds together from scratch, creating a common lived experience. But in a larger, established organization, there's a separate consciousness born from different lived experiences. These two consciousnesses can only merge through new shared experiences, not through explanations of past ones. Understanding words isn't the same as understanding reality.

The only way to reach true alignment is to show, not tell. We're currently in the middle of transitioning teams bottom-up through demonstration—letting results speak louder than any explanation ever could. One team seeing another ship faster with OKRs is worth a thousand presentations about why OKRs work.

The pattern: Don't try to convince leadership top-down with words. Show results bottom-up with working teams. Let success be contagious. When people see tangible outcomes—faster shipping, happier teams, better products—they stop asking "how does this work?" and start asking "how do we do this too?"

Thinkers Who Shaped How I Build

These people influenced specific product decisions and how I think about building for human agency.

Charlie Munger

Mental Models & Inversion

"All I want to know is where I'm going to die, so I'll never go there."

His inversion principle shaped how I prioritize: instead of asking "what features should we build?", I ask "what would kill this product?" That's where I focus first.

Bret Victor

Interface Design & Thinking Tools

Visionary exploring how tools shape thinking and what's possible when interfaces amplify cognition.

His "Learnable Programming" essay influenced Fabric's workflow design: make the system's logic visible, not hidden. Users learn by seeing, not by reading docs.

Paul Graham

Startups & Clear Thinking

"Make something people want" sounds obvious but is incredibly hard in practice.

His essay "Do Things That Don't Scale" saved me from over-engineering early at Fabric. Those 300+ manual demos taught me more than any scalable onboarding flow could have.

Peter Attia

Medicine 3.0 & Personalization

Pioneered personalized, proactive healthcare focused on individual biomarkers and outcomes.

His emphasis on measuring individual variance influenced how I think about product metrics: aggregate stats hide important patterns. Track cohorts, not just averages.

Andrew Huberman

Neuroscience & Actionable Protocols

Translates complex neuroscience into implementable protocols for sleep, focus, and performance.

His ability to make complexity actionable shaped my product communication: give users concrete next steps, not just information. "Do this" beats "here's how it works" every time.

Jim Collins

Good to Great & First Who, Then What

"Great vision without great people is irrelevant. Get the right people on the bus first."

His research on what drives truly great companies shaped my core belief: the best strategy, technology, or market opportunity means nothing without exceptional people who are aligned, empowered, and passionate about the mission. Every breakthrough at Fabric and MSCI came from investing in the right team first, then figuring out where to go together.

Want to see these principles in action?

Check out my portfolio to see how these frameworks drove real outcomes at scale.