Last week, I had the opportunity to speak with Steve Joos, a seasoned product leader currently serving at Vanco, a company specializing in payment solutions for churches, schools, and nonprofit organizations. Steve's experience in managing complex product ecosystems, particularly in companies built through acquisitions, offers valuable insights for product leaders facing similar challenges. Here's what we discussed:
Can you tell us about your background and your current role at Vanco?
"I spent about 14 years at an educational content firm, Cengage, where I had the opportunity to witness two significant transitions. First, watching a really analog, traditional business turn digital, and second, moving from a more editorial, authoritative approach to a complete product mentality.
After that, I moved to a startup in healthcare, where we rebuilt our care management solution to coordinate care across insurance companies, pharmacies, and other use cases. Then I went back to ed tech with Prometric, and now I'm at Vanco. At Vanco, we do payments for churches, schools, community organizations, and nonprofits - processing their digital payments and things like that.
What's interesting about both Prometric and Vanco is that they're companies built largely by acquisition. This presents unique challenges in product management, especially when you have multiple products with overlapping capability but that behave very differently and aren't well integrated."
You've mentioned working with companies built by acquisition. What unique challenges does this present from a product management perspective?
"When you work with companies built by acquisition, you almost have to step back and ask, 'What does this company want to be when it grows up, now that it's acquired these other organizations?' Is there a steel thread that holds them together? And then, how do you make decisions?
One of the big challenges is demystifying where the investment is going. From a finance perspective, your CFO might say, 'This is our revenue in market A and this is the revenue in market B.' But that doesn't necessarily map to the investment in homegrown and acquired applications that support that revenue.
You have to make judgment calls on where to draw the boundaries between these different apps because they start to interact with each other, and people get shifted around. The goal is to come up with a P&L and set of financials that makes sense to determine whether you're investing in the right spots, and then marry that up with all the product management data."
How do you balance the need for innovation with financial accountability in this type of environment?
"What we've ended up doing is coming up with a series of touch points. We say, 'Here's the P&L for this product. To maintain the product and run the current footprint of the business, we need X dollars.' That's just what we need as long as that product is something we're going to sell.
Then we say, 'Here are the ideas we have for additional investment.' We estimate costs in orders of magnitude - is it big, is it small? We then cross-reference this to turn it into money, which makes things clearer.
It's funny math, right? We might say a 'medium' project is three developers for four sprints, which varies by developer salary range, supporting roles, and other overhead. We also know software projects have varying levels of uncertainty. But if I run that “funny math” five times on a team, it usually ends up coming out pretty close for what they can deliver during a PI or year.
This approach gives us the freedom to dig into problems because they've been funded, and 'no' becomes a complete answer. There might be ten things we want to do, but we're going to do these three. It drives focus, which allows people to still be creative inside those focus areas without getting distracted."
How do you decide what to innovate on? What data do you look at to make these decisions?
"Ideally, we'd start by looking at what people are doing in our product now and what insights we can get from that. But I find that this gives you a good idea of how to fix the experience, not necessarily open up new ideas.
So I usually like to start by connecting with the go-to-market team and getting some selected clients - not necessarily the biggest clients, but the most representative ones. We try to have a more qualitative outreach that's not explicitly about the product. For instance, if I'm talking to a school administrator, I don't want to ask them about setting up fees in our system. Instead, I'd ask about their biggest challenges generally.
This approach can uncover interesting opportunities, especially in a company with multiple acquired products. Sometimes there's functionality in one product that can be moved to address needs in another area.
From there, we'd start testing and tuning those assumptions with surveys, product feedback data, and more explicit inquiries. In companies with a lot of application sprawl, getting to a ‘shift left’ discipline can be difficult in the face of technical debt."
Who do you find yourself interacting with the most to drive innovation and solve customer problems?
"It's easy to spend all your time with the development team if you're not careful. But I try to balance it. I push my team to do client outreach, to get curious about customer needs.
I spend a lot of time, especially early on, getting the go-to-market team’s perspectives. Go-to-market teams often don't feel heard, and they tend to have a pent-up set of ideas about what we should consider that can bring some short term wins.
I also spend significant time with my technical partners, figuring out why we haven't done certain things and if we made the right decisions. It's about finding the balance between delivering predictably and understanding the inherent ambiguity in software development.
Once we start delivering new features or products, I spend a lot of time with the go-to-market team, refining the list of priorities, making sure everyone's on the same page, and then tracking the results. Where are the opportunities? Where's the pipeline? Do they need product information? It's about walking it all the way through, from idea to delivery to market impact."
So what did we learn?
Steve's insights highlight several key principles for managing product innovation in complex, multi-product environments:
1. Understand the bigger picture: In companies built through acquisitions, it's crucial to step back and understand what the company wants to be as a whole.
2. Create financial clarity: Develop a system that translates product development efforts into financial terms that executives can understand and support.
3. Balance structure and creativity: Implement lightweight governance that provides focus without stifling innovation.
4. Look beyond the product: When seeking innovation opportunities, don't just ask about the product - ask about customers' broader challenges.
5. Foster cross-functional collaboration: Ensure go-to-market teams are heard, work closely with technical partners, and follow through on market impact.
6. Embrace uncertainty: Recognize that software development inherently involves uncertainty, and build that into your planning and communication.
7. Focus on delivery and results: It's not just about building features, but about ensuring they deliver real business value.
By applying these principles, product leaders can navigate the complexities of managing multiple product lines while driving meaningful innovation. As Steve put it, "It's about finding the balance between delivering predictably and understanding the inherent ambiguity in software development." It's about creating a framework that allows for both structure and creativity, ensuring that product development efforts align with business goals while still leaving room for innovative thinking.
