10% Luck, 20% Skill, 50% Pain

Years ago, while leading a platform modernization effort at Logi Analytics, I drew a pie chart on my whiteboard.

It wasn’t based on customer research, market analysis, or anything I learned in business school. It was based on a song I liked.

The song was Remember the Name by Fort Minor, and the pie chart was simply the percentages from the lyrics:

At the time, it was a combination of humor and hard-earned experience. The project was already teaching me that successful transformations require far more than technology alone.

In hindsight, it may have been one of the more accurate descriptions of product leadership I’ve encountered.

The 10-Year Rule

The story actually started years earlier.

While at Microsoft, I led a project exploring how software companies approached platform modernization. The software industry was changing rapidly. Open source databases such as MySQL were gaining traction, web applications were changing customer expectations, and new architectures and deployment models were emerging.

As part of the project, I spoke with software companies that had gone through significant platform transitions. One pattern kept appearing.

The products weren’t failing. In many cases, they were quite successful. The challenge was that years of success had accumulated into something else: architectural constraints, customer expectations, technical debt, and assumptions that no longer aligned with market direction.

The exact details varied from company to company, but the pattern felt familiar. At some point, many teams found themselves wrestling with the same question: Can we continue evolving what we have, or is it time for something more fundamental?

The timing wasn’t identical, but it often seemed to happen around the ten-year mark. I started thinking of it as the ten-year rule — not a law, more of an observation.

Years later, I found myself confronting the same pattern again.

What Is NGP?

Before moving into Product, I had spent several years as a sales engineer at Logi Analytics, where I built and scaled our OEM Sales Engineering practice. At its peak, we supported nearly thirty sales representatives and many of the company’s largest and most strategic opportunities.

Along the way, I had the opportunity to meet and learn from a wide range of software companies and product teams. As they embedded analytics into their own products, I got to see how they approached architecture, extensibility, user experience, scalability, and platform evolution.

Over time, patterns started to emerge. I also knew our own product well enough to recognize where it struggled.

Architecturally, it reflected decisions from an earlier era of software. The user experience reflected assumptions that were becoming increasingly dated. We had continued to evolve successfully, but many of the workarounds required to win larger opportunities suggested we were approaching the limits of incremental improvement.

When the company launched an initiative called NGP, short for Next Generation Platform, I stepped out of Sales Engineering and into Product to lead the effort.

Almost immediately, the organization divided into camps. One group believed the existing platform could continue evolving. Another believed more fundamental change was necessary. There was also a fair amount of skepticism. For some members of the legacy team, NGP felt less like an evolution and more like something being imposed upon them.

The debates often centered on architecture, frameworks, migration strategies, and emerging technologies. Angular was still relatively new at the time, and engineers had strong opinions about what technologies should define the future platform.

Those discussions mattered, but they weren’t the hardest part.

The hardest part was a deceptively simple question that kept surfacing:

What is NGP?

At first, I treated it as a product definition problem. Over time, I started to realize people were asking something deeper: Why are we doing this? What problem are we really solving? What happens to everything we’ve already built? What will the future look like? Where do I fit in that future?

Around that time, I worked with someone from our marketing team to create a video about NGP. Rather than explaining the platform ourselves, we decided to walk around the company and ask people a simple question:

What is NGP?

The answers were all over the map.

Some people talked about technology. Others discussed customers, architecture, innovation, or the company’s future. Everyone seemed to see a different aspect of the initiative.

The exercise taught me something important. People weren’t really asking for a definition of NGP. They were trying to understand what the change meant for them, their teams, and the company’s future.

At the time, I remember telling my colleague that I kept thinking about Remember the Name. I thought it was mostly because I liked the song’s energy.

Years later, I came to realize it was probably something else. The technology was only part of the conversation. NGP had become a vehicle for a much broader discussion about where the company was headed and how we would get there.

Most transformation efforts eventually converge on some version of the same questions. Today, many organizations are asking them about AI.

The technologies change.

The questions rarely do.

The Percentages

The whiteboard pie chart wasn’t entirely wrong.

10% Luck

I was fortunate.

I had spent years working with prospects and customers before moving into Product. I wasn’t trying to imagine where the platform struggled. I had lived those conversations. I had also spent years working with software companies building their own products, which gave me exposure to a broad range of approaches, challenges, and architectural decisions.

I had spent time studying platform transitions earlier in my career, and by the time NGP arrived, I already had a working theory about what happens to successful software platforms as they age.

Luck often looks like preparation in hindsight. Sometimes it simply means being in the right place to recognize a problem when it appears.

20% Skill

Skill matters too.

NGP required all the usual product and technical disciplines. We spent countless hours discussing architectures, frameworks, migration strategies, extensibility, and user experience. We evaluated alternatives, debated tradeoffs, and tried to make decisions that would position the platform for the next decade.

Product leadership requires understanding customers, technology, markets, and business realities. It requires making tradeoffs, communicating clearly, and navigating uncertainty while still making decisions.

The technical aspects were difficult. The product decisions were difficult. Neither turned out to be the hardest part.

15% Concentrated Power of Will

This may be the most underrated percentage in the song.

Large transformations require persistence. You don’t communicate the vision once; you communicate it hundreds of times. You answer the same questions repeatedly and revisit the same concerns repeatedly.

Many people think product leadership is about creating a vision. In practice, much of the work is helping others see it.

5% Pleasure

The song only allocates 5% to pleasure.

That may sound pessimistic until you’ve spent enough time building products.

The pleasure is real. It’s the moment when a customer understands the vision. It’s the design review where people begin to see the future taking shape. It’s the launch, the customer success story, or the deal won because of something your team built.

Those moments matter. They are part of what makes the work rewarding. They are also brief.

A launch is rarely the end of the story. More often, it marks the beginning of the next chapter. New customer requests emerge. Competitors respond. New opportunities appear. Success creates its own set of challenges.

50% Pain

This was the largest slice on my whiteboard, and it wasn’t there by accident.

What struck me over time was that many of our most difficult discussions weren’t really about technology.

We would spend an hour debating architecture and leave, realizing that the disagreement had very little to do with architecture at all. Some people worried about risk. Others worried about disrupting existing customers or abandoning years of investment. Still others were excited by the possibilities of what a modern platform could enable.

The conversation sounded technical, but the underlying concerns were often organizational, financial, or emotional.

The same questions kept resurfacing in different forms. How much should we preserve? How much should we change? How much risk were we willing to accept?

Every answer seemed to create a new question.

Over time, I came to appreciate that the hardest part of a transformation isn’t usually the technology. It’s helping an organization navigate uncertainty while continuing to run a successful business. It’s helping people let go of assumptions that have served them well for years. It’s carrying a vision that isn’t yet obvious to everyone around you.

Technology is hard. But technology is often the easy part.

Helping people align around a different future is harder.

The Marathon

Having run two Marine Corps Marathons, I’ve come to believe that product transformations have more in common with endurance sports than most people realize.

Everyone is enthusiastic at the starting line. The challenge is sustaining momentum mile after mile when the finish line is no longer visible.

Product transformations are much the same. The excitement comes early. The difficult part comes later — when progress is slower than expected, debates continue longer than expected, priorities shift, and the destination remains frustratingly far away.

After roughly a year and a half working on NGP, I was ready for a change.

I still believed in the vision and the direction we were pursuing, but transformation efforts are demanding. They require persistence, patience, and an enormous amount of organizational energy.

When the opportunity to join Zoomdata emerged, it felt like a chance to continue pursuing many of the same ideas from a different starting point.

The Finish Line

Over the years, I’ve occasionally received unexpected messages from former colleagues. Someone mentions a roadmap document I wrote years earlier. Someone references a strategy presentation. Someone tells me they’re reading a Jira ticket I wrote five or ten years ago.

The first time it happened, I was surprised. Eventually, I started to realize that product leadership often leaves artifacts behind. Sometimes they’re roadmaps, architecture decisions, or strategy documents. Sometimes they’re teams, processes, or ways of thinking that outlast the people who introduced them.

Some of the most meaningful work I’ve done continued long after I left. NGP was one example.

More recently, I saw similar patterns emerge during the early stages of PerformYard’s AI journey. Different technology. Different market. Many of the same questions: Why are we changing? What does the future look like? How do we get there?

I won’t be there for every mile of that journey either.

That’s okay.

I’ve come to believe that the measure of impact isn’t whether you’re present at the finish line. Sometimes it’s whether you helped an organization start running in the right direction.

I think that’s what the pie chart on my whiteboard was trying to tell me all those years ago. The hardest part of product leadership was never the technology. It was helping people navigate change.

And if the pie chart got anything right, it was the size of that slice.