Leader Spotlight: Innovating in a loss-averse environment, with Brian Root

Brian Root is a fractional CPO and former Senior Director of Product Management and Design at Assurance IQ. He began his career as a business analyst at Steve & Barry’s before joining McMaster-Carr. From there, Brian joined Amazon, where he held multiple senior product management positions, before moving to Director of Product Management, Everyday Living at Walmart Labs. Before his most recent position at Assurance IQ, he served in various leadership positions at both Fundera and Huckleberry, and now owns his own consulting company, Rooted in Product.

In our conversation, Brian talks about how product development differs in a loss-averse environment, such as insurance tech, from a gain-seeking one like Silicon Valley. He discusses his passion for a career that emphasizes well-roundedness, as well as how the nature of product management motivates him. Brian also shares how highly regulated environments deal with technological innovation and change.

A career shaped by ‘fate and luck’

Can you tell us about yourself and how you arrived at product management as your career?

I love doing things that require a lot of patience and dedication. I’m a marathon runner, I enjoy assembling mechanical watches, and I’m the father of a one-year-old. I’ve always valued being well-rounded rather than wanting to be really good at one thing. So, it felt natural to seek out a role in which being well-rounded is regarded as an asset.

My arrival at product management involves some elements that feel like fate and others that feel like luck. My grandfather helped build the JOHNNIAC, one of the first computers ever made. He introduced me to computers and programming in QBasic when I was young, so I grew up with a fundamental understanding of what programming can accomplish. When I went to college, I was a computer science major, but once I started taking advanced programming classes, I realized I had neither the skill nor the passion for it.

I ended up pivoting into economics, where I discovered game theory and behavioral economics. Combining them with what I’d learned from computer science led me to some very interesting excursions into modeling and data analysis. In retrospect, I couldn’t have asked for a better foundation for understanding the intersections of technology, strategy, and logical data with illogical human behavior.

Fast forwarding, I was fortunate enough to get an offer to join Amazon’s rotational leadership program coming out of business school — that was complete luck. The team that eventually became Amazon Business needed a PM with experience in industrial supplies, which, coincidentally, I had. That was my first placement at Amazon and how I officially became a PM.

Solving an array of problems across different verticals

You’ve held roles in many different-sized companies and industries. How have these roles shaped your approach to growing as a PM?

On my first day, my boss sat me down and said, “Here’s the problem we’re trying to solve. Your job is to solve it. Go.” I remember feeling empowered because it was the first time that nobody was putting a box around what I was allowed to do in pursuit of solving a problem. That was very motivating for me as a PM.

Of course, given my history, I really didn’t want just to be a PM — I wanted to be a well-rounded, great PM. So, I intentionally sought roles at Amazon and subsequent companies that gave me a breadth of experience — roles in B2B, B2C, innovation, growth, consumer-facing, internal tools, etc.

So, I went about building a very well-rounded PM skillset, but, interestingly, still felt the same resistance to being pigeonholed that I had felt as a child. People always want to put you in a box. Recently, I’ve heard a lot of people say, “So, you’re a design guy?” Technically yes, but before that, I was a data guy, an innovation guy, and the supply chain logistics guy. I find it unnecessary to label myself.

What I love about product management is that it allows me to solve such a diverse array of problems and flex many skills in new contexts.

You worked in fintech and insurance tech before founding Rooted in Product. What is it like working in such highly regulated industries?

There are some big differences between highly regulated industries and less regulated industries. The operating rhythm, for lack of a better term, for a product manager is different in regulated industries. At a macro level, regulation can and does change. And the consequences of not reacting quickly or accurately enough to that change in regulation are severe.

Regulatory bodies don’t care how hard it is for you to make a change, so it’s really important to avoid hinging the success of your product or business on something that may be subject to future regulatory changes. If you’re forced to completely rework your business model, it could be a death sentence for your product or company.

When changes occur, the requirements are also, typically, lacking a lot of the detail that you, as a PM, need to define your product’s specifications. Even following up with regulators to get clarification is challenging. There’s often massive ambiguity combined with a tough deadline that’s being delivered to you by a third party you can’t talk to very easily. It’s a really harsh combination.

Mitigating sources of risk

What does planning to succeed as a PM look like? Could you talk more about that?

I’ll give an example of Medicare, which I’ve focused on over the last few years at Assurance. Before you can make any change in written or oral communication to a customer, the proposed changes are subject to compliance reviews from the Center for Medicare and Medicaid Services and insurance carriers. It’s a two-step process.

Those reviews can take several months to complete, so it’s not unreasonable or unlikely to find yourself in a situation where you only have four or five bites at the apple over the year to improve your product. You’re waiting for these giant approval periods to clear, and typically only one or two of those attempts will yield something successful.

Changing your product substantially once or twice a year significantly lags behind what you get in less regulated industries where you constantly see these micro improvements. That’s why the rate of innovation in regulated spaces tends to be much slower than that of less regulated spaces.

So, if you really want to accomplish anything as PM in regulated spaces, you have to be clear about what you’re trying to accomplish, how you’re going to test it, and what you are going to do about the positive, negative, or ambiguous results of those tests. Try to plan all of that out alongside your roadmap so you can get it approved simultaneously and work ahead of the approval process. Planning with this degree of rigor is a great skill for a PM to develop because it means you’re getting sharp on the “what” and the “why” of what you’re building.

How do you go about trying something new in this environment where change is consistently viewed as risky?

It is very hard. I’ve spent some time in Silicon Valley, and not to be stereotypical, but when you come up with a crazy idea, people will jump on it because they’ve seen crazy ideas turn into billion-dollar companies. But it’s the opposite in regulated environments. You devise a crazy idea, and your control partners, legal and compliance, will hear it and think, “We could get sued for billions.”

When control partners are a key part of your product development process, their primary function is to enforce loss aversion rather than seek gains. As a PM, this raises the bar for you to anticipate and mitigate those sources of risk, which can make your job harder. You have to be much sharper and more able to anticipate what may or is likely to happen. You also must anticipate that the response to proposing anything innovative will initially be no.

How do you move forward with innovating, especially as it pertains to competition, in this type of environment?

There are two paths forward. One hinges on relationships. Find ways to bring the control functions — legal and compliance — into the fold. Partner up with them, ideate together, and make them tell you why it won’t work. Then, invite them to come up with a solution with you, which is not their job, so you’re asking them to partner with you on something they wouldn’t naturally do.

Plus, you have to be prepared for the MVP version of whatever you’re proposing to be the smallest possible test of all possible tests. It’s going to be a much longer ramp to do anything innovative within these spaces because you have to continuously prove that you are not incurring more risk than was anticipated.

The second path comes from the idea that new things within fintech and similar verticals are often old things in other industries. For example, take the concept of giving customers a choice in how they transact. Within regulated industries, it was a very common dynamic to force people to talk to agents over the phone, regardless of the customer’s preference or value to the company. The idea of giving customers choice and enabling purely digital means of communicating and transacting has proven to be innovate at every place I’ve worked in these spaces.

It’s a great reminder that innovation is contextual, and one of the critical skills for PMs in any space is analogical thinking. If you can overcome the inhibiting factors I previously discussed, there are plenty of opportunities in fintech and insurance tech to apply that with a potentially massive impact.

Changing customer norms and preferences

What do you consider to be pitfalls in the general product-centric mindset within these regulated industries, and how do you work past them?

One absolutely critical strategy to avoid the traps of product-centric thinking is to embed customer feedback loops into your processes. In my opinion, nothing replaces properly conducted UX research as a critical input to product development. We have a role that literally specializes in distilling the voice of your customer into unbiased and actionable insights and it’s so unappreciated and underutilized at most companies.

Another aspect of customer feedback loops that often gets overlooked is that you should create them at every level of your business. It’s all well and good to have your individual contributors factoring the voice of the customer into their work, but if the executives conducting strategic planning are out of touch with the customer then you’re just going to end up building the wrong things.

One tactic I love for involving people of all levels in customer feedback loops is dogfooding. In my experience, a mixture of using the product yourself and watching real customers use your product, such as via session replays, yields the best results. The latter helps to overcome the bias of familiarity.

Regardless of how you approach dogfooding, it’s critical to do it with intellectual honesty. If you’re dogfooding your experience and you just start making excuses about the things you don’t like — “oh, that customer just didn’t know what they were doing,” or, “yeah, that’s not ideal but it’s the best we could do” — then you’re losing the value of the exercise. Your customer doesn’t care about your excuses — their experience is their experience and if it’s bad then it needs to be fixed or eventually they’ll take their business elsewhere.

Another strategy I’d recommend is forming cross-functional teams. When you have different perspectives and skills on a team, that creates tension that has to be resolved by explanation. The less an individual or functional team has to explain what they’re working on and why, the greater the likelihood that they will work on things that are interesting or important only to that individual or team.

Well, that would be fine if individual and team priorities organically mapped to company and customer priorities, but they often don’t, and anybody who’s been through annual planning cycles knows just how painful and difficult it can be to make them do so. So it’s not a foolproof strategy, but if you can create cross-functional teams, and ensure that you have a customer-centric viewpoint represented on the team, for example by a UX researcher, then you’re at least increasing the likelihood that the resulting work will reflect a multifaceted understanding of both your customer and product.

What about the debate of adding more features to improve an already complex or robust product?

It is counterintuitive for a product-centric company to say, “You know what we need? Less product.” Your customers might be shouting at you in all ways they can, “You have too many features. Your UX is confusing.” The typical product-centric response to that would be, “All right, let’s build an onboarding tutorial.”

Essentially, you’re adding more functionality to solve the problem of having too much functionality. It’s always an accretive response. My job is, fundamentally, to solve problems, and there are situations in which eliminating the source of the problem can be an effective solution.

To abstract this idea up a level, if I’m constantly adding features, headcount, and complexity to my product, I’m creating more opportunities for problems when my mandate is the opposite of that. The Friction Project by Robert Sutton and Huggy Rao talks about this concept called addition sickness. It’s the inexorable growth of process, communication, and headcount around a product. They’re not talking about this exclusively in the context of product-centered teams or companies, but the two ideas are inextricably linked.

You mentioned the pitfalls of addition sickness. How do we create an environment that helps to avoid these pitfalls?

There have been many situations where I’ve either planned to launch a product a certain way, and then realized during the product development process that either a feature was unnecessary or could be accomplished with dramatically fewer resources. I had some early experiences at Amazon in this regard, but at most others places I’ve worked, only accretive actions were rewarded.

I find that it’s vital to value and reward people for finding ways to simplify the product and intentionally not invest resources in things we can’t justify. It shows that they think about the business impact of building and maintaining those things, particularly in aggregate.

The qualities of an effective cross-functional team

When people have differing experiences and opinions about product decisions, how do you effectively build a cross-functional team?

Theoretically, there are three key qualities of an effective cross-functional team. One is that each individual on the team is in their highest-leverage position. Two, the team’s impact is achieved in ways that are self-enforcing. And three, these ways sustain over time.

To the first point, everybody on the team needs to be in a position where they add the most value. So, it’s important to consider what individuals and roles should be on a team and how the team should be structured. There’s an organizational tendency towards making teams similar in size and composition, but we should instead be thinking about maximizing the impact-to-cost ratio of each team in isolation.

The second and third points are really important to me because they speak to the culture of the team and of the company, respectively. If you have a self-enforcing team culture, it’s vital to ensure the team can do their work with agency. If I’m a leader and I have to step in to correct and adjust the team constantly, it isn’t a team, just a collection of individuals held together by oversight. To be self-enforcing, the team needs a shared set of clear and comprehensive values, and it’s the primary job of a leader to instill those values in the team.

Sustainable ways of working are crucial, too, because I have seen so many teams achieve significant impacts and then get run into the ground in doing so. The product gets shipped, but everything else pretty much falls apart. That might feel like winning the battle, but it is essentially losing the war. You have to reassemble the team, rehire people, etc.

There’s a debate in the product world about differentiating people based on roles and titles vs. what they’re accountable for. What’s your take on that?

I prefer to think about the differentiation of accountability rather than the differentiation of roles. Role, to me, implies an almost exclusionary area of expertise in the set of tools that you’re using. You’re a UX/UI designer, or you’re not. It’s a binary thing. Accountability, on the other hand, implies an inclusionary outcome. I can be accountable for ensuring the UI is usable without actually opening Figma. I would do that by working with other people to achieve that goal.

Every key risk for your product, whether people can find it, use it, or enjoy using it, needs an accountable party on the team. As a leader, I make it clear to each team member what they’re responsible for, when, and to whom. But I want everybody to approach being accountable inclusively and collaboratively so that, ultimately, the whole team ends up being liable.