Leader Spotlight: Easing into dramatic change, with Michael Lubansky

Michael Lubansky is Senior VP of Product Management at COMPLY, a software company specializing in regulatory compliance solutions and parent company of ComplySci, RIA in a Box, National Regulatory Services (NRS), and illumis. He previously served as Head of Product Management at RIA in a Box before its acquisition by ComplySci in 2021. Before that, Michael worked in product leadership positions at Sageworks, Dun & Bradstreet, and Decipher Finance.

In our conversation, Michael shares his experience working at RIA in a Box when it was acquired by COMPLY, thereby tripling total headcount and becoming five companies with four different platforms. He discusses the challenges that came with that, namely navigating new stakeholder processes and keeping the right people informed in product decisions. Michael also talks about the importance of not keeping a static view of the roadmap and adjusting the product vision based on changing circumstances.

Bringing five companies and four platforms together

A few years ago, COMPLY acquired Ria in a Box, where you used to work. Now, COMPLY is made up of five companies with four different platforms. Do you think about these platforms separately or are you trying to consolidate them?

There have been a lot of opportunities to integrate these platforms and their capabilities. In the last couple of years, we’ve brought eight product managers across the four platforms together. We found ways to cross-pollinate the teams and how those capabilities can match the different segments that we serve. Overall, having one COMPLY platform is the drumbeat we’re marching toward.

Logistically, you can’t bring four platforms together overnight. There are incremental steps as we integrate capabilities from the different platforms. We’ve done some of those integrations already from, say, the NRS platform into the RIA in a Box platform, where we’ve found there’s a shared capability. NRS was more robust for what we want going forward, but there are more capabilities and clients in RIA in a Box. It made more sense to find a way to integrate and shift that one capability from NRS over into the new product.

Eventually, it may all be one platform or even two — we have two pretty distinct customer segments between the SMB wealth segment and the more institutional segment. The look and feel could be very consistent between the two platforms and eventually, some customers might migrate from one platform to the other. But that all will take shape over time.

Can you speak to your experience at RIA In A Box during the acquisition from ComplySci?

With a strategic acquisition like that, there’s always a goal and investment thesis for the investors that are bringing these companies together. It took time to understand what that strategy and shape was going to be. Bringing four companies together, as you’d expect, was a change for me, my team, and a lot of folks in the company.

Over 200k product managers and developers use LogRocket to create better digital experiences

Learn more →

There are different processes, cultures, and practices amongst different teams. The challenge there is certainly balancing gradual change against the reality of the long-term plan: bridging the companies together and bringing people along for that ride. It’s been interesting as far as that part of things go, but there is a really exciting vision as to the combination of these companies.

Navigating stakeholder management after an acquisition

Aside from the org-wide challenges you just touched on, are there any specific challenges that you faced and have gotten through?

Stakeholder management is an interesting one and that has certainly been an evolution for me. Getting acquired by COMPLY, we almost tripled in size overnight. I was meeting new stakeholders, understanding how to navigate that process, and how best to keep the appropriate folks across all teams involved. At RIA in a Box, we were less formalized as far as processes, so we had to evolve to a more formalized process with more stakeholders.

What I learned is it’s important to get a firm grasp of the go-to-market process and what role each stakeholder needs to play in that process. Oftentimes, they may be the responsible party or accountable party other times, but there are a lot of other people that need to be consulted, informed, etc. It’s about really understanding and how that can best take shape when you do have more stakeholders involved.

You mentioned making sure that everyone stays informed. What skills does that pertain to specifically?

One is just understanding the structure of the organization, who everyone is, and what they do. Even with roles that didn’t necessarily exist in the previous organization like revenue operations, for example. I’m familiar with some of them, whereas others are evolving disciplines. It’s good to understand how that should fit in now versus where it was before.

There are a lot of different natural wrinkles and nuances when you have different organizations coming together with a variety of stakeholders. Understanding the roles that people play within those organizations, who needs to be consulted, and how particular things that you’re working on may impact their organization involves more steps.

Maintaining a dynamic view of the roadmap

Can you tell us about your experience working on roadmapping and planning long- and short-term roadmaps?

Roadmap planning is really based on a variety of inputs and synthesizing them — inputs from the market, the competitive landscape, market trends, and insights directly from customers. It’s important to have all these aligned, making sure you’re capturing the information so you can then synthesize it into a product vision. You’ll then elucidate a way to explain that vision to your team and the company.

Ultimately, you’re looking for the vision that the business and the product are driving towards, which can determine product strategy. Once you have the product strategy aligned, it’s important to prioritize initiatives over the next 12 months that are going to help the company achieve its three-year strategy, for example. And communicating it is important as well. I typically like to have the team do a company-wide monthly release and roadmap updates. This keeps the company in sync with what is being built and planned.

It’s important to have that communication and those types of inputs flowing into the roadmap as you put it together and plan it.

Many teams find that the roadmap they build for the product differs from what they actually end up producing. Can you talk about how to navigate those changes as different factors come into play?

Obviously, things change. Sometimes you’re not exactly where you wanted to end up, but sometimes you’re not too far off because key aspects have come to fruition. When you have that guiding post, you can continually reevaluate the landscape as far as what’s happening with new regulations, market dynamics, competitive pressures, or opportunities.

You have to be nimble, adjust, and probably even reframe that three-year strategy periodically as well. It’s not a static point of view, it’s dynamic. It’s a point-in-time vision. And you have to keep adjusting that vision based on when circumstances change. I wouldn’t imagine that you’d ever end up exactly where you thought you would be in three years, but at least it gives you something that you’re working towards based on the information that you have at that time.

And with roadmaps, how do you prioritize product ideas to ensure that resources are allocated effectively and efficiently?

Different prioritization frameworks can make sense in different contexts. For me, it’s important that you have a good sense of the business case and opportunity sizes, and also a firm sense of the product and development effort. Only then can you weigh the business opportunity of the different initiatives against the effort level so that you can prioritize. The RICE framework is one of several frameworks that can help assess this. I’ve utilized several of them in the past.

Another way I’ve done this is, after initial prioritization in road mapping, pressure testing things to measure the overall person-months for the projects that are planned. We align with the engineering team to assess how the overall total person-months measures up with the resources the team has. While this may seem like an academic exercise, it can shed light on when there is a resource mismatch.

Can you share an example of a time when you had to decide to really prioritize something, even if it meant pushing everything else out of the way?

Within the first year or so of joining RIA in a Box, we had a focus on a particular adjacency of building out a cybersecurity product. There were a lot of other things we could do, but a good adjacency to compliance was building out a security awareness training and phishing testing product. There was a big need, and cybersecurity continues to be a big challenge and compliance-related need for firms. We built out a mini-learning management system for that.

There were a lot of other things we could have been doing that we ultimately needed to defer on. It was one of the first initiatives for us as a company where we galvanized most of the engineering team towards quickly building out this product and pushing some other things to the side for a little bit. It paid off, as we had a quick uptake in sales to our existing customer base and added a lot of revenue to each new logo sale.

So you went with that product because it was, at the time, what your team felt was the most needed in the space at the time?

Yeah, based on the landscape. We talked with customers and did quantitative surveying to understand how likely our customers would be to buy a product like that. We did market research around our pricing to get an understanding of what the pricing might look like and what uptake would be. It was pretty good validation to know that based on market trends and what our customers were saying, that it was going to get a good uptake initially and increase annual contract value (ACV).

Growing the product organization, team, and individuals

You’ve worked in a lot of different environments and different size companies, many times as the first product person. Can you speak to your experience building out a product function from scratch in an organization?

Stepping in as the first product person in an organization is a really unique and valuable experience from my perspective. Usually, I’ve come in when there’s already somewhat of a development function and practice, but not necessarily a true product function for prioritizing work, structuring, and implementing it.

There may already be a good core product and even a reasonably well-functioning development process, but without the product function, we’ll have a lot of room for improvement. Some changes have to be made of sorts and people are always somewhat resistant to change. I found that incremental, as opposed to dramatic change, is the way to do it. Introducing tools, frameworks, and processes gradually at times. Sometimes you can do it a little more quickly, it just depends on the people and teams and receptiveness.

And how do you support the growth and development of either new product teams that you’re building out, or existing product teams?

You can take this in two directions — growing the team and growing the individuals. We’ve had different opportunities that have been given the latitude to grow and develop the product team. For me, it’s important to think about the right structure of the team, their needs, and strengths and weaknesses. You need to try to balance the need for diverse perspectives with strengths that will help with operational efficiency.

In all these cases, I’ve also worked to find ways to support the growth and development of each of the individuals on the team. It’s important to recognize each individual’s strengths and areas of growth and have ongoing open channels of feedback.

I’m really proud of the fact that I’ve had a hundred percent retention of my direct reports over the last two years, even with the great resignation and change brought about by bringing together four companies. And I’ve done this by building strong bonds with each person, establishing a collaborative culture, and listening. I understand what their goals are and how I can best support them, whether that’s within my team or being promoted to other teams as well.

Finally, what advice would you give to product leaders experiencing a transition? This could be in terms of a reorg, acquisition, change in employer, etc.

In each of those situations, I’d say the sooner that one can let go of the old and embrace the new, the better. The sooner you can recognize that the new situation is just that, a new situation, the better and easier it is to adjust and excel there.

It’s easy to hold on to the old situation, but that ultimately holds you back. There are good practices to always bring with you from any of your previous experiences, but you need to figure out how to implement them in the new scenario.

LogRocket generates product insights that lead to meaningful action

LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.

With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.

Get your teams on the same page — try LogRocket today.