Product management isn’t about building more. It’s about solving what matters.

Why product starts with listening

Conversation with Jonathan Coll

Principal Product Manager 

A conversation with Jonathan changed how I think about product. Jonathan is a Product Manager at Avalo, helping shape the Ionfi by Avalo platform. From the outside, product can look like deciding what to build and handing engineering a list of requirements. From the inside, it's something quieter and harder: making sure that what we build is actually solving the right problem, for the right reason. 

When I asked him to describe the job in plain English, his answer surprised me. 

"I'd say it's 75% listening and 25% building," he told me. "My role is to give design and engineering enough context to solve the problem themselves." 

That context comes from everywhere: clients, customer support, operations, compliance, and technology. Each sees a different part of the picture. Product's job isn't to decide whose request wins. It's to find the patterns, understand the business impact, and make sure the whole team is solving the same problem for the same reason. 

"My job is not to build you a feature," Jonathan said. "My job is to solve your problem." 

Sometimes that means asking one more question. A client might say, just put that widget right there. Instead of immediately saying yes, Jonathan asks why. 

"When a client comes to me with a feature idea, I try to get a little deeper into what they're actually trying to solve," he explained. "Sometimes what they're asking us to build isn't the best solution, or there's an easier way to solve the problem." 

Underneath the request is usually a larger objective: a smoother workflow, greater adoption, or a better client experience. Understanding that objective is what allows the team to build something useful, rather than simply adding another feature. 

One story stayed with me. Clients were creating wires, attaching supporting documents to a profile, and then submitting the transaction for approval. From the client's perspective, the documents were already in the platform. But the relevant files could be among dozens of documents on the profile, creating an avoidable follow-up request for something the client believed it had already provided. 

Jonathan heard versions of the same issue from several clients.  

"This came up about five times when I interviewed different clients," he said. 

Instead of treating each instance as a one-off request, the team identified the underlying gap. That insight became the basis for a feature that allows clients to attach the relevant profile documents directly to a wire. The context can travel with the transaction, helping reduce back-and-forth and supporting a faster review. 

"Most big projects are really about connecting the dots," Jonathan explained. "You look at the recurring things that keep coming up. That's what helps us decide what to prioritize." 

Two things stayed with me from our conversation. 

First, product is where different perspectives come together. Customer support hears the client's voice firsthand. Compliance and operations understand what is needed to move a transaction forward. Engineering knows what can be built and how to build it at scale. Design makes the experience intuitive. Jonathan helps those teams share a common language and align around the same outcome. 

"Compliance and engineering don't always speak the same language," he explained.  

Part of his job is making sure the requirement, the reason behind it, and the intended outcome are understood by everyone. 

Second, progress doesn't have to mean disruption. As we continue enhancing the platform, Jonathan is focused on protecting the workflows clients already rely on while making the value of each change clear. 

"If we just migrate people and don't explain the benefits, they'll ask, why am I even changing?" he said. "We have to show them: this is what you told us was difficult, and this is how we solved it for you." 

Help clients recognize their own feedback in the product, I said. He agreed—that's exactly it. 

Good product leadership, in his telling, isn't about shipping the most features or chasing the newest idea. It's about asking better questions, listening across boundaries, and helping the team focus its time and energy on what matters most. 

Jonathan described product as a "jack of all trades" role. That breadth may be its hidden strength. His job isn't to replace the specialists in each function. It's to understand enough of every perspective to connect them, earn trust over time, and keep everyone moving in the same direction. 

Good products are rarely the result of a single breakthrough. More often, they grow from dozens of small moments when someone listens closely, spots a pattern, and turns a recurring frustration into a better way to work. 

Jonathan helps make that happen—thoughtfully, collaboratively, one problem at a time.