Leader Spotlight: Structuring teams around OKRs, with Ghazal Badiozamani

---

Ghazal Badiozamani is Chief Product Officer at Catchafire, a social impact platform that brings together corporations, philanthropies, volunteers, and nonprofits to drive local impact. She started her career building incubations at a CleanTech fund, then moved to RELX, an information services company, where she led corporate strategy and later product in their STEM business. Prior to Catchafire, Ghazal was the head of product at Celtra, a B2B enterprise marketing content creation and distribution platform.

In our conversation, Ghazal talks through how she organizes her product teams around goals and OKRs and how, by doing so, product teams are empowered to experiment in any area to move those metrics. She discusses the qualities that make a good product manager, including curiosity, a strong sense of responsibility, and the desire to always ask questions. Ghazal also shares how her 15-year experience in AI has influenced her view on how it’s transforming product management.

---

Providing structured volunteer opportunities

Catchafire helps match real company projects to volunteers with specific interests. How do you differentiate yourself from other volunteering platforms?

We are different in two ways. First, we really focus on impact. We put a lot of effort into making sure that every project is meaningful and drives real impact for the organization. We are not optimizing for Instagram! Related to that, we bring a lot of structure. A lot of times, you might find an organization that inspires you, but they don’t have a strong structure in place. When that’s the case, you and the organization can churn for a long time. And both sides are unhappy because they don’t feel like they walked away with something useful or meaningful.

So, we spend a lot of time making sure that the projects that organizations are posting are robust and structured. We have suggested milestones, so we give a lot of support along the way to make sure that the engagement is going to go well. The expectations are clear and everybody knows what they’re getting themselves into.

Associating teams with goals

You’ve talked about how you have a unique take on planning at Catchafire. Could you share more about that?

In most companies, engineers are organized around pieces of the platform or a specific capability, like the help desk team, distribution team, authoring team, etc. When it comes to goal setting, everyone is talking about OKRs. For better or for worse, people are starting to think about OKRs the same way we thought about performance. OKRs were supposed to be these big moon shots completely separate from performance, but now, increasingly, we’re expected to shape our strategy and roadmaps around the achievement of the OKRs. They’re no longer this extra thing, but a core part of the business and the core part of planning.

Say you have an OKR to grow the number of conversions on an ecommerce website from X to Y. There are so many different ways to do that. A head of product will have to say, “Okay, help desk team, we want you to write some help desk articles about this.” Or, “Hey, this team over here, you do this thing.” The work gets separated into different teams, creating dependencies, and then it all has to be governed and managed.

Alternatively, if you have an overarching goal to move into a new segment and you’re trying to get ideas to come from the ground up, your teams are very limited in their scope. People will focus on their areas of control instead of thinking broadly and experimentally.

That’s why, at Catchafire, I’ve organized my teams around goals. We have objectives and key results, and each team is associated with an OKR. On the executive side, this makes it really easy for us to be clear about our level of investment. If we have 100 engineers and three OKRs, how are we going to distribute our resources? Is it going to be an even split or are we going to do 50 percent toward one goal and 25 percent in each of the others? We can have a really meaningful and robust conversation around how much we want to invest in each goal.

How does this benefit your job managing these teams, as well as the employees themselves?

As a product leader, I can start to think about my team as a portfolio. I can look at the goals, think about it like a dashboard, and move teams around easily. If I had my engineers organized around pieces of the platform and something starts to stall in one area, it’s really hard for me to take a help desk engineer and have them move to support a distribution goal. Whereas, if we have self-contained teams that have a cross-section of expertise, we can move entire teams to help with goals.

On the team level, there are so many benefits for the team working this way. I’ve never met an engineer who wants to only look at one piece of the platform; every engineer wants to be a part of and understand every piece of the platform. They always resist being boxed in or pigeonholed to just one thing. Having these self-contained teams enables engineers to have visibility into the whole platform. It also frees the team to explore and experiment in any area. And that drives a lot of enthusiasm, excitement, and experimentation because now, they can move that metric.

Do you have an example of a recent project that shined because of this organizational setup?

One of my teams at Catchafire had a goal to move a metric, and not only did they exceed that target, but they also came up with two completely new product ideas. With this type of structure, the world is truly their oyster. They had a blank canvas and they were focused on the problem and how to solve it.

One of the new products is an SMS chatbot that we just released. We have a problem where leaders of organizations just don’t have time. They’re too busy and they can’t take the time to log in to our platform to post a project and get help. We chose not to build a mobile app, and I have always resisted building mobile apps because there are so many of them out there and I’m not quite sure if users really want them. The team built an SMS chatbot to help us leapfrog that technology. You don’t even have to open the browser. You just send a text message and the chatbot enables you to post a project through text.

Justifying features with OKRs

How do you mitigate challenges in organizing your teams around goals, like teams having similar ideas?

It doesn’t matter if you’re organized by goals or if you’re organized by pieces of the platform, there will always be dependencies across the teams. What works well for me is setting up a governance team. The leadership of the different squads — the tech leads, product managers, and design leads — get together regularly to go through what each team is working on, how they’re interacting with each other, and things to watch out for. Or, maybe two of our teams have a similar idea or want to build in the same area of the platform, and the foundational piece is the same for both things that they want to build.

We can discuss which team is going to build that foundational thing so that the other team will benefit. We can sort of work through a lot of these issues with a governance structure but also encourage cross-team collaboration and knowledge sharing.

I imagine this goes hand-in-hand with trying to avoid becoming a feature factory. Can you speak to how you’re avoiding that?

This is exactly the same thing. If you just have teams oriented to pieces of the platform, then you, by nature, will be a feature factory because you’re creating a roadmap that’s one feature after another. And you’re justifying those features with OKRs. It’s often hard to see which one is leading the OKRs or the feature ideas. And it can be demotivating for teams to see this long list of things that they’re going to do one after another. But if you organize around goals and have key results or metrics that you’re trying to move, then you are breaking out of that feature factory mindset.

This is not to say that you’ll never have a list of things to build. Sometimes, when you’re going from zero to one if you want to break into a new customer segment or want to build a whole new set of functionality, there is going to be a period when you have to just build. There’s no metric because the product doesn’t exist. You have to build until you get the table stakes, and then you can move more into that experimental metric-led delivery.

And both things can exist in the same company at the same time. Some teams might be building zero to one while other teams are working to move a metric.

Shifting projects and keeping motivation

You mentioned that leadership will do a weekly sync and maybe change things around so the teams do not overlap too much. How often are teams shifting to work on different things?

I try to set teams, give them goals, and have them stay with the goal until the goal is no longer relevant to the company. You’ll have the same goal for a year, maybe two or three, but at some point, the goal will change. I like to have the teams connected to a goal for a long period of time, and then the key result under the goal can change from quarter to quarter. In terms of moving teams from one goal to the other, it’s not something I would want to do every quarter, but the option is there if I need it in a pinch.

Do you find there to be challenges like morale or keeping that motivation if teams are organized this way?

I actually think it’s more motivating. What I’ve seen is that people love having a goal, and especially for those teams that are trying to figure out how to move a metric, it’s so much more motivating to be given a metric to move rather than a list of features to build. It creates a much stronger sense of autonomy and that drives motivation.

Curiosity and a strong sense of responsibility

What is your philosophy on spending time with internal processes like Jira tickets, roadmapping vs. the outbound, competitive research, etc.? What do you think is a good balance?

I think a lot of it depends on the maturity of your team. So, if you have a very strong engineering team with good processes in place that can work like clockwork, then you don’t need to spend a lot of time focused on execution. But, if the team is not yet settled, you’re still working out the kinks. You need to be in the weeds with process and execution because ultimately, it’s the product manager that’s responsible for the delivery of an outcome. And if you’re not driving execution, then you’re not going to hit your outcome. It doesn’t matter how great your discovery was if it falls in execution.

So it’s a really hard balance. The ideal world for a product manager is to be working on three different things at the same time:

• New products — New things you’re exploring or discovering. You need to do competitive research, like user interviews, and work with design on concepts
• Things in the execution process — The items you’re working on releasing. You’re planning the sprint, you’re tracking each ticket, you’re answering questions
• The thing that was just built — You’re building dashboards, you’re monitoring metrics, you’re catching bugs, you’re working with marketing to roll out campaigns, and you’re tracking adoption and the success metrics

For folks who are new to the field or want to get into product management, what does it mean to be a good product manager?

I think being a good product manager means that you are very curious about the problem you’re trying to solve. You’re curious about the customers you’re serving, the market that you’re in, your competitors, how engineering works, how technology is built, how the system interacts with different parts of the system, etc. It’s kind of a mindset of always asking questions, always trying to dig one more layer deep, and thinking broadly while being detail-oriented at the same time. It’s very challenging, which is why not everyone is in product management.

You have a really strong sense of responsibility. In some ways, a product manager is responsible for everything but doesn’t actually do anything. You don’t have any control of the designs, you don’t have any control of the code because you have engineers doing that. You don’t have any control over the adoption because marketing is doing the campaigns and customer service is supporting the customer.

But you were responsible for the whole of it. I’ve seen product managers who will point the blame at someone else if things are late, for example. And that kind of personality isn’t suited to product management. They need to be in a role where they have a lot of control over the thing that they’re supposed to deliver. Good product managers hold themselves accountable for every piece, even if they are not directly responsible for delivering it.

‘AI is like a hammer’

Lastly, AI is a hot topic across all industries. What are your thoughts on AI and how people are implementing it?

I’ve been working with machine learning and artificial intelligence technologies for 15 years. I think about these technologies as a tool. It’s like a hammer. You can go around with a hammer looking for a nail or you can spot a nail and see that your hammer is the right tool for what you want to do with that nail. What I’m seeing right now is people running around with hammers.

They haven’t quite figured out the value, customer problem, or value proposition that we can deliver most effectively with this tool. So, when you talk to people, it starts to feel like they’re just doing it for marketing. They want to say they’re using AI or they’re building stuff for the sake of building it. I think the key is to really figure out the customer problem first and make sure that that customer problem is really valuable and worth solving. And then, if it makes sense, use machine learning or AI to solve that problem.

For example, when I was at Elsevier, we had massive amounts of content and wanted to recommend content to the user depending on where they were in their workflow. Having machine learning tools that can deliver that kind of personalization of content delivery is powerful and totally game-changing. The hard part is finding the right problem to solve. And if you can, then you can unlock a lot of magic.