Product Opportunity Discovery: The First Problem Wasn’t the Real Opportunity

Some details have been intentionally generalized to respect confidentiality. The thinking and process are my own.

The problem I noticed

It started while I was shadowing general managers at one of our locations.

I noticed how much manual work went into processing invoices. Information had to move through different places, sometimes more than once, and people spent a lot of time making sure everything matched. One task here or there didn’t seem like a big deal. But this was a huge organization, with thousands of locations.

So I did the math.

I looked at the scale of the organization, how much time this kind of work could take depending on the size of a location, how often it happened, and a few other factors. I used ChatGPT to help me work through the numbers and assumptions, then sanity-checked my reasoning with people who understood the problem better than I did.

I can't share the internal numbers, but even directionally, the scale was hard to ignore.

That’s when I started wondering: why are we asking people to do so much of this manually in the first place?

What if the system could do most of it for them?

Instead of spending too much time thinking about what that might look like, I built a rough concept in Vercel V0. It wasn’t meant to be a solution. I wanted to make the idea tangible enough to see whether it made sense and give people something concrete to react to.

My first idea was simply to give that time back. Let technology handle more of the repetitive work and let the people running these locations focus on actually running them. At the time, I thought that was the opportunity.

It wasn’t.

Following the problem changed the problem

I started talking to people who understood the systems around the problem far better than I did.

That’s when I learned something important: other teams were already solving parts of it.

My first reaction could have been, well, I guess they’re already solving it. Instead, I wanted to understand why the problem I had seen still existed. A few conversations later, I had a much better picture. What looked like one problem from the frontline was actually connected to a much larger system, with different teams holding different pieces of it. That left me with a more interesting question: what were we still missing?

I had been focused on the time people spent processing invoices. But as I learned more, I started seeing the invoice as more than something people had to process.

The information itself might be more valuable than the time we could save processing it.

That changed the direction of my thinking.

I started bringing that idea to people in different parts of the organization, not to sell it, but to challenge it. What was I missing? Was the information valuable elsewhere? What other problems were connected to it? Each conversation expanded the picture. Suddenly, saving people time wasn't the most interesting part anymore.

The problem had changed.

I had started by asking how technology could remove repetitive work. Now I was asking what else becomes possible when you follow the information behind that work. I can't share where that thinking ultimately led, but it became a much larger opportunity than the one I had started with.

Making the opportunity hard to ignore

As my understanding of the problem grew, that early V0 concept was still useful. The thinking around it had changed, but it gave me something concrete to bring into conversations. That was exactly what I needed. Not a polished prototype, but something people could understand and react to quickly.

The concept was intentionally rough. Its job was to start a conversation: Could this work? What was I missing? Who else should I talk to? But the prototype was only part of it. I also boiled everything I had learned down to three simple slides: the problem, the opportunity, and a potential direction.

That forced me to get extremely clear.

If I couldn’t explain each one simply, I probably didn’t understand it well enough yet. I kept writing and rewriting until someone with none of my context could grasp the idea quickly. Those three slides became something I could use almost anywhere: send them to a leader, pull them up in a quick conversation, or use them to guide a more formal discussion. The clearest signal was what happened next: people kept engaging, asking questions, connecting me with others, and helping the idea move further through the organization.

That’s why I like making things early.

A rough prototype isn’t there to prove I’m right. It gives people something concrete to challenge, correct, or build on. The more complex the work became behind the scenes, the simpler I wanted the story to become. The goal wasn’t to make the presentation impressive. It was to make the full weight of the opportunity clear: the scale of the problem, the broader value behind it, and why it was worth acting on.

That’s what made it hard to ignore.

Building momentum without building a committee

In a company this large, finding a good idea was only part of the challenge. The other part was figuring out how to move it through such a massive organization.

I tried to keep that simple: Who is the one person I need to talk to next? In fact, that’s how the whole thing started. I simply asked a senior leader: Who should I speak to if I want to understand this better? That one question led me to the first key director, and each conversation pointed me toward the next leader.

Over time, those conversations took me across very different parts of the organization. I didn’t need to understand the entire company. I needed to understand enough to know where to go next.

Gradually, I started seeing real momentum around the opportunity. Leaders were engaging with the idea, connecting me with other people who could strengthen or challenge it, and helping move the conversation further through the organization.

I was also careful with people’s time and trust.

Instead of pulling everyone into large meetings, I kept conversations short and brought something useful each time: a clearer problem, a rough concept, something I had learned, or a question I couldn’t answer myself. As people got busier, I relied more on quick updates they could read when they had time. If an update sparked interest, I knew there was a reason to continue the conversation. Before trying to take the opportunity further, I also worked through its potential value. A good idea still has to compete with everything else an organization could be doing.

Little by little, what had started as a frontline problem became a much broader conversation. And importantly, I was no longer the only one pushing it forward.

I wasn't trying to get everyone involved. I was trying to involve the right person at the right moment, learn what I needed, and create enough momentum that the opportunity could keep moving beyond me.

Product opportunity discovery: the bigger lesson

By then, the opportunity had become much bigger than the problem I had started with.

I can't share exactly where the work ultimately led. And I didn't get to see the idea through to implementation. My time with the company ended while I was still building support for it, so I can't claim an outcome. But I can share what the process taught me.

Finding a good AI use case is rarely the hardest part of product opportunity discovery.

In a large organization, the pieces you need often already exist. They’re just spread across different teams, systems, priorities, and people. The work is finding those pieces, understanding enough of the system to connect them, and knowing who you need to talk to next.

You don't need to understand everything. You need to understand enough to find the right next move. Make something tangible. Ask a simple question. Find the next person. Learn. Adjust. And as the complexity grows behind the scenes, make the opportunity simpler and clearer for everyone else.

That became a principle for how I work: Understand the system. Find the right next move. Make the opportunity hard to ignore.