Kelly O’Connell is Chief Product Officer at ActiveCampaign. She started her career as a client relations associate at Hallmark Data Systems before transitioning to a product owner role. From there, Kelly joined customer success at ActiveCampaign and has spent the last nine years in various roles, including solutions consulting, product management, product strategy, and more.
In our conversation, Kelly talks about how things like leadership, structure, and culture change as a company scales. She discusses the importance of aligning on messaging and communication, as well as how layers of management evolve with time.
ActiveCampaign is an industry-leading marketing automation platform that helps small teams power big businesses. Customers from over 170 countries depend on ActiveCampaign’s mix of pre-built automations and integrations to power personalized marketing, transactional emails, and one-to-one CRM interactions throughout the customer lifecycle.
We’re currently building a platform that suggests what users could do next and adapts to their use case, vertical, role, etc. The goal is for it to validate that what they’re building will work and drive conversions and revenue.
It’s been a long learning process. When I joined and was building teams, organizations, and processes, I was in it every day. I did all the roles my team was doing — managing customers, driving onboarding, and meeting every day while building the team at the same time. As you scale, you learn how to lean back a little and delegate. You learn to trust the team while also balancing when to lean into something.
That delegation and trust of the team, as well as trust in the structure of the org, was important to give me time to think about where we are going, what we are doing, and our purpose. I also believe that you have to learn various modes of communication. When you’re a small team, one message cuts it — you can use the same message for everyone. As you grow and have different teams under you, they’re all motivated differently, so it’s critical to understand how to communicate with each team.
For example, how do I communicate this to an engineering team versus a product team versus a design team? How is it going to motivate them? What do they need to learn from this change? It’s important to think about the various audiences you’ll have and how to tailor your communication to them.
Lastly, operating at an executive level is very different than at a functional level. It’s vital to understand the cross-functional impact you have. How are you going to work with all of the leaders in different areas to drive progress? What do they need to know about your work? How do you communicate the work of your function to others? This was definitely something I needed to learn as we scaled and built more and more teams.
It’s a constant evolution. You always have to think about how many levels of management your company needs. As you start watching an org get really wide, you start realizing that either you or another manager is at capacity. So how do you bring on another leader or level without it becoming bureaucratic, while also understanding everyone’s day-to-day? It’s important to think about how many levels and layers you have, as well as how wide the scope is getting on any leader.
We’ve moved teams around over time here. We’ve moved design from a standalone function into product, and as we noticed some functional splits or differing goals, we realized we needed to bring those teams into one org to make sure they were going the same way. Some teams can separate just fine, but others stay together. For example, we had both tech and product living under engineering previously, while now, we’ve made those two separate orgs sitting next to each other to achieve more balance.
Speed of decision is a big one regarding how many stakeholders exist within the same org. Also, I’ve noticed that if I see two levels acting as the same authority, there’s the possibility that decisions are being duplicated. I make sure to have quarterly 1:1 sessions with all of my ICs. If I start noticing that they’re getting degrees of separation in communication or they’re not understanding the company or org goals, there might be a gap within the layers. That’s either something that we need to address with the person or we may need to check if the layer is skewing things in a different direction.
When our organization reached about 200 people, we decided to clearly state our values and what we respect as a team. These things were always intrinsically known, but we had not explicitly said them or specified that this is what we care about. When we did that, it took a few more years to bring those values into the day-to-day operations of the company, and now we include those values in our review cycles. How is everyone living up to or honoring these values? I’ve also included them in my competencies for each level of product management or design.
Any award we give out — whether that’s a functional award, for culture, etc. — always comes back to those company values. Everything that you’re celebrating or managing performance on should have some layer of those values within it. That way, everyone thinks about how they’re contributing to those day in and day out.
Further, it’s critical to understand that values can adapt. How are you getting feedback on them? How are you understanding, as you bring more and more people on, what’s changing, what’s resonating, and what’s not? For example, we had a value called “iterate everything always” for many years. A few years ago, we dug into feedback on this and talked to many people. People were reading that value like everything always changes, which isn’t what we wanted to emphasize. So, we adapted it to “iterate everything wisely.”
This was something that was very top of mind a few years ago. We were so focused on the customer problem and the problem of today that we weren’t always talking about what was next. One of the ways to break some of that was to create a purely experimental growth team. They did not have a roadmap and operated very differently from other product teams. The entire goal was just to drive some of that learning. We made a point to celebrate failure as much as we celebrated success; we also embraced risk-taking.
I’ve also found that it’s important to allocate time for innovation. We have a quarterly hackathon where we invite everyone in the company — not just tech and product — to devote that time to think outside of what we’re currently working on. We celebrate ideas and work on that cross-functional collaboration.
Some elements have stayed the same, but others have changed. Early on, we were looking for generalists who could dive in, get their hands dirty, learn something new, and jump into a few different roles to find success. Now, we look for more specialized experience. Like, how well does the candidate know this functional area that I might have to manage? For example, as we bring on a designer for reporting, do they have design experience in data and insights?
With that said, I’m still always looking for that entrepreneurial spirit — the person who’s going to learn, grow, and be OK with their job being different from what’s on their job posting. They’re going to make this job theirs.
It’s both. However, now, it’s a lot easier to invest where we want to. We have many things going at one time but we can decide where we want to lean in, where we want to scale back, and where we want to focus. We have incredible people, talent, resources, and capacity, so it gives us a lot of opportunity.
The difficult part is that with more people comes more stakeholders and more layers in decision-making. More people need to understand what we’re doing and why it matters. That communication becomes much more critical. It can sometimes feel slower and more painful to arrive at a decision compared to when only a small group was making the call, but the opportunity with budget, resources, people, ideas, etc. makes things more exciting than ever.
On the really big items, the executive team and senior leadership need to make sure they’re on the same talking points. They need to be working from the same framework, even though in many other ways, we operate differently. Every executive sends a weekly email to their team and includes the other leaders. So, for example, I know what our CMO and CTO are sending every week. I can then make sure that I’m aligning, reiterating, or celebrating something that they talked about.
Also, we used to do quarterly company updates. We’ve moved that to monthly to drive consistency and frequency of communication from leadership. We found that when we did this quarterly, we might have had a new hire start a week after the update, so they don’t hear from the CEO for an entire quarter. Driving that frequency was important to make sure we were all highlighting and celebrating the same things.
We have a Slack channel dedicated to celebrations that everyone in the organization is in. Many people use it to celebrate launches or early access, but we also now use it to celebrate experiments where things didn’t work as expected but we still learned something from them. Celebrating those in the same way we would celebrate a big GA is getting more normal for us. It took a while for us to make sure we were giving those items just as much attention as some big launches, but we’re getting there.
That’s a common problem. As we scaled, we found that customer-facing teams were siloed from the product and engineering. There was a lot of potential innovation being missed, so we had to think about how to get those teams to talk to each other and drive empathy. We want them to share what customers are saying and create that excitement.
So, a couple of years ago, we developed a program called BFF. This was our way of getting the customer org and the product org to work together on backlog ideas. They’d get on customer calls together, understand what was going on with the product and customers, and ultimately drive some of that excitement cross-functionally.
We created a growth team, which initially allocated resources for experimentation. What I didn’t love about that approach is that it makes it seem like no one else is working on innovation, which isn’t true. It’s really about how you are blending innovation into your strategy and how you are using it to differentiate.
For example, one of the ways we have won in the past — and we believe we’ll continue to win — is the velocity of our new functionality releases. We want to continue to win by our velocity even as we grow. Then, it’s important for us to bring that into planning and prioritization. We just modified our planning process. We’re still thinking a quarter ahead, but teams are bringing all of their ideas about where they could go.
Our leadership team is thinking about things like what is innovation? What is the market-leading direction we want to take in the next quarter? How is that balanced with retention initiatives? We leverage our overall strategy to prioritize what our teams are going to work on to drive the most value.
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.
It’s important to distinguish between these roles and create an infrastructure where they come together to build useful products.
At its core, product lifecycle management (PLM) software is a tool designed to manage every aspect of a product’s lifecycle.
Scenario analysis is a strategic planning tool that helps you envision a range of possible future states and the forces behind them.
A fractional product manager (FPM) is a part-time, contract-based product manager who works with organizations on a flexible basis.