Leader Spotlight: Innovating before you think you need to, with Leo Gong

---

Leo Gong is VP of Product at Apartment List. He has been working in product management for more than a decade and began his first PM role at Dropbox before becoming a founding PM at EverString, a B2B data company. Most recently, Leo led the B2B product at Evernote before transitioning to Apartment List five years ago. Earlier in his career, he founded a social network startup, Heyawanna Labs, to connect people with shared interests.

In our conversation, Leo talks about the importance of knowing when to plant a new seed in the business to expand growth opportunities — a challenge many companies face because “the moment you need to do that is usually before you think you need to.” He discusses the difficult balance of being critical of the product in the validation phase while also maintaining an optimistic mentality to make it work. Leo also shares advice on when to stay zeroed in on the product’s existing market versus when to expand to new markets and opportunities.

---

A shift to the strategic PM role

From your vantage point, given your extensive experience in product, how has the role of the product manager evolved and where do you think it’s going?

One thing I’ve noticed is that within teams, PMs are progressively moving out of the execution layer of R&D. Many PMs were primarily scrum masters first and foremost, and product managers second. There were also very technical PMs who wrote incredibly specific tech specs. At smaller companies, these roles, like the scrum master role, have shifted to within the team so they can do a round-robin style rotation. The spec-ing has also shifted into the engineering team for it to be managed there. In larger companies, you have these specialized roles that get created — whether it be like a specialized scrum master or like a PMO organization.

The specialization of roles is something we actually went through at Apartment List. When I initially joined, PMs were running story point meetings and doing sprint planning. We would ask them, “When are we getting a delivery? What’s the team velocity?” That no longer happens. We hired a scrum master and eventually folded that role into a broader program management organization. At this point, PMs are working on providing the “why” and the outcomes we’re trying to drive. That’s more of the typical product manager that you see now.

In the future, you might see PMs go further up the chain toward more team leadership or maybe product marketing. I’m starting to see a little bit of that here. That’s the next transition I’m trying to get my team to make — beyond ensuring that everybody understands what we’re trying to drive in terms of outcomes to actually setting the right tone and culture of collaboration within the team. It’s also important to demonstrate how to build a high-performing team. I view PMs more like the leaders of the team, and most of them aren’t used to that. They think of themselves as execution or strategy supporters as opposed to leaders.

What advice do you have for PMs who are in a more tactical role now to help them become ready for that heavier strategy lift?

I feel like that shift in mindset can be quite difficult because the way we look at a product is fundamentally different. Recently, I’ve been interviewing PMs for some open roles and I can tell what their mindset is just by how they answer the same question. I like to ask, “Pick a product that you really like using. If you were to assess it as a product manager, what rating would you give it?” If they focus more on features or bugs, or if they focus more on what the company strategy is and how the product fits within it, that gives me a sense of which stage of the progression they’re at.

If you’re, let’s say, in the more executional mindset, how do you shift that? I think exposing yourself to the other type of thinking is probably the best way to do it. Find a PM in your organization who exhibits that behavior and spend time with them. Do product breakdowns together. We do team sessions where we look at each other’s work and give feedback. That’s a really good way to learn. There are also a lot of good resources on YouTube where people talk about how to be a good PM or even provide interview practice questions. Interview practice is almost like an on-steroids way to learn core PM skills in a limited fashion.

Sometimes a PM is more strategic, but tactically, the team may not ship as quickly as they would like. Do you have any advice for that scenario?

Every team goes in and out of sync occasionally. I think it really depends on why — why is the team not delivering? There’s a bunch of different reasons. It could be because you’ve got the wrong skill sets. That’s not a PM issue. It could be because the team is not being managed, motivated, held accountable, or being given the right goals and coaching. That’s also not a PM issue.

But, if the team doesn’t know what their goal is, or they know what the goal is but don’t think it makes sense so they’re not bought into it, then that probably is a PM issue. The team may also feel like they don’t have the appropriate amount of autonomy to actually come up with the best solution. That leads to motivation and execution issues. It really depends, but it usually involves the PM working with leaders on their team to set the right level of collaboration and engagement.

Balancing criticism and optimism

Could you take us through your playbook for launching products — starting with how you craft a POC and then what the alpha, beta, and GA would look like?

I took a bunch of products to launch at Evernote, my Series A machine learning startup, and also here at Apartment List. There’s a common pattern. What I typically notice is that for POCs, you want to start with the end user pain point. Usually, it doesn’t work well when you start with a business problem. What really matters is that the grounding thing has to be an underlying pain point, and then there’s some kind of a trigger or unique insight where you feel like this problem is now solvable or worth solving.

It could be that some new technology came in or that you’ve built an integration that no one else has access to that enables you to solve a problem in a new or unique way. Maybe you’re pioneering a brand new monetization model that makes it worthwhile to actually solve this as a problem. The equilibrium of something not being solved has now been disrupted. What I try to do with the POC is to then get the team really clear and laser-focused on two hypotheses that we feel are enabled by the new trigger: that our solution will solve the user’s problem, and that the solution will lead to a meaningful business impact.

The POC and the alpha to me are sort of a similar phase in terms of the validation you’re seeking, i.e., does it solve the problem and is it impactful to the business? The main difference is the fidelity — the POC is just a couple of mockups that you’ll take and validate, and the alpha is a working prototype that isn’t just a mockup.

You move to beta when you’re confident that if you implement the alpha solution, you’ll solve the user’s problem and make a meaningful business impact, but you aren’t sure if you can do that scalably. Beta is spent figuring out how your product works at scale and with the right unit economics. There are some common, but not exhaustive, questions to answer in the beta phase. Can the product stay performant? If we need an operations team, how would they operate? Can we support the product with sustainable economics? You’re ready for GA when you’ve checked those questions off in beta.

Do you have any examples of lessons you’ve learned in launching products?

One mistake I made at Apartment List was in the launch of a new product called LIFT. It allowed properties to participate in an auction where the more they bid, the more exposure and the more leases they got from our platform. We did a POC phase, and one key learning for me was that the mentality that you go through in validation is really important. It was the CEO’s idea, and when we on the product team were given the job of validating it, we were not fully bought in. We were looking for reasons why it wouldn’t work.

We’d say, “There’s this problem and this problem, so this isn’t going to work out.” The co-founder sat down with me and said, “There are 10 million different reasons why it won’t work. I need you to figure out the reasons why this could work.” That was a really helpful jolt to the system. It’s a difficult balance because when you’re in the validation phase, you want to be super critical in the sense that you’re looking for all the likely reasons this thing will fail. But your mentality going in has to be, “We think we can make it work.” You need to hold both things true in your head at the same time, and they have to go in these two opposite directions.

Knowing when to plant a new seed

What do you look for in the alpha to say there’s enough good to continue the project?

Alpha is about solving a user problem while believing that it has business impact. The signal in alpha is that there’s potential, and this signal is usually obtained in a non-scalable way. For example, if your idea is to build a responsive AI assistant for five concurrent users at the same time, you need to look at business signals like, “It’s definitely not profitable, but if you believe these numbers scale in these ways, we could probably make it work.”

We did that at Apartment List. As a business, we focus on long-term rentals, but we ran a POC on short-term rentals. The idea was that someone could come in, look for an apartment, and sign a one-month lease. Apartment List would furnish it fully, so it would essentially be a white glove concierge service.

For our alpha, we were looking at whether our renters were actually interested enough to go and purchase, as well as what the financials were. That meant putting a small-scale test in front of renters to figure out what the cost and revenue drivers really were, and what unit economics we’d need to achieve at scale for this to be worth investing in. If we arrived at believable target numbers, we’d then move into beta and then work on validating that we could hit those targets.

In our case, we decided to cut the short-term rental idea at alpha after we looked at the numbers. We found out a lot more about those main drivers than we did prior to moving some renters into these short-term units, like some operational difficulties that we never would’ve thought of otherwise. It wasn’t going to work at scale, so we decided to kill the idea while it was still young.

How do you balance launching big initiatives against iterative changes?

I hate to give this answer, but it really depends on what stage of maturity your product is in. Post launch, it’s important to focus on iterating and supporting the seedling that’s sprouting. This is where you whittle a shape down into a sculpture. Then, at some point later, you need to realize, “Let’s divert some attention from what’s now on a tree. We need to carve out some time to plant a new seed and do something new at the same time and balance it.” This is when it’s really difficult for businesses. It’s a difficult conversation to have because the moment you need to do that is usually before you even think that you need to.

I work with a lot of non-R&D folks who say, “Well, the metrics are going great. The growth is fantastic.” At that point, we may not have fully penetrated the market yet. I think it takes a certain amount of willingness to deviate from the numbers because, by the time growth starts declining, it’s too late. You want to be ahead of that curve, depending on your product, by a year or more.

So do you think most people don’t invest in the second or third product soon enough, but should do that sooner? They need to find the next thing that can grow a lot and have it ready before running out of juice on the first product?

Yeah. Apple’s a really interesting example because the Apple Vision Pro just came out. They started working on that years ago, likely in the peak of iPhone growth. So it’s a really good example of a company that’s working on the next initiative before they think that they need to. They do this for iPhones as well. Their development is always very ahead of where the business is at.

I think in hardware, it’s actually easier to stay ahead of the curve. You can physically look at a car and recognize that it looks dated. Perhaps the technology within it is dated. These things make it pretty clear that you need to launch a new model. With software, however, it can be really hard to see that. You’re making tweaks all the time, so it might be easy to deceive yourself into thinking that you don’t need to do a proper relaunch. In fact, I would say that’s a con of the whole SaaS model.

In the past, when you had Windows, it was not like a SaaS product. It was not live on the internet, so there needed to be a different version of Windows that came out every year. Nowadays, you don’t have that. I think it can be a little bit more difficult for folks to see that you might actually need to do a bit of a product relaunch.

Staying focused on the core segment

The Apartment List marketplace is made up of renters and rentees. How does the marketplace model influence how you think about developing new products?

When someone thinks about our marketplaces, the first question is usually, “Are you just based in the US?” There’s a simple geographical expansion, but even within the US, the housing market for rentals is split roughly into thirds. The first third is large apartment buildings with 200 plus units that come with a pool, front desk, concierge, etc. That’s where we’re really strong — our name probably gives that away. The middle third is the 50-plus-unit buildings, and then the last third is the small mom-and-pops, like people renting out their second home. For us, we have to figure out at what point we should stay focused on building a really strong, competitive product in our core segment and at what point we should start thinking about building out new shoots of growth in the other two segments.

What’s the calculus for when you should invest in those new segments vs. doubling down on your core segment?

I’ll give an example. My favorite company in terms of how they did this is Amazon. They started off as a bookstore and later scaled into all types of things that they now sell. At this point, they don’t just sell products, they sell books, e-books, movies, and even cloud services. We talked about that ebb and flow of, when you launch into that very first market, the ramp-up period feeling like there are many obvious things that you need to fix.

At that point, after a new product launch, you should still be 100 percent focused on that existing market until you get it to where it needs to be. Once you start approaching the point where you’re optimizing and making the product more efficient, but you’re no longer missing must-haves, it’s worth carving out a set of efforts and teams to expand the technology that you’ve developed into these other platforms. The companies that do this well, like Amazon or even Rippling, think about this very intentionally.

Their approach is, “We are going to build some core fundamental building blocks as we build out this new market, and we intend to reuse those building blocks to then enter the next market.” This is why you see Amazon treating warehousing, logistics, and cloud hosting as a fundamental capability that they can even sell to other people. That’s a winning strategy because if you don’t do that, that second segment feels like the same amount of work as starting the first. You don’t want that to be the case.

The customer’s word as ‘diamond-clad truth’

What’s your process for incorporating customer feedback into your product lifecycle?

I think it depends on if we’re talking about a mature product or a new product. A mature product can use feedback mechanisms embedded on the site. You can read your emails, read your reviews, and look at the metrics on how users are converting. With new features or new products, it’s a bit more interesting. You have a couple of things at your disposal, whether it be mockups, user interviews, prototypes, or user testing. The trick here is to figure out when you use which method or if you use it at all. I’ve done the whole gamut. I’ve knocked on people’s car windows to ask them a question. I think that’s where that balance and tricky part comes in.

How do you balance that customer input with your own product vision?

I always 100 percent believe the customer in terms of whether or not something is painful. I never overrule them on that. That’s the thing where I take their word to be a diamond-clad truth. I also completely rely on them to tell me when my solution solves their problem. For everything in between, I will heavily read between the lines in what they tell me about how something may solve their problem. Then, I ultimately decide whether or not I want to solve that problem for that particular user.

Ambiguity: Embrace it, name it, bring it

In product, there’s a lot of ambiguity. How do you navigate that when you’re making key decisions? And how do you help your team members, especially those maybe who have less experience in product, get comfortable with that?

This is really very difficult and it’s something that we’re working through as well. I’ve made a lot of mistakes in this over the years, but I’ve found that the best way to deal with ambiguity is to embrace it, to name it, and to bring it to the team.

What I used to do, and what I see more junior PMs do, is try to deal with ambiguity by bringing their own answers to it. They try to shield the teams from ambiguity and say, “You don’t need to worry about it. I’ll tell you what we need to do, what we need to solve for, so just go build it.”

That doesn’t work well because chances are, you’re wrong, and when you’re wrong, your team will lose belief. You’ve also missed out on very rich ideas and perspectives. Nowadays, I bring ambiguity to the team by saying, “These are the things we don’t know. I’m going to plant some stakes in the sand. Here’s what some of my assumptions are and what I believe are the solutions.” Then the team picks it apart.

It is extremely uncomfortable for me to have that conversation, but the team loves it and I have about a 50 percent hit rate — half the time I’m wrong, and half the time they say, “OK, that makes sense.” When I’ve done that versus the other approach, the level of engagement and enthusiasm from the team are factors of magnitude different.

Hiring for potential

You mentioned that you’re hiring right now. What’s your approach for structuring your teams and are there specific attributes that you look for when hiring?

I try to balance these skills that we bring in, but I think it’s more important that I have a really solid understanding of what that specific team needs. Then, I’ll hire for that team specifically. Some teams need someone who’s more technical, some need someone who’s more comfortable with new products, and others may need someone who’s very comfortable with B2B sales. I try to stack teams that way — based on what the need is.

A big part of what I look for is if the candidate has the raw capabilities. Do they have the raw potential to grow and, during onboarding, do they have the potential to get to where we need them to be? The other piece is if they have the right mindset to be able to get there. I look for if they’re humble, hungry, and overall good, low-ego people to work with.