This interview is with Brian Root, Fractional Chief Product Officer at Rooted In Product.

 

Brian Root, Fractional Chief Product Officer, Rooted In Product

Can you tell us about your current role and how your leadership journey has shaped your approach to guiding teams?

Sure. Right now, I run Rooted in Product, a boutique fractional product management practice that offers fractional CPO services targeted to help with tough product, people, and process problems. That means I step into companies that either don’t yet have senior product leadership or need outside perspective to move through complexity; anything from helping a founder structure their org to rethinking how product and engineering work together. I also work with a network of other experienced operators who I bring in when a broader lift is needed.

My leadership approach is very much shaped by the road I took to get here. I’ve spent time at every level: in the trenches as a PM, as a people manager, as a head of product, and as a cross-functional org leader during both high-growth and existential-crisis moments. I’ve spent a lot of time at Amazon, where precision and process were everything, and I’ve worked at a handful of startups where the entire roadmap was held together with duct tape and hope.

What all of that taught me is that leadership isn’t about having the answers. It’s about creating the conditions for your team to find the right answers themselves. Sometimes that means being the steady hand in ambiguity. Other times, it means stepping back so someone else can step forward. I care a lot about clarity: clear expectations, clear feedback, and a clear sense of what “good” looks like. But I also try to hold space for people to do things their own way. That balance between structure and autonomy is something I’m always refining.

What was a pivotal moment in your career that significantly influenced your leadership style?

Arguably, the most pivotal moment occurred right at the beginning of my career. Three months out of college, I was suddenly managing people. I had no real training, no framework, no muscle memory for leadership. I did what a lot of people do in that situation: I mimicked what I saw. And what I saw was control masquerading as leadership. So I micromanaged. I jumped in to “fix” work that didn’t meet my expectations. I handed out platitudes and trite motivational speeches instead of meaningful feedback. I assumed that because I had a title, that meant I had authority. I learned the hard way that none of that works.

Looking back, I wasn’t leading. I was managing through anxiety, trying to prove I belonged, trying to deliver results fast, and in the process, making it harder for my team to do their best work. What shifted wasn’t a single revelation, but a slow, often uncomfortable process of observing the gap between what I was trying to do and the outcomes I was actually getting.

At the same time, I keenly felt the impact of being on the receiving end of that same kind of management from people above me. When leaders relied on status instead of trust, when feedback felt performative, when direction came without context, it didn’t motivate me, it made me disengage. So I began questioning: what kind of leader would I actually want to work for?

Over time, I understood that authority conveyed on an org chart means very little if you haven’t earned it through your actions. The people who worked for me didn’t need someone to control them, they needed clarity, support, and someone who could clear the road so they could move forward.

After nearly two decades, that’s how I try to lead now. I’m people-first, but not passive. I care deeply about how my team experiences their work, how they grow, how they’re challenged, how they’re recognized. At the same time, I won’t hesitate to be direct when something isn’t working. I’ve just learned that being firm doesn’t mean being harsh. It means being honest, and giving people the tools and context they need to do great work.

I don’t rely on command and control. I lead by clarifying what matters and removing the blockers that get in the way. And I try to remember, always, that the way you treat people is the work. The impact lasts far beyond any single project.

You’ve mentioned the importance of empathy in leadership. Can you share a specific instance where practicing empathy led to a positive outcome for your team?

One example that sticks with me goes back to my time at Amazon. A director I worked for had moved someone into a new role via internal transfer. It was a decision that, frankly, was based on surface-level signals and didn’t take into account what the role actually required. It was a highly analytical position that demanded a strong quantitative skill set, but this person’s strengths were much more relational and people-oriented. It wasn’t a good fit, and it became pretty clear that they were struggling.

A few months later, for unrelated reasons, my scope expanded and I inherited both this individual and their role. Almost immediately, the same director who’d made the transfer decision started pressuring me to put them on a performance improvement plan. The subtext was obvious: they wanted this person out.

But when I started digging, I realized no one had ever actually given this person clear, actionable feedback. They knew they weren’t hitting the mark, but they’d been flying blind with no direction and no clear expectations, just mounting pressure. That didn’t sit right with me.

At the same time, I had a new position opening up on my team. It was considered smaller and lower visibility, but I could see it playing to this person’s natural strengths in stakeholder management and communication. So I sat them down and had an honest conversation. I gave them the feedback they hadn’t received. I told them plainly: if things continue on this path, we’ll be having a formal performance discussion soon. But I also gave them a choice. They could stay in the current role and work toward a clear improvement plan, or they could move into this new role, one that I believed was a better fit, and get a fresh start.

They chose the new role. And they told me afterward that what made the difference was the trust we built in that conversation. I had been direct with them, but also fair. I didn’t sugarcoat the situation, but I also didn’t throw them under the bus. I offered context, a path forward, and my commitment to back them either way.

They ended up thriving. What started as a situation that looked like a slow march toward termination for this individual became the start of a multi-year, high-impact run at Amazon.

Empathy in leadership isn’t about protecting people from hard truths. It’s about being willing to tell those truths in a way that respects their agency, acknowledges their potential, and gives them a real chance to succeed.

How do you balance fostering autonomy within your team while ensuring alignment with organizational goals?

I see autonomy and alignment not as competing forces, but as two sides of the same coin. The key is clarity. People do their best work when they understand what matters, why it matters, and where the boundaries are, and then have the freedom to find their own path within that frame.

Early in my career, I leaned a little too hard on control. I thought alignment came from constant oversight. But what I’ve learned is that micromanagement kills both creativity and accountability. When people don’t feel trusted, they default to risk-aversion. You end up with teams that wait for permission instead of pushing forward. It sucks all the critical thinking out of all but the highest levels of the company.

Now, my approach is to set a strong foundation up front. That means being extremely clear about the goals we’re aiming for, the constraints we’re operating within, and the context behind the decisions being made. I don’t just say what needs to be done, I try to explain why, so the team has the necessary information and judgment to make good decisions when I’m not in the room.

From there, I stay close enough to offer guidance and course-correct when needed, but far enough away that people have the space to take ownership. Autonomy without direction creates chaos. Direction without autonomy creates disengagement. The balance comes from trust, and trust is built by consistently showing up, listening well, and following through.

When alignment is treated as a shared understanding rather than a top-down mandate, you get teams that aren’t just moving fast, but moving together. That’s the goal.

Can you describe a challenging situation where you had to lead a team member who had more expertise in a particular area than you did? How did you approach this?

Absolutely, and honestly, this comes up more often than people like to admit. As a product leader, you’re regularly working with people who are deeper in their craft than you are, whether it’s engineering, design, data science, or any other domain. That’s not a threat. In fact, it’s kind of the point. I often tell people, “My job is not to be able to do your job, just to know how to do it well enough to set you up for success.” The complexity of my job is getting to that level of understanding for almost every role in the company.

One example that comes to mind was working with a senior engineer who had been in the industry for over a decade and had deep architectural experience in a system I was just getting up to speed on. I was accountable for the product decisions and the overall direction, but there were technical implications to every choice we made, and I wasn’t going to pretend to be the expert.

The first thing I did was acknowledge that openly. I wasn’t going to play the game of trying to keep up for the sake of optics. Instead, I focused on being clear about what I did own: the problem we were solving, the user need behind it, the constraints we had to work within, and the outcomes we were driving toward. From there, I invited him in, not just as an implementer, but as a thought partner.

I asked a lot of questions. Not to challenge, but to understand. I listened. I made space for him to explain trade-offs and walk me through options. And when we disagreed, I tried to separate the “what” from the “how.” My job isn’t to dictate solutions. It was to make sure we are solving the right problem in a way that aligns with the business and the user.

That dynamic ended up working really well, not because I tried to match him on technical depth or assert some authority, but because I created a structure where his expertise could shine without the burden of having to compete with me or guess at broader priorities. And he came to value the clarity I brought to the table, which helped us move faster and with more conviction.

Leading someone more experienced than you isn’t about knowing more. It’s about respecting their craft, being confident in your own, and creating an environment where both can thrive. When you get that right, it stops being a power dynamic and starts being a partnership.

You’ve talked about the value of ‘interests and skills’ sessions. How has implementing this strategy transformed your team’s dynamics and productivity?

The idea behind “interests and skills” sessions is simple, but the impact has been consistently outsized. Most teams operate on assumptions about who’s good at what, who wants to grow in which direction, who’s motivated by what kind of work, all of this mostly based on a person’s job title. Those assumptions are often wrong, or at best, incomplete. The sessions are designed to replace guesswork with conversation.

It’s not performance-based. It’s not a 1:1 behind closed doors. It’s a team-wide, open discussion where each person talks through two things: what they’re good at and what they want to get better at. Strengths and interests, side by side. Sometimes they line up, sometimes they don’t. Both situations are valuable data.

What ends up happening is, people learn things about each other they didn’t know. Someone who’s quiet in meetings might have a background in customer research. Someone who’s always been handed execution work might actually want to lead a zero-to-one project. And when that information is surfaced in front of the group, it starts to shift how people collaborate. Who gets tapped for what. Who gets trusted with what. It breaks some of the default patterns that tend to calcify over time.

From a leadership perspective, it’s incredibly useful. I get a clearer picture of how to shape the roadmap in a way that stretches people while still delivering outcomes. But more importantly, it helps the team start to self-organize in smarter ways. Ownership gets more intentional, energy goes up, and silos break down.

And it builds trust. Not the manufactured kind, but the kind that comes from seeing someone as more than just their job title. That human layer, the acknowledgment of who someone is, not just what they produce, is what changes team dynamics in a lasting way.

So yes, productivity improves, but not because we’re squeezing more out of people, it’s because we’re finally aligning the work with the people doing it.

In your experience, what’s the most effective way to maintain team motivation during long-term, complex projects?

When I think about how to sustain motivation on long, complex projects, I always come back to lessons I’ve learned from running ultramarathons. Running 30 or more miles gives you a front-row seat to how motivation actually works over time. And it’s not how most corporate cultures act like it works.

The first thing you learn is that motivation is unreliable. It fades. It comes in waves. You don’t feel inspired for ten hours straight. You keep moving because you’ve built structure, rhythm, and a sense of purpose strong enough to carry you through the parts when motivation vanishes. Long product cycles are the same. You can’t rely on energy or urgency to hold things together. You need clarity, shared goals, and a plan for what to do when things get messy or slow.

The biggest thing is that, in ultras, you know at some point it’s going to suck. You’re going to hit the wall, want to quit, and feel like there’s nothing you can do to change that. Ultrarunners call that the pain cave. It’s not a question of if it will occur, it’s a when. The first few times it hits in races or long runs, it’s scary. But once you’ve been there and come out the other side, it changes your relationship to discomfort. You stop seeing it as a sign that something’s gone wrong. It becomes confirmation that you’re doing something hard, and that you’re still in the game.

Over time, that shifts your mindset completely. You start to anticipate the pain cave. And when it comes, instead of backing off, you lean in. You think, “This is the part most people don’t get through.” That’s the reframing: not just enduring the hard part, but seeing it as the separator. The thing that weeds out people who were just there for the easy wins. It stops being the part you dread, and starts being the part you get excited about.

I bring that same lens into how I lead teams through hard, slow, often ambiguous work. I normalize the dip. I make space for people to be tired, frustrated, uncertain. And then I help them reframe it: this is part of the process, not a problem with the process. If you’ve set things up right, if people have purpose, support, and clarity, they can push through. And when they do, they don’t just ship something. They come out the other side more capable, more confident, and more connected.

That’s the real outcome of long, complex work. Not just the product. The capabilities of the people you build in the process.

How do you approach giving constructive feedback to team members while still maintaining a positive and empowering environment?

For me, constructive feedback starts with respect. Not just for the person’s work, but for the context of what they’re navigating, where they’re growing, and what they’re capable of. You can’t give feedback in a vacuum. It only works when it’s grounded in trust, clarity, and a shared commitment to getting better.

I don’t believe in saving up feedback for performance reviews or packaging it in artificial positivity. I also try to give it at the opportune moment, which may mean holding off to see how the person naturally addresses it themselves, but not so late that it’s no longer fresh and specific. And I try to be as direct as I can while remaining empathetic. “Here’s what I’m seeing, here’s how it’s landing, and here’s why it matters.” That opens the door for a real conversation where we can address it together.

I also try to make a clear distinction between what needs to change and who someone is. Feedback should never be about character or personality. It’s about behavior, decisions, patterns. When people feel like you’re invested in their success, not just pointing out flaws, they’re far more open to hearing what you have to say.

And I don’t just give feedback, I ask for it too. From people above me, beside me, and on my team. That sets a tone. It shows that getting better is a shared goal and expectation, not a judgment, not a punishment, just part of how we operate.

If you do it right, feedback isn’t something people brace for. It’s something they expect, and eventually even want. Because it means someone’s paying attention, someone cares, and someone believes they can do more. That’s what makes the environment not just positive, but empowering.

Can you share an example of how you’ve successfully navigated a major change or transition within your organization, and what leadership lessons did you learn from that experience?

In the early days of COVID, I was at Fundera, a Series B fintech company providing sources of funding for small businesses. Practically overnight, every single one of our lending partners disappeared. Foot traffic had vanished, brick-and-mortar small business owners were shutting their doors, and traditional lenders were freezing up. The company’s business model just suddenly didn’t work anymore.

Then the government announced the Paycheck Protection Program (PPP), and it was clear there was an opportunity to serve the same customers in a new way, but the timeline was brutal. With so many companies and customers in the same boat, it was obvious there was going to be a mad rush to access the PPP funds, and we had maybe a week, at most, to figure out how to get something live if we were going to survive. The rules were unclear, the guidance kept changing, and we were competing against banks with massive infrastructure.

What’s stuck with me more than the operational details is that we had total clarity of purpose. For a brief window, everything that didn’t matter fell away. The mission was simple: move fast, serve small business owners better than anyone else, and get them the funding they needed to survive.

It was like the company snapped back to its seed-stage roots. Everyone just started doing the work that needed to get done, regardless of job description. I remember one of the engineers saying something like, “I’ve never seen a PM dive this deep into implementation.” But to me, there was no question. We were using whatever no-code, low-code, and duct-tape tools we could find to stand something up quickly, and that meant I could help in areas that I normally wouldn’t. In the end, we were first to market with a fully digital PPP application, and kept the company afloat.

That experience really showed me what becomes possible when there’s sharp clarity, real urgency, and a shared sense of purpose. It stripped away all the artificial constraints and revealed what high-functioning collaboration can look like when the only goal is to make something work.

Since then, I’ve spent a lot of time thinking about how to recreate that same environment, but without needing a global crisis to get there. Because the conditions that made us effective certainly weren’t about panic. They were about focus, humility, and mutual trust. If you can build that on purpose, not just in response to external pressure, there’s no limit to what you can accomplish.

Thanks for sharing your knowledge and expertise. Is there anything else you’d like to add?

One of the things that I find continuously reinforced through my fractional work at Rooted In Product is that none of this is static. Leadership, product thinking, team dynamics, and even best practices are all evolving constantly. What worked five years ago doesn’t always hold up today. And what works in one company, with one team, at one stage of growth, might fail completely in a different context.

The one through-line that does seem to hold is this: stay curious, stay pragmatic, and don’t mistake process for progress. The best outcomes I’ve seen came not from having the most refined roadmap or best-written artifacts, but from teams who knew what mattered, trusted each other enough to move fast, and were willing to adapt when the path shifted.

So, just remember to be self-aware, human, and relentlessly focused on what makes the work matter as much as the work itself.