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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
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.
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.
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.
While agile is about iterative development, DevOps ensures smooth deployment and reliable software updates.
Aashir Shroff discusses how to avoid building features or products that replicate what’s already in the market but, instead, truly stand out.
Impact mapping is a lightweight, collaborative planning technique for teams that want to make a big impact with software products.
A product evangelist educates the broader audience on what the product is about and how to get the most out of it.
Learn more →
One Reply to "Leader Spotlight: Structuring teams around OKRs, with Ghazal Badiozamani"
What are Ghazal Badiozamani’s thoughts on the implementation of AI in various industries, and how does she advocate for a customer-centric approach in its utilization? Regards, URL/a>