Building Clarity

A few weeks after we launched a new capability, I was walking through our annual customer conference when someone stopped me to thank me for it. A little later, someone else did the same thing. By the end of the conference, several customers I had never met had gone out of their way to shake my hand and tell me how much they appreciated what we had built.

Those moments never get old. We spend months talking to customers, debating priorities, making tradeoffs, refining designs, and working with Engineering to bring ideas to life. Hearing directly from someone whose job has genuinely become easier because of that work is one of the most rewarding parts of Product Management.

What stayed with me after the conference wasn’t that customers loved the feature. It was that none of them had ever asked us to build it.

That might sound like an odd statement coming from a Product Manager because we’re constantly told to listen to our customers. I couldn’t agree more. In fact, I think we should spend far more time listening than talking. Customers are incredibly good at describing where they’re struggling, what frustrates them, and where they feel they’re wasting time. What I’ve learned, however, is that there’s an important difference between listening to the problem and simply implementing the solution being requested.

Over the years, I’ve found that customers are experts in their business. They know their workflows better than I ever will. They know what feels difficult and what keeps them from accomplishing their goals. What they shouldn’t have to do is design the software that solves those problems. That’s our responsibility.

The more I reflected on those conversations at the conference, the more they reinforced something I’ve come to believe over the course of my career. The most valuable thing a Product Manager builds isn’t the product itself. It’s the clarity that allows everyone else to build the right product.

That’s probably not the answer most people expect.

When people think about Product Management, they usually picture roadmaps, backlogs, user stories, requirements, prioritization meetings, and release planning. Those are all important parts of the role, and every Product Manager should be good at them. They’re also the most visible parts of the job, which is why they’re often mistaken for the job itself.

What I’ve found is that the work creating the greatest value usually happens before any of those things exist.

It begins by creating clarity around the customer problem. Once that happens, conversations change. Decisions become easier. Tradeoffs become clearer because everyone is evaluating ideas against the same understanding instead of bringing their own assumptions into the room.

Eventually, those conversations at the customer conference led me back to the feature itself.

The capability they were thanking me for was Conversational Reporting.

Interestingly, nobody had been asking us for conversational reporting. They’d been asking for easier reporting, which at first glance, sounds like the same request, but it really isn't.

If we had approached the problem in the traditional way, we probably would have invested another release improving the reporting engine. We could have added more filters, redesigned the interface, improved performance, or introduced additional visualizations. Every one of those ideas would have made reporting incrementally better.

None of them would have solved the problem customers were actually describing.

The reporting engine already did its job remarkably well. The challenge was that many customers found it intimidating. They knew the answers they needed were somewhere in the system, but getting to those answers required learning a tool they didn’t enjoy using. Meanwhile, another group of customers loved reporting because they had invested the time to master it.

That distinction changed everything.

Once we became clear about the real problem, the discussion shifted from “How do we make reporting better?” to “How do we help every customer get answers from their data?” Those are fundamentally different questions, and they naturally lead to different solutions. AI gave us an opportunity to remove much of the complexity that customers had been wrestling with for years. Instead of asking them to learn the reporting engine, we allowed them to ask questions in plain English and let the software do the heavy lifting.

Customers weren’t thanking us because we had built an AI feature.

They were thanking us because we had removed a source of frustration that many of them had simply accepted as part of using the software.

That experience reminded me that clarity has a ripple effect far beyond the product itself.

Engineering needs clarity about the problem they’re solving, not just the requirements they’re implementing. Design needs clarity about the experience they’re trying to create. Marketing needs clarity about the story they’re telling. Sales needs clarity about the value they’re communicating. Leadership needs clarity about why a particular investment matters. Without that shared understanding, it’s entirely possible for very talented people to produce software that checks every box on the requirements document while missing the customer’s real need.

I’ve seen the opposite happen as well, and it’s one of my favorite parts of this profession.

Every once in a while, a team reaches the point where everyone suddenly sees the problem the same way. Meetings become shorter because fewer words are needed. Prioritization becomes easier because everyone is evaluating ideas against the same objective. Healthy debate still happens, but it becomes far more productive because people are no longer arguing from different assumptions about what success looks like.

That’s what clarity creates.

I’ve been thinking about this a lot recently because AI has dramatically changed how quickly we can build software. Today I can prototype ideas in hours that would have taken weeks not very long ago. That’s an incredible change, and it’s one I embrace wholeheartedly because it allows us to learn faster than ever before.

What AI hasn’t changed is the importance of deciding what deserves to be built.

If anything, that responsibility has become even more important. When building software becomes easier, the cost of building the wrong thing doesn’t disappear. We simply get to the wrong answer much faster. Speed amplifies good product judgment, but it also amplifies poor product judgment.

That’s why I don’t believe the growing conversation about AI diminishes the importance of Product Management. Quite the opposite. The organizations that succeed won’t necessarily be the ones that build software the fastest. They’ll be the ones that develop the clearest understanding of their customers, align their organizations around the right problems, and consistently make good decisions about what deserves to be built.

The tools we use will continue to evolve. They always have. But the responsibility at the heart of Product Management hasn’t.

Great Product Managers don’t create certainty. They create clarity.

Wishing you all the best

Mike