Q&A with J Crowley, Head of Product at Airbnb Lux, on what makes a great PM

The role of Product Manager can mean very different things at various companies. Should a product manager be technical? Scientific? Opinionated?

J Crowley has run product at three big-name companies. At Foursquare, he led the rebuild of Swarm after a rocky initial launch and eventually became Head of Product. He then moved on to Blue Apron as Head of Product, overseeing growth and monetization. This was right before Blue Apron went public, which ushered in a turbulent time for the company but one that yielded a wealth of life lessons for Crowley.

Now, he serves as Head of Product for Airbnb Lux.

I hopped on the phone with J to talk about what makes a great product manager, some of the lessons he’s learned, and how he’s made difficult decisions and communicated that to his team.

Editor’s Note: This interview has been edited for length and clarity.

Jordan: How did you get into the tech world in the first place? You used to work in TV, right?

J Crowley: I worked in the television industry for about 10 years. Many years at NBC for a bunch of different departments. Started in the Page Program, and worked on everything from late night comedy, to sports, news, election coverage, digital programming.

I ended up leaving NBC to start my own company, which was a small digital studio here in New York City. We made hundreds of digital shorts and web series. It was probably the most challenging, but most fun three years of my career.

I eventually packed it up to join Foursquare as their Director of Business Development in 2010. There, I helped them grow their brand by securing hundreds of media partnerships with major publishers, sports leagues, TV networks, musicians, etc. That was actually my first job in tech. It wasn’t a product role. It was business development.

Jordan: And what was it like working with your brother, Dennis, at Foursquare? I’m sure there were a bunch of really good things about it and I’m sure there were some frustrating things about it.

J Crowley: It’s complicated. I’ll start by pointing out that my brother and I had an agreement before I decided to join Foursquare that I would never report to him directly. If we ever thought that it was affecting our personal relationship, I would just leave the company. And that was the agreement we had. I worked at Foursquare for a total of six years, and I never reported to Dennis, even when I was Head of Product in my final year.

As you can imagine, there are benefits and challenges to working with a sibling. The main benefit was a level of predictability. You know who you’re talking to. You know what they care about. You know the things that are going to excite them and frustrate them. So it allows you to move quickly. Being brothers allowed us to have a tremendous amount of transparency and honesty when working together and making decisions. That was great.

One of the biggest challenges was how instinctual it was to treat each other like brothers. You can’t really do that in a professional setting. The way you debate with the CEO is very different when that CEO is your brother. When he and I were in a room, just one on one, those were not the most professional conversations. Productive and to the point, yes. Professional, not so much. But the moment somebody else was in that room, we had to change our tone. At times it felt like I was acting, or I had a switch that I would turn on and off.

Jordan: As you said, at Foursquare, you didn’t start out in a product role. You moved from BizDev to Product. How did that happen?

JC: I worked for three years in that Business Development role managing a small but awesome team, and I really enjoyed what I was doing. But then I had this terrible feeling that I wasn’t learning anymore. I wasn’t being challenged, and I needed something new. I also missed being a creator. Remember, I worked in television for 10 years and I consider myself a storyteller. I love building things that make people feel something or bring people joy. And I wasn’t doing that in my current bizdev role. So, after about three years, I decided to leave the company and move to Portland, where my wife was offered a job.

When I tried resigning from the company, they came back and offered me a role as a product manager. It’s not very often that someone gets an opportunity to be a PM at a company as well known as Foursquare. Especially someone like me, not having that technical background, not having a CS degree, and having never worked in product before. It was tough decision that my wife and I made together. We decided to stay in New York, and I ended up transitioning from a Director of Business Development down to a PM. And that was right around the time that they had made the decision to split Foursquare into two apps. And my first job was to be one of the many PMs working on the new Foursquare.

Jordan: So it wasn’t actually a lateral move. You took a step down to be a product manager.

JC: I don’t really think about titles that much but I can say it was lateral at best. The biggest change was going from managing a team to managing a product as an individual contributor.

Lessons from the success and failure of Swarm

Jordan: And eventually you moved from Foursquare, a product with existing users, to work on Swarm, which was essentially a brand new product. When you don’t have users to inform the product, how do you start from scratch as a product manager?

JC: They’re completely different challenges. When you’re starting from scratch, you’re quite blind. You have no first-hand data. You don’t know your users. You don’t know what they want, or what they don’t want. You’re speculating how they’re going to use a product — and it’s often different than what you originally thought! There’s little to no user base to experiment and learn. You need to rely on a tremendous amount of research, consumer trends, user behavior, look at what’s worked in the past and what hasn’t. You need to rely on your product instincts. There’s a big first leap of faith you need to take, but hopefully you’re armed with some research to help validate your assumptions.

Jordan: Speaking of moving from Foursquare to Swarm, the first version of Swarm was very different from the check-in experience we had on the old Foursquare. It was more of a social utility app to figure out what your friends were doing and if you wanted to join in with them. And then you quickly realized that that wasn’t the play. How did you formulate your original hypothesis around Swarm as a social utility, and what happened when you realized that hypothesis didn’t pan out?

JC: Being pretty candid, I think that the original hypothesis to have an app that was focused on social utility was flawed. I don’t believe that it was grounded in enough user research. There were a lot of decisions that were being made internally, based off how employees used the product. But we’re not even close to representative of the real population. I can talk about some of the challenges of building a social utility if you’d like?

Jordan: Yeah, please do.

JC: In short, software as a social utility is meant to help people meet up in the real world. But that was really, really hard to pull off. One of the many reasons was because the average active user had less than ten active friends using the platform. So if you think about that, the stars really need to align for a social utility to deliver value and help people meet up in the real world.

Think about all the barriers to success. You had small, intimate social graphs by design (because it’s real-time location sharing). Then friends needed to be close enough where they can actually meet up. Then they need to open their phones to discover the other person was nearby (or have push notifications enabled). They needed to have the time to meet up, and the actual interest in meeting up with that person.

The idea of software bringing people together and creating that serendipitous moment sounds magical, but it was much more rare than we would have liked.

Jordan: So when you find yourself in that position and you realize you need to rethink the app, how do you decide what the next path is? And how do you communicate that to your team?

JC: Once we actually launched Swarm, it was very easy to identify the missteps by analyzing usage data and reading all the feedback.

We pissed a lot of people off. We read almost every single ticket that came into our customer support team. God bless that team. They had the hardest job in the entire company because they were just fielding emotionally charged emails every day. It must have been draining for them. People don’t like change in general, but when you take away features they have a deep emotional connection to, like badges they’ve earned, you’re going to get a strong reaction. On top of that, a lot of people felt strongly they wanted one app to do everything. Not two.

I wouldn’t be able to accurately represent the amount of feedback that we got from users. So, it was quite easy for us to understand where we needed to spend our time and resources. But we didn’t want to just go and rebuild the old product because that wasn’t perfect either. So we focused a lot on the overall themes of the feedback, identified what users cared most about, and then planned to move quickly to build a better product than before.

Product leadership and using autonomy as motivation

Jordan: That must be tough, though. It just seems like a product team and engineers and designers have spent so much time and energy building this thing. And when the launch doesn’t go right, it seems like it would be such an emotional and mental blow. So, as a leader, how do you rally the troops after something like that?

JC: It’s not easy. When I came in to lead product for Swarm, I distinctly remember having that first meeting where we all got in a conference room and I acknowledged that the last year was probably really, really hard for them. I couldn’t imagine how they were feeling after that crazy sprint, and then seeing those metrics and feedback.

I did a lot of listening. I asked how they felt. I asked if they believed in the original theory. And I did my best to try to convince them to take one more shot at this. Let’s build a product that we would be proud to say that we built. Let’s build something for our users. Let’s make our users happy again.

One of the agreements that I had before I started running Swarm was that we were able to operate with complete autonomy … like an internal incubator. We didn’t have to go through the normal product development processes that were in place. We could set our own course and determine our own fate. And the reason I was able to negotiate that with leadership was because they knew how challenging it would be to get those designers and engineers to work on Swarm again. They understood autonomy was a key driver in getting people excited about working on this.

When I told the team we had the autonomy to build the product we wanted, you could see their energy and enthusiasm change. It wasn’t something that I or anybody could convince them of overnight. It really took time. It was important to identify some guiding principles for how we were doing to work together. And one of the key things we did was to identify what we were not going to do. We identified those previous mistakes and pledged to not repeat them. People started to have a bit more faith in the future and how we were going to operate as a team.

Jordan: I’m curious to learn more about this idea of an internal lab or incubator. How did you negotiate that and what did that actually look like?

JC: When I was asked to lead the rebuild of Swarm, I wasn’t super excited about the opportunity because I didn’t want to relive the previous mistakes that happened in the past. And we needed to drastically shake things up. So I sat down with leadership and said “I will do this. I will work with the team, but these are going to be the stipulations.” And that’s where I asked for full autonomy. It was just a conversation that we agreed to. There wasn’t much to debate. We were in a tough situation. They took a very, very loyal and dedicated user base and managed to significantly disrupt the way people used the product and the metrics. And so, they were open to the idea of changing the way the product was going to be built.

So we did not have to go through the normal product development processes that other products and other PMs did. Steps like working with leadership, design and copy reviews, and getting buy-in on decisions — it just didn’t happen. Whatever decision we wanted to make, we made it. I’d stay up late at night writing ridiculous app copy with another PM. If we made each other laugh, we’d just ship it. We just built the product. We’d keep leadership updated of what we were doing. But it was never “Can we get approval?” It was whatever we wanted to do, we could build it. And the team flew. It’s amazing how fast you can build products when you have a team of people who are energized and you remove all hurdles.

From Swarm to Blue Apron, and being transparent during hard times

Jordan: Let’s shift away from Swarm for a minute and talk a little bit about Blue Apron. You left Foursquare to go to Blue Apron in 2017?

JC: In the fall of 2016.

Jordan: Right. And during your tenure there, Blue Apron went public and I think it’s fair to say that it was a rocky time for the company, and potentially, continues to be. At Swarm, the issue was about getting people excited to rebuild a product that users didn’t want. In the Blue Apron scenario, the distraction was more around corporate chaos. These employees are seeing their equity dwindle before their eyes. It’s a different type of distraction or mental fatigue. So how do you keep your team focused on building a product that delights users in the midst of corporate chaos?

JC: Ummm…. It’s not easy. Working for a public company that experienced what Blue Apron did was very unique. The best way to motivate a team through times like that is to keep them focused on the mission. Why did they join that company? Because even though the company might be struggling, the mission doesn’t change.

I’d get them to focus on the greater good and the purpose for why they come to work every day. I’d remind them of the impact they’re having, not on the company, but on people. Blue Apron has an incredible mission statement. “Make incredible home cooking accessible to everyone.” We were teaching people how to cook. How to eat healthier than takeout. We brought families together around a table. That’s something that can get people to focus through pretty challenging times.

But focusing on the mission isn’t enough by itself. You need to acknowledge the challenges. I think really great leaders don’t shy away from hard conversations. I think they acknowledge that ‘yeah, this is a really hard time right now.’ If you’re willing to be real with someone and let them see the things that you’re concerned about or afraid of too, it really just helps people connect. It helps teams trust each other — to know we’re all in this together.

Jordan: Was there ever a time, at any of these companies, where there was a decision made by leadership that was passed down that maybe wasn’t popular with you, or not popular with your team? And how do you deal with transparency in that regard, both up and downstream, and keep people excited about building something they haven’t bought into?

JC: The best advice is to be transparent and authentic about how you feel. You have to tell leadership that you disagree with them, and if you’re not able to persuade, then disagree and commit. I would always tell my team if I disagreed with leadership, but would try to represent their point of view as best I could. But that doesn’t always work. Whenever possible I’d have my team meet directly with leadership so they could ask those hard questions firsthand. That’s way better than me playing the role of the messenger. When they’re able to hear it firsthand, from leadership, and they’re able to ask questions and challenge, it gives them a better perspective on why certain decisions are being made. Nobody likes decisions that are made behind the curtain.

Jordan: Yeah, even if it doesn’t win them over, at least they had the opportunity to kind of see things as they are. Like, ‘here’s your perspective, here’s my perspective, we had it out, and this is the way things are going to be.’ That seems like it’s easier to accept.

JC: Exactly. Any good product manager should be able to accept that and move on, because the role of product manager is to build consensus, every single day, across different levels and departments. There are trade-offs being made all the time, so it shouldn’t be foreign to them. But ultimately, it’s very difficult when it is a big decision that’s going to impact a long-term strategy. And the best thing you can do is just give them exposure to the people that are making that decision.

What does it take to be a PM?

Jordan: Okay, this is a good time to talk more broadly about what it means to be a product manager. Are there any characteristics or traits that you think a product manager absolutely must have. And are there any that a product manager shouldn’t have?

JC: Empathy. Empathy for customers and empathy for the people that you’re working with. Being an incredible listener. Going out there and meeting with people who use your product. Asking a ton of questions, and listening to how people talk about the product. Paying attention to what they get excited about, and what drives them crazy. Having insatiable curiosity and wanting to learn is really important, too.

And finally, I would say, being honest and able to build trust with your team. Being a product manager requires authenticity and humility. I think people do their best work when they know who they’re working with. The best teams I’ve ever seen work together are those that trust each other. They know what they’re good at and trust their teammates to fill in the gaps.

So, to answer your second question, the traits a product manager shouldn’t have … I think that product managers sometimes think it’s their responsibility to come up with all the solutions and make all the decisions. Those PMs typically struggle. Great product managers know their own skills, but they also know what they’re not great at. They can trust the people around, who are experts in what they do, to help make decisions.

Jordan: It seems like a difficult balancing act, because on one hand, a product manager really needs to have, like you said, a lot of empathy and humility to listen and learn from the people around them. But at the same time, a PM is an advocate for the customer and may have to challenge leadership and have a lot of conviction in their belief system of what they think will and won’t work. How do you balance that empathy and humility with having conviction and standing up for the things you know to be right.

JC: Well, those things naturally go hand in hand. A good PM should be an advocate for the customer and their team. It often comes down to convincing leadership that you should stay long-term focused and always put the customer first. That can be challenging because leadership is often focused on the short-term pressures being applied to the business.

I remember one time when I was trying to convince leadership to make a difficult long-term decision that would have negative short-term implications on the business. I asked our Customer Support team to assemble a supercut of phone calls from angry customers. I played it for the CEO in front of about 15 people. I teed it up and said, ‘this is going to be really uncomfortable but you need to hear this.’ And it was, in fact, super uncomfortable. But the CEO was able to actually feel the pain and the emotion of these customers. It completely changed the tone of the conversation around why it was really, really important for us to make that tough decision.

Jordan: You’re not a technical product manager. Do you feel like that’s something that you’re missing? Do you think that a company needs a mix of both technical and non-technical product managers?

JC: Missing?

Jordan: Yeah. Do you wish you had more technical experience? Is that something you’ve tried to teach yourself?

JC: Early on, it was probably my biggest insecurity, that I did not have a technical background. But I quickly learned that I had a decision to make. I could either spend a tremendous amount of time trying to develop my weaknesses, in this case, a lack of technical experience. Or I could double down and focus on my existing strengths. So I decided to spend 80% of my focus on my strengths, and maybe 20% of my focus developing my weaknesses. But I was only doing that 20% percent, not to become a technical expert, but to be able to have conversations with engineers, to better understand tradeoffs… and not embarrass myself.

Jordan: Do you think that there is a trend toward non-technical product managers?

JC: I can’t really comment on overall trends. But I think the best teams are diverse. It really depends on the type of product manager you’re trying to hire. If you’re trying to hire a PM to lead a machine learning team, you clearly need a highly technical person. But if someone is coming in to build an engagement flywheel, that’s a completely different type of product manager. I’ve worked with both technical and non-technical PMs and they’ve both been great in their own ways. So I think it really just depends on the type of role that you’re trying to hire.

Jordan: So when you talk about that 20%, where you were getting to the point to be able to have these conversations, make decisions, and be fluent in the language that they’re speaking, how did you go about that specifically?

JC: I just asked a ton of questions without any reservation at all. I probably asked more questions than anybody else in the room, and I’m not afraid to do it. I’d spend a ton of time with my engineering partners on a whiteboard. Sometimes just asking them to map out our tech stack, or walk me through our data storage centers. I’d take photos of the whiteboard and keep notes and go back and try to study those notes. I’d be lying if I said I comprehended 100% of it, but I knew how much I needed to process.

I’ve been fortunate enough to have worked with incredibly patient and talented engineering managers who are great teachers, and really took the time to explain things. I’m super grateful for all the awesome partners I’ve had.

How do you hire a PM?

Jordan: What about hiring? You’ve been in a position now for a while to hire and I’m sure you’ve done a lot of it. What are you looking for? Is there anything to you that is immediately a sign of a good fit? And is there anything that’s an immediate red flag?

JC: In interviews, there are certain things I’m looking for. Do they obsess about the customer? How do they go about building products? A question I often ask in an interview is to walk me through their process for building a brand new feature. I’m looking for someone who talks about learning about the customer and collecting as much research and inputs as possible. I’m looking for someone who talks about their team. I have a concern if they start whiteboarding solutions.

In terms of the things that are red flags for me … I’m always watchful for people who don’t feel like team players, or people who are just looking to build their career. It’s pretty easy to pick up on that. I think advancing your career will come naturally if you are a team player, and you do great work. But sometimes I meet people who are more obsessed with building their careers than building great products.

What does the day look like for a PM?

Jordan: Tell me a bit about how you spend an average day. What do you do all day? Who do you talk to? What are the conversations like?

JC: There’s no such thing as an average day. It sounds so cliche but every day brings a new set of challenges. I think that the most challenging part of my job is the constant context switching. One moment I’m documenting a new process I want to introduce to the team. High-level thinking. Then I’ll be looking at funnel analysis. Then I’m talking about re-allocating resources from one team to another. And then I’m reviewing designs for a completely different part of the product. So, my days are pretty unpredictable. I try to spend about 20% of my week meeting with new people, and interviewing. I’m not going to lie, I’m definitely not hitting that 20% target right now, but it’s definitely a goal.

Jordan: When your day is like that… always changing and fluid, how do you introduce structure into that? Or do you even want to?

JC: It’s just different every day and I have to adapt. There’s very little time left at the end of the day, especially after I go home to be a husband and a father. I have almost no energy left, and the idea of going to my inbox is really, really challenging.

It’s hard to put structure to my days. I try to block off big chunks of time just to get stuff done. If I don’t do that, then my calendar will control me, versus me dictating my priorities. But I will say that I probably only have 10% of my week as ‘me time’ and that’s a problem.

I know certain companies do things like ‘no meeting Wednesdays.’ I think that’s a phenomenal idea. It’s not something that I’ve been able to stick to but something I hope that I can be disciplined enough in the future to actually do.

Jordan: What systems do you use to prioritize work and make those decisions?

JC: We’re actually heading into roadmapping season now. We do very simple impact and effort scoring so we can quickly bucket ideas into a “now, next, and later” format. ‘Now’ being the next three months, ‘next’ being four to six months from now, and ‘later’ being everything else. Once you actually have your impact and effort scoring, and projects in general buckets, then we work with data scientists and analysts to put some teeth behind these numbers to better validate the opportunity. We always try to have a diverse portfolio of short- and long-term projects. The percentage breakdown really depends on the stage and health of the company.

Jordan: And how do you measure results? Any systems or processes you favor?

JC: We have top line goals for 2019 and a broader mission statement. We try to ensure every single project on our roadmap ladders up into both. If you’re doing work that doesn’t, you should stop and ask ‘why are we doing this?’ Every single project we’re working on has unique target metric associated that relates to one of the broader goals.

Jordan: What software should a PM or leadership team use to store and communicate a roadmap?

JC: I’m sure there are great tools out there I haven’t used yet. But Google Sheets has worked well for us. I usually have one master Google Sheet with multiple tabs representing different teams or squads. I try to make our roadmaps visible and accessible, so anytime someone in the company is wondering what we’re working on, or why — they have access to that information. I also encourage my team to proactively send out email updates when they launch new products, and always link to the roadmap as a reminder of what’s to come.

I think the tools you use to roadmap are less important than the process. If you start with a very collaborative roadmapping process, people and teams will feel like they helped define the company’s future. And if they had input to the roadmap, they’re more likely to feel connected to it in the future.

Lessons from being a PM

Jordan: What is the most important lesson that you’ve learned about being a product manager at each of these different companies?

JC: Building products strictly off of instinct and not validating or invalidating your theories with research is very dangerous. And, the second thing … solely focusing on the short-term will not help you build a successful product or business. Way too often people focus on the short-term, and it takes a tremendous amount of discipline to not chase every fire, and to keep your eyes on a long-term horizon. You need to constantly be reminding yourself “This is where we need to go. This is what’s going to be a game changer for our customers and our business.’

Too often, I’ve seen teams only focus on the problems right in front of them. They’re focusing weeks out, not years. And before you know it, it’s two years later, and you haven’t built anything that’s transformative for your business or for your customer.

Jordan: What advice would you give to other product managers, and what advice would you give their bosses?

JC: The advice I’d give to people hiring product leaders is to know what profile and skills you want and know what you don’t want. When I was interviewing with some companies, I would ask CEOs what kind of product leaders they wanted to hire. That one they could usually answer. When I would ask them what kind of product person they’re not looking for, I’d get a lot of blank stares and silence. Identifying what you don’t need might be more important than what you do.

And, in terms of advice that I’d give to product managers, and I hope it’s helpful… well, really it’s general advice that I’d give to anybody. Know what you know, and admit what you don’t. Don’t be afraid to admit your shortcomings. Don’t fake it. Rely on the people around you who are experts in what they do. That’s how you build great teams. That’s how you build great products. So many people are afraid. I see it all the time. I can’t tell you how many times I’m in a meeting and I can tell people are lost. They’re just afraid to ask the question. They’re afraid of sounding stupid. And that comes at a great expense. Because so often, other people in the room have the same question.

And the last advice I would give… always make sure that you’re learning, you’re growing, and you’re having fun. And if you’re not doing any of those things, you really need to move on, and move on quickly.

Jordan: Ok, last question: You said earlier that it’s important to couple instinct with research and data to back it up. How do you stay aware of your own bias and keep your hypotheses scientific without abandoning instinct?

JC: There’s a process that I used at Foursquare and Blue Apron, and will soon be using here with my teams. It’s a process set up to ensure we have the right key decision makers in the room at the right times throughout various stages of the product development process – without slowing us down too much. From kickoff, all the way through launch.

It’s a series of check-ins to ensure we’re solving the right problems, building the right solutions, and have a strong go-to-market strategy. I’m never making a decision by myself in a vacuum. I always want to have design, engineering, analytics and research in the room. I’ll often look at everyone in the room and ask, ‘do you agree with this decision we’re making?’ or ‘is there a better way that we should be doing this?’ I try to encourage a group discussion. And if someone hasn’t said anything, I’ll often call them out and say, ‘you haven’t said anything. there’s clearly something on your mind, what are you thinking but not saying?’

I encourage Data and Research to keep us honest. Tell me right now if we are making the wrong decision, because I’d rather know now than find out two months from now. So I think it’s really about creating that environment where people feel comfortable to challenge and disagree.

But I also think it’s really important to be able to disagree and commit. I want everyone to be able to voice their opinion, but also have a structure in place where we can make decisions quickly. I never want to get trapped in this perpetual cycle of debating. Let’s have the hard discussions and move on. I want to spend more time building.