Leader Spotlight: Diving into details without micromanaging, with Noah Manger

Noah Manger is Director of Product Management at Zapier, a workflow automation software company. He started his career at The Bus Project (now Next Up Oregon), a nonpartisan nonprofit centered around youth leadership. From there, Noah transitioned into UX advocacy and development at PixelSpoke, a digital marketing agency, and later worked in product management, design, and development at 18F.

In our conversation, Noah discusses how he balances diving into the details with zooming out to see the broader product vision. He talks about his role as a coach and mentor to “give teams a running start,” support them on projects, and assist in prioritization efforts.

Zooming in at different levels

You began your career in development before moving to UX and, eventually, product management. How have all those career experiences influenced your leadership style?

I started building things like websites and features, and, at that time, I was doing every aspect of it — UX, development, and more. Ultimately, I learned from this initial stage of my career that I’m not the best designer or engineer, and I’m actually not interested in being either one, even though I enjoy dabbling! I realized that my superpower is bridging the gap between design and engineering and translating between the two functions.

As my career progressed, I got pulled into product management by virtue of being a good facilitator, especially since oftentimes, challenges arise when different functions work together.

I’m a big believer in the idea that you must think holistically about the experience and technology to figure out solutions for customer problems. If you focus on only one of those spaces, you’ll likely miss solutions that are right in front of you or problems that could be solved.

The real magic happens when you have design, engineering, and business all working together to find creative solutions to difficult problems. This concept influenced my approach to product management, and later my approach to leadership. I manage my team by encouraging them to do the same and grow to become highly effective cross-functional leaders.

One of the most important aspects of product management is the ability to dive deep in many areas. At the same time, it can be easy to drown in the details while you’re trying to keep initiatives moving forward. How do you manage that balance?

This is one of the hardest parts of the job. Something I’ve always been good at in my career, even before I worked in technology, was the ability to zoom in at different levels. As a PM, it’s really important to be able to dive into an individual user story acceptance criteria and then zoom out to the strategy for your part of the product. For me, it’s not just about going down to the story level, but understanding what the team is building and how it relates to where we’re going as an organization.

I find it important to live in the details because one of the key roles of a leader is to represent your team’s work upward and across the company. You have to be able to speak competently with executives and other leaders about the work your team is doing. Second, a big part of my role as a manager is to help my reports and support them in thinking through things. If you don’t know the details, it’s hard to give helpful advice or coaching.

Lastly, performance management is really important. Without knowing enough about the project details or results, it’s hard to know if someone’s doing a good job and supporting them, providing feedback, and helping them improve.

How do you ensure that in going into the details, you don’t accidentally fall into the trap of micromanagement?

It comes down to being strategic about when and how you zoom in. I have a vantage point by my place in the organization. I’m able to see a broader, longer-term view, and having that context is helpful. With that said, my main approach is to be as useful as I can be. I want to help people see around corners or draw connections between different things that might not seem obvious.

My goal is to give my reports a running start. For example, I’ll say, “Hey, there’s this new thing that we’re looking into. Let me give you all the context I have so that you don’t have to start from scratch.” Then, to avoid micromanaging, I need them to take ownership of it. It’s not enough for me to have all that context in my head or an idea for a solution — I need them to dig in and ultimately own it. At that point, they are ready to leave the nest but I’ll still touch base as the project moves along.

You mentioned giving your direct reports ownership. How do you instill that sense of empowerment in your team, especially since every PM works slightly differently?

It’s all about trust. For me to build trust with my reports, I have to get to the point where I see that they understand a topic as much as I do, if not more. Now, I can expect them to understand it even better than me moving forward. Other times, if they’re having trouble getting to the point, I’ll stay closer to them on that initiative. I want to make sure they understand the full scope of the problem or the different possible edge cases. Once we get to a point where we share the same base foundation, it’s easy for them to continue the project on their own.

---

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

Learn more →

---

Giving teams a running start

Going back to the communication piece, you talked about setting your team up for success by giving them a running start. What’s your process for staying in communication with them even after things are moving along?

One thing that helps me a lot is demos. My team and I talk a lot about the concept of showing your work. So, I keep an eye on the demos my team is shipping, look at them closely, and ask questions. In my position, ultimately, that is the best tool I have. Our teams also have different systems for weekly updates and project statuses.

Further, I get a lot of updates from my reports in our 1:1s. We spend a decent amount of time talking through whatever work we have going on and anything they might be struggling with. That weekly, high-bandwidth communication almost always gives me what I need.

How do you gauge if you are providing enough support to your direct reports?

There are a few ways. One is by asking directly, “Do you help? Are you feeling stuck? Do you need anything from me specifically?” I keep an eye on projects and mention if it seems like they’re taking longer than expected or not making as much progress as they should be. That could be anything from not seeing demos in a little while to the team spending a lot of time debating one or two aspects of it. I’ve developed a bit of a spidey sense of how things are going and use it as an opportunity to see if my team needs anything. Sometimes, they need guidance or leadership direction, while other times, they need a more tangible solution.

In general, as a leader, I’ve found that certain decisions can only be made at certain levels. I try to really pay attention to that. I view the process of moving up in an organization as a light beam spreading out. When you’re up top, the difference between point A and point B might seem pretty small and inconsequential. For example, given a choice between two things, there might be a possibility to do both. There isn’t a material difference, so it’s not a huge decision.

But, the further down you go, the farther points A and B get from each other. You need varying levels of leadership to bring a lens in and focus on these things. When you get to the ground level, there are often pretty material tensions that individual PMs need to reconcile. They’re sometimes trying to straddle or solve multiple problems. The PM’s job is to then come in and prioritize or help make those decisions.

Do you have an example of a decision that might be viewed differently depending on your vantage point in the organization?

Sure. At Zapier, our product is used by a wide range of customers for an array of use cases. We have highly non-technical users on one end and extremely technical ones on the other. That means that some people find our product very easy to use and others find it nearly impossible. As an individual PM, if you are trying to serve your customers in a constant push and pull between two very different types of users, that can be a really tough place to be. At my level, I can come in and say, “These folks are in a customer segment that we need to serve and these others are not.”

When you check in with your PMs to find out how everything’s going, do you find that their needs often fall into a certain category, like tools or stakeholder management?

It can vary by person. It can be anything from, “Hey, we need to update the scope of this project so that we can hit our deadline,” to tactical execution challenges. Oftentimes, a lot of the guidance I provide has to do with prioritization, so that’s a big theme in my role. Then, to a lesser extent, comes navigating team dynamics and troubleshooting issues as they relate to people. Lastly, my team sometimes comes to me asking for feedback on a specific project or initiative.

Prioritization and knowing your customers

You talked about providing guidance and support while letting your product managers have true ownership. Since we often learn from experiences that don’t go well, could you share an example of a time when being a little bit more hands-off wasn’t the right choice?

Totally. A few years ago, we had a project that originally started outside of my scope. But, after some organizational chance, I inherited it, even though I wasn’t closely involved in the project’s inception. It was a very technical project — we were rebuilding a core part of our infrastructure from the ground up.

There was a lot of thought from engineering around the right way to architect the project and how to build this the right way. We made progress for a long time, but we didn’t have anything tangible in our customers’ hands. This was an area where I definitely was hands-off, one because it started so far outside my knowledge base and two because it felt so technical. I deferred to engineering heavily. I didn’t have a great grasp of how to engage the necessary parts, so I was actually overly trusting.

Then, a previous engineering director I worked with raised a flag. She said, “Hey, this is not going well. This is not how this should be working.” We dug in and she drove the change to ultimately cancel it. I learned a lot from this experience. Even with a highly technical project, product needs to come in and bring that user focus and value perspective. Our job is to push engineering to find a way to deliver things incrementally, de-risk, and get value in the hands of customers.

Product plays a really important role here, especially in terms of challenging the approach taken. Challenge some of the assumptions and push to think differently about things. That was a big learning for me.

You mentioned that the main thing your product managers come to you for help with is prioritization. How do you coach them to think about that?

For me, the most fundamental foundation is knowing your customers. When you deeply understand your customers, everything else comes easier. I advise my team to talk directly with them and regularly to monitor all the different feedback channels. I also advocate for staying close to internal, customer-facing stakeholders, such as sales, support, and customer success. Prioritization can’t happen without a strong customer connection.

Especially for core product work, prioritization is an act of judgment. There isn’t a spreadsheet you can plug numbers into that tells you exactly what to build. However, you can still think rigorously about it. Also, when it comes to prioritization, it’s really important to think about sequencing. What is the first part that has to happen that unlocks everything else?

The top-down strategy is the other really important part. You need to know where the company is going and where you are trying to go as a product to know what to prioritize in the first place.

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.