This is an interview with Brian Root, Fractional Chief Product Officer, Rooted In Product
As an expert in Product Management, could you introduce yourself and share a bit about your current role and responsibilities?
I’m Brian Root, founder of Rooted In Product. I work as a fractional Chief Product Officer, usually brought in when there’s a persistent gap between how fast engineering teams are shipping and how little that work seems to be moving the needle. The velocity is there, but the outcomes aren’t. Product development feels disconnected from business impact.
That kind of misalignment can surface in many ways. Product strategy may be too abstract to drive real decisions. Teams might be operating without clear goals, or with too many of them. Backlogs grow but clarity shrinks. Feedback loops stall. Engineering delivers features that meet the spec but miss the point. Meanwhile, leadership senses the problem but can’t always pinpoint where things broke down.
I step into that gap. I don’t show up to observe. I embed directly in the work, shoulder-to-shoulder with the people already trying to fix it. Sometimes that means redefining the product vision so it can actually be used as a decision-making tool. Other times it means installing simple, durable systems to guide prioritization, reduce churn, or improve how product and engineering partner together. Often, it involves coaching product managers to strengthen their judgment and helping founders understand how to scale product leadership without losing grip on the original intent.
My background spans enterprise and startup environments. At Amazon and Walmart Labs, I worked inside highly structured systems with large-scale complexity. At smaller companies, I built product teams where nothing existed yet. Across those contexts, the core problem has been the same: product teams need help turning potential into leverage. Not through heroic efforts, but through repeatable mechanisms that create progress without burning people out.
The work I do is practical and designed to outlast my involvement. I don’t sell a framework or a methodology. I build real alignment between effort and results, so companies stop relying on momentum and start moving with precision. That’s the value of strong product leadership. Not more process or more planning, but the discipline to make product work count.
What was your journey into Product Management like? Can you share a pivotal moment or decision that significantly shaped your career path?
I’ve always been interested in how systems work, why people make the choices they do, and how those decisions ripple outward. That’s what drew me to study game theory in college. I didn’t know it at the time, but that way of thinking would become foundational to how I approach product management: as a discipline that connects the dots between people, incentives, and outcomes.
After graduating, I joined Amazon through a rotational leadership program. In my first placement, I was assigned to a product role mostly by chance. I didn’t even know what product management was. But within a few weeks, I knew I had landed somewhere that made sense. Product was the hub of the wheel, with strategic connections to every aspect of the company.
One of the experiences that most shaped how I think about product came during my time at Fundera in 2020. We were a marketplace for small business financing. When the pandemic hit, our lending partners stopped lending. The entire supply side of our business disappeared at the exact moment demand spiked. Our customers were desperate for funding, but we had nothing to offer.
Then the government introduced the Paycheck Protection Program. It had the potential to be a lifeline, but it came with vague rules, unclear timing, and no guidance on execution. We formed a small cross-functional team to respond. I was the product leader on that team. We understood that the companies that moved first would have a real advantage, and that waiting for clarity would put us behind. So we moved fast.
We spent a few days dissecting the initial guidance, anticipating potential edge cases, and assembling an off-the-shelf tech stack that would let us build quickly without waiting on backend infrastructure. Once the application requirements were released, we launched a fully digital, self-serve PPP application in under 72 hours. That speed to market became a differentiator. We processed over a million dollars in loan fees, bought the company time it wouldn’t have had otherwise, and ultimately helped position it for acquisition.
That experience clarified what product management is at its core. It isn’t process. It isn’t stakeholder management. It’s the ability to operate under conditions of uncertainty, to identify leverage when everything is in flux, and to ship something that matters before the window closes. Product creates momentum. When done well, it keeps companies alive.
In your experience, what’s the most challenging aspect of balancing user needs with business objectives when developing a product strategy? Can you provide an example of how you’ve successfully navigated this balance?
One of the hardest parts of balancing user needs with business objectives is that they often move on different timelines. Businesses tend to optimize for near-term revenue, usually tied to quarterly targets or campaign cycles. On the other hand, users judge a product based on whether it solves a real problem in a way that earns their trust over time. When the pressure to hit numbers grows, company incentives tilt toward shortcuts. Teams reach for aggressive conversion tactics, launch prematurely, or prioritize features that close deals rather than deepen value. You can hit your short-term goals while gutting the product and user experience.
At Assurance, I ran directly into this tension. We were selling insurance through a large inside sales team. Marketing spend was massive, and the business relied on quick conversions to stay afloat. Customers were routed into high-pressure calls immediately. The experience worked for the company’s metrics, but not for the customer. Retention was weak. Sales morale was low. Internal surveys showed that employees didn’t believe in the product they were selling.
During our peak season, I led an initiative to test a different approach. We launched an invite-only referral program with a slower, more respectful experience. Customers scheduled their own calls, received better context ahead of time, and were flagged internally for white-glove service. There was no hard sell. The goal was to reduce pressure and create a sense of the customer being in control.
We got the test live in three weeks. Our standard funnel converted at around 2 percent. The referral funnel converted at 73 percent. That result gave us the leverage to push for bigger shifts. We moved forward on initiatives that had always been deferred, such as call scheduling, stronger post-sale follow-up, and better pre-call education. All of it was fundamentally based on customer trust.
What made the difference was starting from the user and building around them, rather than bending the user experience to meet business goals. We didn’t design a smoother process to improve conversion. We designed a smoother process because customers deserved a better way to buy. The business benefited because it finally aligned with how people actually wanted to engage. That shift in perspective is subtle, but it matters. When strategy begins with the user and treats their needs as fixed constraints, you have the framework to build something that lasts.
How do you approach feature prioritization in your product roadmap? Can you walk us through a specific instance where you had to make a tough call between competing priorities?
I don’t start with features. I start with clarity on what we’re trying to achieve and why it matters. Most teams don’t struggle because they have too few ideas. They struggle because everything feels equally important, and they don’t know how to make trade-offs. That’s usually a sign of a weak strategy or goals that are too vague to guide decisions. My job is to make the trade-offs explicit and force the organization to choose.
One example that stands out was at Assurance, where we managed more than 20 lead generation funnels across multiple insurance lines. We had a massive performance marketing engine driving traffic to those funnels, with scores of A/B tests running at any given time. That system was good at optimizing for conversion, but it made deeper product improvements harder to prioritize. Everything was measured in near-term lift. The roadmap filled up with iterative experiments because they were easy to measure and quick to ship, even when the long-term upside was marginal.
We were seeing stagnation. Small wins kept us busy, but nothing was moving the needle. I pushed the team to step back. We reframed our roadmap around the biggest constraints on growth, not the easiest opportunities to test. In our case, one of those constraints was that our conversion data wasn’t trustworthy. Marketing was using one analytics tool, product was using another. Bot traffic was distorting the numbers. And every conversation about performance turned into a debate over which data set to trust.
Fixing that wasn’t flashy. It meant pausing several visible roadmap initiatives and pulling engineers off growth work to clean up tracking, validate attribution logic, and align reporting. From a pure velocity standpoint, it looked like we slowed down. But once we had clean data, we discovered that a major affiliate was misconfigured and costing the company hundreds of thousands of dollars a year. We found that our A/B testing platform was broken and delivering false positives. And we uncovered performance gaps that had been hidden under noise.
That kind of work rarely wins political points in the moment; in fact, it’s often controversial. But it’s what creates real leverage. Prioritization isn’t about what’s fastest to ship or easiest to measure. It’s about what creates the conditions for sustained impact. If you can’t defend your roadmap by pointing to that kind of leverage, you’re just rearranging deck chairs on the Titanic.
Data-driven decision making is crucial in Product Management. Can you share a situation where data insights led you to make an unexpected or counterintuitive product decision that turned out to be successful?
At Assurance, we had a persistent gap between sales and retention. Customers were buying life insurance policies, but a large share never made their first payment. On paper, we were closing deals. In reality, a significant portion of those deals never became revenue.
We already knew the product experience was high-pressure and fast-moving. What we didn’t know was what customers felt after the call. I had just hired a Director of UX Research, and one of her first initiatives was to map the full post-sale journey. The key insight she surfaced was unusual: many customers who had just purchased a policy started shopping again almost immediately, literally within 24 hours. Not because they wanted a better deal, but because they were anxious and unsure about what they had just done. The pressure of the sale, the complexity of the policy, and the lack of clear follow-up made them second-guess their decision.
This insight cut against the company’s instincts. Sales leadership believed strongly in the “one-call close.” Any post-sale contact, they argued, would only create doubt and raise the risk of cancellations. But we had data. We could quantify the drop-off. We could tie it directly to that post-sale uncertainty. So instead of trying to overhaul the sales model, we tested a smaller intervention. We had customer support agents call buyers a few days after their purchase, not to upsell, not to cross-sell, just to check in and answer questions.
The effect on the test group was dramatic. Policy effectuation increased and customer sentiment improved. The ROI on the outreach was more than 10 to 1. It helped shift the company’s mindset. We started thinking of retention not as a lagging metric, but as part of the product experience itself.
The data didn’t just help us make a better decision, it helped us change the conversation. We stopped asking whether we could afford to follow up and started asking what would happen if we didn’t.
Cross-functional collaboration is key in product development. What strategies have you found most effective in aligning diverse teams towards a common product goal? Could you provide an example of overcoming interdepartmental challenges?
One of the most persistent interdepartmental challenges I’ve seen is the way Product Design and UX Research are positioned in relation to Product Management. In many organizations, they are treated as downstream functions. Design is brought in to style something that’s already been decided. Research is used to confirm what someone already believes. This setup guarantees misalignment. It strips those teams of strategic influence, reduces the quality of decisions, and wastes time when work has to be redone after late-stage objections.
I’ve stepped into more situations than I care to count where that exact pattern had taken hold. When I enter that kind of environment, I don’t start by working at the individual level. I start by rebuilding the operating model. The first move is always to pull design and research forward in the process. That means structuring work so that discovery leads into solutioning, not the other way around. It means planning research cycles ahead of build cycles, and holding PMs accountable for bringing pointed but open questions to the table instead of pre-baked answers.
Once those expectations are reset, the shift becomes self-reinforcing. Designers stop being asked to decorate decisions and start shaping them. Researchers stop chasing stakeholder hunches and start framing the right problems. Product managers gain clarity because the ideas that reach development have already been pressure-tested.
None of this is about making collaboration feel better. It’s about producing better work, faster, with fewer resets. And it only happens when every function is allowed to lead at the point in the process where they add the most value. I’ve seen what happens when you don’t do that. And I’ve seen how quickly things improve when you do.
Looking ahead, what do you believe will be the next big challenge or opportunity for Product Managers in the coming years? How are you preparing yourself and your team to meet this future head-on?
The next big challenge for product managers won’t be related to tooling, process, or frameworks. It will be navigating through signal collapse. As AI gets better at generating content, code, and even basic product decisions, the volume of output will explode. The noise will be endless. It’ll be easy to ship, easy to measure, and dangerously easy to mistake activity for progress. The product manager’s job has always been to drive impact, not just ship with velocity, and this emphasis will only get more important.
Most teams are already overwhelmed with dashboards, research, feedback, and test results. Now layer on LLM-generated documents, AI-assisted roadmaps, and automated synthesis tools. If you don’t know what good looks like, the machine will bury you in plausible nonsense. Ideas will be a dime a dozen. The challenge will be knowing which ones are worth building and having the clarity and discipline to say no to everything else.
To prepare for that, I focus on strengthening judgment. For myself and for the teams I work with. That means less emphasis on output and more emphasis on understanding. Are we solving a problem that matters? Do we know why it matters now? Do we know what good would look like for the user and for the business? Those are human questions, and they’re what keep the work grounded.
It also means creating structures that preserve context. Shared documentation, open planning processes, research that lives alongside strategy rather than beneath it. When decisions are made in isolation, they become fragile. When teams have context, they move faster with less oversight.
AI is going to make a lot of things easier. It’s also going to make undisciplined teams look productive right up until they’re wildly wrong. The opportunity is to build teams that stay focused on the signal. That’s where I’m personally investing. Not in moving faster, but moving with more intention.
