In the 1989 song, ‘I Won’t Back Down,’ Tom Petty sings “and I'll keep this world from draggin' me down, gonna stand my ground, and I won't back down.”

For product managers, not only does this serve as a pump-up song, but it captures what it’s like to be on the battlefield of building and growing product teams - working hard to hit targets, dodging blockers and hurdles, keeping your team motivated, and ultimately executing the mission. No matter how difficult it may be, you gotta’ stand your ground.

Johnny Quach, seasoned product leader and quintessential Renaissance Man, knows a little something about not backing down from a challenge. Growing up in Los Angeles, Johnny started his career ingrained in the eclectic comic book scene, then doing a long stint in the fashion world during the heyday of Southern California’s streetwear culture.

After growing massive products at Unison and, he crossed the pond over to Berlin, where he did a tour of duty at Rocket Internet. At Rocket, Johnny helped build companies from the ground up, including fast growing ventures like Everdine, ZenRooms and Vendomo.

Now, when Johnny isn’t running ping pong tables through the greater Berlin area, he’s fully immersed in the world of air travel compensation, bringing happiness to air travelers around the globe as AirHelp’s Chief Product Officer.

In this installment of Software Development 2.0, we sat down with Johnny to get his take on building and scaling impact-driven product teams, making sure your team focuses on the results and why strong communication is the pillar of successful organizations.

When you first started at AirHelp as VP of Product (later transitioning into the CPO role), what did your process look like for tackling the product strategy?

For most product people, you only really have one main job, and that job is to find opportunities to create impact. In the case of joining AirHelp (this was 3 years post YC, and my team was all based in Gdańsk, Poland), the first order of business was to find opportunities. I started at the highest level, met with each individual executive on the team, and asked them: “How can I help you?.” Usually, when you start with this framing, they produce two things: first, they tell you all the opportunities they see and what they’re working on. Then, you can add those to your list of initial objectives you can focus on. Again, you’re generally looking for things that can have the biggest impact on the business and customers. Secondly, you allow each stakeholder to literally build you a roadmap to trust. If you support these things, not only will everyone be on the same side, but you start with a great collaboration and the goals are all aligned. You want to begin that relationship without any barriers and you also reduce the risk of having unproductive conversations later.

I then started to review the current roadmap, and asked “what are we working on and why are we working on it?.” I wanted to better understand the company strategy, and what we wanted to accomplish in a quantifiable way. For example, what our revenue looked like and how many users we had. Then, “how far are we from achieving this year’s goal, next year’s goal,” etc. You have to buy in and really understand those numbers, even if they’re simple numbers. Only when you really know the multipliers of growth each year, can you truly start to define what your roadmap looks like. Once you have that visibility, you want to define how much money you want to spend, and who you want to hire. It all really starts with understanding financially from a revenue point of view what you want to get to as a company, and that is the core driver of most decisions. Buy into the value, buy into the revenue, and then buy into the strategy. From there, you address the actual opportunities.

The most common mistake I see executives make, is that they start in a company and establish the ownership of the things they’re working on, to the entire team. It establishes silos and immediately draws lines. Everyone has the same goals, and we work together in different ways to get there. It’s all about building trust.

How did you take this trust building and collaboration across your different team hubs?

Once you’ve identified the opportunities, you start thinking and validating if these are real opportunities that will drive the biggest impact. From that, a strategy starts to solidify naturally, and you start to see commonalities from different conversations you’ve had within the team. Sometimes, you can even solve one problem and it alleviates issues that are popping up across departments.

When you put these opportunities into a bucket that forms the strategies, then you can start to figure out, “what needs to be done to make these things happen?.” It’s very easy after that, but in reality most people start with the tactical task, as opposed to starting with what business goals need to be achieved. The issue with that is projects or tasks start to look random across the company, and to the outside as well. The reason why it’s important to have a confident looking roadmap or strategy, is that you need to build a consensus around it to understand if they’re not unified in simple, high level statements. You’re just trying to compile all the opportunities, roll those into strategies and then you want to communicate those strategies.    

The tactics are more or less developed by the teams that are doing the execution. You’re just there to translate this constantly and see this into concrete things.

Once you have the strategies in place and initiatives start to form, what are some things that you put in place to make sure you’re on track, communicating that progress and making it all visible to the team?

For this, my general approach is to set up very frequent, but very short interactions. For example, there are weekly 1-on-1s with my direct reports. These are structured 1-on-1s where you’re constantly talking about the same order of things: goals, progress, strategy and feedback. When you’re constantly asking, “what’s the progress on x metric?,” it’s drilled into the person you’re talking to that they own this thing now and have that responsibility. It helps you instill accountability and ownership within the team.

With our executive team, I do the exact same thing. I have weekly 1-on-1s with all of them, for 15 minutes. We go through the quick checklist, and everyone is always on the same page. One of the common causes for communication breakdown is that you just stop talking. Sometimes I may not talk to an executive for two weeks, and it’s amazing what gets lost during that time. At the end of the day, these are small things that can be done and aren’t hard, but they make all the difference. Ownership is a side effect of the high frequency of me talking with someone.

With your distributed team setup, do you find that you have to over communicate?

It’s not so much about overcommunicating as much as it is me continuing to repeat things, which is funny because repetition is the mother of learning. In addition, I’m visiting our teams in Poland about 35% of the time each month. If you ask these teams, they all feel that I’m there all the time. You have to put in those hours of facetime, and be present for your team. There’s this funny study that says, after 10 meters of each other, your productivity with each other deteriorates by a large amount. Then, my goal is to sit next to everyone all the time!

Fortunately, with our CTO at AirHelp, we have great alignment from a business standpoint, and we’re constantly thinking about company revenue and other goals. “What is that we need to do to make these numbers happen?” We also try to mirror each others’ org structures to focus on the same topics.

Is there a translation of your top-line company goals to specific engineering team metrics?

I have different perspectives on this, and my most radical perspective is that you don’t have engineering goals or you don’t have product management goals. You only have organization/company level goals, revenue being an example. The general idea is that we don’t care what your job title is, or what your day-to-day is, we just care if your team can make this number go from A to B. What happens there is you exclude conversations about activity, and you only talk about results. When you are results-driven, you’re not focused on the day-to-day how to do things, which puts the team in a completely different mindset. A person could work weekends, and work to 10pm everyday, without any results happening. And on the flipside, if a person doesn’t work that much, but delivers results, it’s recognized as a great job. In reality, what more do you need as a company except for results to happen. That is an example of what would happen in a vacuum, in an ideal world.

However, in reality, people have personal career goals and interests, which means not every engineer, product manager or designer cares about revenue goals. That’s where you want to spend your time, building a company culture where it’s clear that this is the direction the company wants to go toward. If you’re hiring people, you’re filtering them through that cultural fit. For some percentage, we need to compromise and ask people what they want to grow into - maybe they want to learn new programming languages, new skill sets, etc. Then you have to give that career path allocation time as well.

In some ways, it can feel unfair to a designer or engineer, who crushed the part they’re supposed to do, but the business results are not great. And that’s the sentiment you need to get rid of in your company, that “I did a good job.” That’s irrelevant, because it’s all bigger than one person. That’s being a part of a team. Then you start realizing, “it doesn’t matter what I do, it only matters if we hit this goal.” Then you start thinking, “what are the best things that I should be doing to make this happen.” That mindset is hard to train, and it’s very awkward. But, I think this is the easiest way to reduce drama when discussing these opportunities.

From an engineer’s or designer’s perspective, it can be incredibly rewarding to go from idea phase to the post release phase, and seeing the tangible results of the business metrics moving forward.

Yes, it’s incredibly satisfying. Winning is also incredibly addicting, and most companies don’t spend enough time explaining what winning is to people. When wins do happen, people don’t share that celebration, and when losses happen, some people don’t share that as well. If you’re constantly saying, “this business goal is the key to our success,” it’s great to go to an engineer and tell her, “what you worked on led to an increase in 10%, and that’s worth millions of euros.” Hearing that statement as an engineer (who can sometimes be detached from that), is not something you hear very often. You want to hear this 10% increase led to certain business goals. Nice things will also happen when you hear engineers come with suggestions, around things like saving money, or increasing revenue. That’s the thinking you want to get to.

If you do come across any issues or project delays, how do you address and surface them to the team?

Usually delays are not such a problem, but it’s more around the impact that you’re losing from that delay. For us, how we communicate it is usually through an email and give the reasons for a certain delay, and take the next steps to plan ahead for it the next time. However, showing the effort that you’re taking the time to plan for a delay that could happen in the future is the key.

Communicating to a large group is difficult in itself - we have Slack channels, emails, and I’ll also have a weekly management call to go through the reasons for the delays.

Most of our delays are usually a few weeks, and not usually months, which isn’t the end of the world. Also, as a product manager or engineering manager, you need to clearly communicate the loss for not delivering a certain project. If you don’t quantify a delay, people will balloon that problem exponentially.

Usually our common delays are around code complexity, inaccurate human estimations, dependencies on other departments. The more dependencies you have, the slower things become. As a leader, one of the main goals is trying to reduce dependencies as much as you can, especially when you scale teams.

I remember speaking with the VP of Engineering from Spotify, and he said that one of the things that people don’t realize about Spotify is that 33% of their entire engineering budget is spent on engineering infrastructure. The main point is, you need to make that investment to help teams move faster as they grow.

In Software Development 2.0, experts in the field of software development share their insights and best practices with the community.

Interested in sharing your experiences? Give us a shout at

Ready to reduce your schedule slippages?

Sign up for free. Get started in minutes.

Get a free trial

We're on a mission to help engineering teams eliminate project delays and be more responsive to their customers.

©Kiro 2020. All rights reserved.

Get development best practices

Cheers! Thanks for joining the community!
Pop in a valid email address.