Leader Spotlight: Applying a finance background to product management, with Caleb Eplett
Caleb Eplett is Chief Product Officer at YCharts, an investment research and proposal generation software. He began his career as a financial advisor at Ameriprise Financial Services, LLC, before becoming a fixed income trader at Chopper Trading, LLC. Caleb joined YCharts as an account manager and has worked his way up over the past 12 years to his current role as Chief Product Officer.
In our conversation, Caleb talks about how his background in finance has taught him lessons in product management, including being patient and maintaining quality client relationships. He shares the challenges of adhering to regulations while still iterating quickly, and how having quality control processes in place enables them to remain agile. Caleb also discusses the importance of the information that you gather and the workflows that you're going through to serve your clients.
Learning patience and ‘carrying the bag’
You have a background in finance, which aligns well with your position at YCharts, but may be unconventional in product management. What pushed you in the direction of product?
I entered the workplace in 2008, which was a weird time to be starting my career, especially coming out of school having studied economics and finance. I gravitated toward different things, but I've always been passionate about problem-solving. Especially when it comes to big challenges or things that people say can’t be done — I love looking at those problems and thinking about them. That's what ultimately led me toward product management.
Overall, I love the constant challenges and opportunities to make things better, and though I channeled that in a lot of the opportunities I pursued outside of product management, I found a really good fit here.
Do you feel that there are parts of your past experience that inform the way that you do product leadership now?
Yes. We're all products of our experiences, so I 100 percent agree that my past dictates how I do things currently. It's not always the easiest transition, so one thing I had to learn was patience. I come from sales and trading, which are very fast-paced. You make mistakes today and fix them tomorrow, whereas in product management, there’s a focus on big-picture work and putting pieces together. That's been something that I've had to adapt to.
As far as my past experience and how it relates to my role at YCharts, it's helpful that I've “carried the bag”. A lot of people in product management end up there because they know the problems that their customers are trying to solve, and it's hard to be successful if you can't relate to that. Working in financial services, you have to be skilled. You have to have financial knowledge. You also have to be able to sell, have technical conversations, and manage relationships.
Having worked in all of those different areas, it's helpful when I bring perspective to how we build products for those personas — making sure that it's not something that's just going to solve a problem, but will be relatable to the end investor and efficient for somebody with a multifaceted, multifunction job, like a lot of our clients have.
Staying close to the customer and navigating regulations
Are there any specific frameworks or approaches that you use to keep the customer-facing teams engaged with the road mapping or product discovery side of things?
Yes and no. Frameworks aside, the first thing to establish is whether or not this item is important. Early in my career, I got a piece of advice that has stuck with me: stay close to the customer, and you'll always be valuable to the business. That’s proven true—understanding your customers and what drives their behavior shapes everything you do and gives you deeper insight into your business.
At YCharts, that principle is at the core of our product management philosophy. We start by getting alignment across the company that staying close to the customer is critical. From there, we tie team goals to client interaction metrics and require stakeholder notes—internal or external—on product tickets. This ensures we’re building with a clear understanding of what problems we’re solving.
To gather this insight, we of course speak directly with clients and prospects when we can. But we’ve found it’s often more efficient to tap into our client-facing teams—sales, support, and customer success—since they’re on the front lines every day. We hold regular meetings with them, supported by structured agendas and a process for submitting discussion topics in advance. These touchpoints keep the feedback loop active and embedded in our workflow, which has been incredibly valuable as our team has grown.
At YCharts, you’re not building a traditional fintech product like a banking app, but you still face the same challenge of compliance and data accuracy. Can you talk a little about just how you approach the unique challenges there?
A lot of people associate product development with the “move fast and break things” mentality. But that approach doesn’t work in every industry, especially finance, healthcare or banking. In these spaces, where trust, accuracy, and compliance are critical, you have to innovate differently.
At YCharts, we do move quickly, but never at the expense of data integrity or compliance. It's not unusual for us to spend more time developing tests when we develop a new product than it takes to actually build the product or the code. Those backend items are crucial.
We also take a segmented approach to our markets. Some of our customer verticals have stricter compliance requirements, which naturally slows the rollout of new features. Others are more flexible or self-service when it comes to regulation, which gives us more room to experiment and gather feedback quickly. By tailoring our rollout strategies this way, we’re able to stay innovative while still meeting the high standards of our industry.
Is there a tension between trying to iterate on something like that and having to still exist within the regulatory constraints?
To an extent. Internally, our team understands our operating rhythm, so there is no expectation to turn things around in 24 hours. That's just not realistic. We release new software updates weekly, with the ability to push hot fixes as needed, all without downtime.
What helps is the shared understanding that even if something seems like a simple fix, it still has to pass through quality control and testing. That can take days or weeks. Still, we’re able to respond quickly when issues arise. Building that internal culture of patience and process has been critical, and it extends all the way to how we communicate with clients.
Can you talk through a specific product launch and how your experience in sales and finance informed the decisions that you made?
Definitely. YCharts originally started as an investment research and analytics platform primarily used for evaluating stocks, ETFs, and mutual funds. It was largely a back-office tool focused on due diligence. But as we deepened relationships with our users, it became clear there was a bigger opportunity: helping advisors bring that research into client-facing conversations.
My experience in sales and finance helped me understand how important the information that you gather and the workflows that you're going through to serve your clients are. It’s crucial to communicate this information to your clients and prospects so they understand the value that you're offering. They don't see what's happening behind the scenes, so it’s your job to communicate that.
That insight directly informed the launch of our proposal and portfolio reporting tools. We built features that allowed users to create custom portfolios, run performance comparisons, and generate white-labeled reports that could be used in meetings with clients and prospects. These tools turned complex data into compelling stories, bridging the gap between the work being done and the value being perceived.
Do you ever take on requests for personalizing products, especially for larger clients?
We draw a clear line between customization and configuration. Our focus is on making the platform highly configurable, especially when it's client-facing. Advisors and asset managers are using YCharts to communicate with their own clients and investors, and those end users often need different views of the same data to make informed decisions.
Even though many firms are telling similar stories, they need to do it in their own way. Our goal is to give them the flexibility to shape that narrative, to configure reports and visuals so they align with their brand and message.
One way we support this is through templated frameworks. These templates are built on the same underlying product and codebase, but they can be edited, saved, and shared in entirely different formats. What you see from one firm can look completely different from another, even though it’s powered by the same engine. That’s how we scale personalization without reinventing the wheel for each client.
The right way to use a product
Does that make it more challenging to identify when there is something going wrong, especially when there are so many layers involved in the product?
At times, yes. A common report is, “The charts aren’t working.” But it’s rarely the charts themselves; it’s usually a specific data point or series out of the hundreds of thousands we support that’s causing the issue.
Troubleshooting typically starts with the user interface and understanding exactly what the client is looking at. We’ll use session data, shared links, or screenshots to dig into the issue. In most cases, the root cause ties back to the data and not the core product functionality.
That’s why most of our support team’s work involves data investigation. Often, that means coordinating with third-party data providers to identify inconsistencies and correct them. It’s a layered process, but one we take seriously because the integrity of the data is what powers the entire client experience.
Do you find that, especially with complex financial technology, users of a product can use it incorrectly, or does the product become what the users do with it, and the PM has to adjust the product strategy to meet user behavior?
What’s unique about YCharts — especially in the financial services industry — is that you won't find recommendations on our platform. We won't tell you whether something is a good investment or not, or if one investment is better than another. Instead, we give you all the tools and data to make those decisions based on how you think about investing or the theories you follow. In that sense, there’s no “wrong” way to use the platform. If your approach to research or portfolio construction is grounded in a specific methodology, YCharts is built to support that, not override it.
That said, there’s often a more efficient way to achieve your goal. This is where our customer success team steps in. For example, if you're screening for securities that match a unique set of criteria, there might be ten different ways to do it. We’ll help you find the fastest path and set up saved views or workflows to make it repeatable.
There are best practices, especially around efficiency and scale, but because outcomes vary so much by user, we prioritize flexibility. The product doesn’t dictate behavior; it adapts to it.
The importance of potential
For product managers who don't have a specific finance background, is it more difficult to explain the theory behind the product rather than focusing on the user experience and the data?
It depends on the team, and that’s the point. We intentionally build teams with diverse strengths. Some people bring deep financial knowledge, others bring UX horsepower. All of their perspectives are critical to building a product like YCharts..
If someone doesn’t have a finance background, can they still be effective? Yes, if they have high potential. Finance is hard to teach, but not impossible. We’ll take potential over experience every time. People with strong aptitude and curiosity tend to pick up complex concepts quickly, and they’re usually the ones who thrive when things get ambiguous or challenging.
A PM doesn’t have to know everything, but they do need to know when to pull in a domain expert, ask good questions, and translate complex theory into practical product decisions. That’s what moves the needle.
You mentioned potential. What advice would you give to someone who comes from a non-traditional or non-technical background and is looking to transition to product management?
The best advice I ever got, and still give, is to spend time with customers. Watch what they do, listen closely, and figure out what would make their lives easier. If you understand the problems worth solving, you’re already on your way.
Everyone seems to think that product managers and product departments have to have all the ideas and all the answers. That’s not true at all. Our job is to filter through other ideas that are submitted, find the best ones, and go out and test them in the market and see if they work well. From there, we build products or solutions around those ideas.
None of that requires a specific technical background. What it does require is curiosity, strong instincts for problem-solving, and the willingness to ask smart questions. If you’ve got that, you can succeed in product, regardless of where you started.