The most unconventional career paths sometimes lead exactly where you need to go.
The best product management training I ever received had nothing to do with product management.
After a year working at a boarding school outside Boston, I decided to head west.
I spent three winters in Colorado (two in Crested Butte, one in Telluride, then back to Crested Butte) working in ski shops and, eventually, as a fly fishing guide on the state's rivers and reservoirs. At the time, it felt like I was just living the dream between powder days and river runs. I wasn't building anything. I wasn't managing roadmaps or writing PRDs. I was fitting boots and reading water.
But those years quietly taught me everything I'd later need to know about leading products, teams, and strategy. Lessons I couldn't have learned in a business school classroom or an entry-level tech role.
Here's what the mountains and rivers actually taught me.
Customer Empathy Isn't a Framework. It's a Practice.
In product, we talk a lot about understanding the user. We run surveys, build personas, and analyze funnels. What I learned guiding fly fishing trips was more visceral than any of that.
Every client who stepped into the water came with different goals, different anxieties, and a different definition of success. Some wanted to land a trophy trout. Others just wanted to be present in nature and not feel stupid. A few were celebrating milestones. A lot were beginners who'd never held a rod.
My job wasn't to deliver the same fishing trip to everyone. It was to understand what this person, on this day, actually needed, and then build an experience around that. If the fish weren't biting in the usual spots, I didn't pretend otherwise and stick to the plan. I moved us. I changed technique. I adapted.
That's product thinking. Great products aren't built around feature requests. They're built around deeply understood desired outcomes. Users rarely know what they want in the abstract; they know what frustrates them and what success feels like. Your job is to bridge the gap.
Translating Vision Across Different Audiences
Running a guide operation meant explaining the same concepts (reading current, matching the hatch, mending line) to wildly different people every day. A retired engineer and a nervous first-timer needed the same information delivered in completely different ways.
I got good at asking questions first. What is your goal for today? What brought you here? Have you fished before? What do you already know? Before I said a single technical word, I needed to know who I was talking to.
Product leaders face this exact challenge constantly. The way you talk to engineers is different from how you talk to sales, which is different from how you present to the board, which is different from how you communicate with customers. The underlying vision has to stay consistent, but the translation has to be precise.
If you deliver the same message to every audience, you're not communicating. You're broadcasting.
Reading Conditions, Not Just Plans
The river taught me that no plan survives first contact with the water.
You could scout a stretch, pick your spots, and show up with a clear game plan, and by 9am everything had changed. Water levels up. Fish pushed into slower pockets. The hatch you were counting on, not happening. At that point, you had two options: defend the plan, or read what was actually in front of you.
Good guides read conditions. If fish weren't biting in one stretch, you moved. If a particular fly wasn't working, you changed it. If a client was getting frustrated with their casting, you simplified the technique rather than pushing harder on the original approach. Every adjustment was data-driven. Not based on what you hoped was happening, but what you could actually observe.
This is exactly what product leadership looks like inside a fast-moving company. Roadmaps are hypotheses. The map is not the territory. Strategic pivots aren't failures; they're the job. The skill isn't just making the call; it's learning to make it quickly, without letting ego get in the way of the right answer.
Systems Thinking Before I Had a Name for It
Working the rental shops in Crested Butte and Telluride was where I learned to think in systems.
The shop I worked at in Telluride was the busiest on the mountain. The operational puzzle was constant: how do you move hundreds of people through a rental flow efficiently, minimize wait times, keep the floor from descending into chaos, and still deliver a good experience to everyone? You couldn't just optimize one step. Fitting boots faster didn't help if the binding check was a bottleneck. You had to understand the whole flow, where pressure built up, and how decisions upstream created problems downstream.
Crested Butte was a different mountain, different clientele, different rhythm, but the same underlying challenge. Every season forced me to rebuild the mental model for a new context rather than just repeat what had worked before.
I learned that optimizing individual steps isn't enough. You have to understand the whole system. Every decision ripples outward: into capacity, sequencing, staff behavior, and customer experience. The same is true in product. Every roadmap decision has downstream consequences that aren't always obvious until you map the full system.
Product leadership isn't about building features in isolation. It's about orchestrating systems.
Where All of This Is Going Next
I carried these lessons through a career in hospitality SaaS, then into healthcare, where I now help lead product strategy for LiveData, a perioperative workflow platform serving 90+ hospitals. The stakes are higher, the complexity is greater, and the domain expertise required is deep. But the fundamentals have never changed: understand the people, solve the real problem, design systems that scale.
What has changed is the toolbox.
In the last few years, I've gone all-in on AI, not as a user, but as a builder. At LiveData, I've built five AI tools: one customer-facing product and four internal tools that have changed how our team does competitive research, strategy, customer success, and sales. Beyond that, I've developed several personal AI projects that have pushed me deeper into RAG pipelines, MCP architecture, and agentic workflows.
I work with large language models the same way I used to work a good stretch of river: with patience, attention to feedback, and a willingness to change your approach when conditions call for it.
The next chapter of product leadership isn't just about shipping features. It's about knowing which problems AI can solve, building the organizational trust to deploy it responsibly, and designing human-AI systems that actually work in production, not just in demos.
The people who will lead that work aren't just AI researchers or pure technologists. They're product leaders who combine domain expertise, systems thinking, and the hard-won human skills that no model has yet learned to replicate.
Turns out the Colorado outdoor industry was decent preparation for that, too.
Sometimes the most unconventional paths prepare you for exactly where you need to be.