Lenny's Podcast: Product | Career | Growth - Driving alignment and urgency within teams, work-life balance, and the changing PM landscape | Nikita Miller (The Knot, Trello)

Episode Date: April 6, 2023

Brought to you by Wealthfront—Make smarter stock investments | Lenny’s Job Board—Hire the best product people. Find the best product gigs | Ahrefs—Improve your website’s SEO for free—Nikita Miller is a product leader, angel investor, and advisor. She has built and led product teams at companies ranging from early-stage startups to multinationals, and she is currently SVP of Product Management at The Knot Worldwide. Nikita is passionate about scaling product teams to support high-growth businesses and was a product leader at Trello and Atlassian for five years. In today’s podcast, we cover:• Lessons from building and growing Trello• Nikita’s roles and responsibilities framework• How the PM landscape is changing• Lessons about managing remote teams• Tactics for driving urgency within teams• Why working cross-culturally was such a formative experience—Find the transcript and references at: ⁠https://www.lennyspodcast.com/driving-alignment-and-urgency-within-teams-work-life-balance-and-the-changing-pm-landscape-nikita-miller-the-knot-trello/#transcript—Where to find Nikita Miller:• Twitter: https://twitter.com/nikitadyer• LinkedIn: https://www.linkedin.com/in/nikitadyer/—Where to find Lenny:• Newsletter: https://www.lennysnewsletter.com• Twitter: https://twitter.com/lennysan• LinkedIn: https://www.linkedin.com/in/lennyrachitsky/—In this episode, we cover:(00:00) Nikita’s background(03:56) How Nikita helped Trello develop enterprise features (09:41) Trello vs. Jira(10:28) Similarities and differences between building for users at The Knot vs. Trello(15:02) Pro tips for Trello users(15:41) Nikita’s roles and responsibilities framework(21:10) Why scrum masters are disappearing and what shifts are happening on teams(21:56) Why every team should have a data scientist embedded in it(23:27) The proper cadence for the rules and responsibilities framework, and problems around execution(25:27) Outcomes and output(28:34) The importance of urgency, and how to cultivate a sense of urgency(29:52) How to determine if your team is moving quickly enough(31:03) Prioritization between big bets and optimizations(31:29) Questions Nikita asks to understand her team’s speed (33:30) Changes in the field of product management(36:42) Advice for people who want to get into product(38:40) Why being a PM is hard, and thoughts on work-life balance(43:03) How to manage remote teams and how to do successful, short, in-person meetups(47:59) The importance of having overlapping work hours and onboarding in person(49:09) The advantages of working in different cultures (52:58) The question Nikita finds most useful(55:07) Lightning round—Production and marketing by https://penname.co/. For inquiries about sponsoring the podcast, email [e-mail].—Disclosure: I am a Wealthfront client and I have received non-cash compensation for the testimonial in this episode. This is a public episode. If you'd like to discuss this with other subscribers or get access to bonus episodes, visit www.lennysnewsletter.com/subscribe

And many of the companies that I've either worked with or advised, coached over the past few years, it was all about outcomes. Like everyone was outcomes, outcomes, outcomes, outcomes, which is right. You want to make sure you're doing the right thing with the right goal, and that's fine. And some folks, you know, myself included at certain points, like swung way too far on the outcomes train and forgot that output is an indicator of that. So if you have a team that's doing all of the ideation and figuring out, you know, how to make decisions quickly and getting the right documentation and setting up the right product briefs and design briefs and experiment briefs, all the things that we know go into successful product

development, that's great. But if you're also not shipping a lot of things to market quickly enough, then it just doesn't matter that much. Welcome to Lenny's podcast where I interview world-class product leaders and growth experts. to learn from their hard-won experiences building and growing today's most successful products. Today, my guest is Nikita Miller. A huge thank you to Camille Ricketts for recommending Nikita and for connecting us. Nikita is Senior Vice President and Head of Product at the Not Worldwide. Before that, she was VP of Product at Dooley, and before that she was Head of Growth and Retention at Trello for over five years. In our conversation, we dig into how product managers

and people getting married are similar. A bunch of advice on getting into into product management, a really cool framework for how to align roles and responsibilities within your cross-functional teams, a bunch of advice for working effectively as a remote and distributed team, and the one question that Nikita asks constantly to get the most out of her teams. Nikita is amazing, and I am excited for you to learn from her. With that, I bring you Nikita Miller after a short word from our sponsors. This episode is brought to you by Wealthfronts. Anyone paying attention to the stock market over the past few years knows it's been a wild ride. Many people who made risky stock bets during the bull market are now facing big losses

and wondering how to make better informed investments going forward. That's why I'm excited to tell you about Wealthfront's new stock investing product, which is specifically designed to help you make better stock investments. It has all the features you'd expect, including fractional shares, zero commissions, and $1 minimum, but what sets it apart is a unique feature called stock collections. These are groups of stocks created by Wealthfront's investment team that are designed around unique investment opportunities. You can think of Wealthfront stock collections like Spotify Discovery Playlists, but instead of helping you find new songs, they help you discover new companies and themes to invest in.

For example, some popular collections right now are dividend-in-blue chip stocks, semiconductor leaders, and rising interest rates. And each collection includes a summary of the opportunity and trade-offs to help you make more intelligent investing decisions. To start investing with just $1, visit wealthfront.com slash Lenny. And note, I'm a wealthfront client, and they arrange for me to share this product with you. Important disclosures and details can be found in the show notes. Are you hiring? Or on the flip side, are you looking for a new opportunity? Well, either way, check out Lenny'sjobs.com slash talent.

If you're a hiring manager, you can sign up and get access to hundreds of hand-created people who are open to new opportunities. Thousands of people apply to join this collective, and I personally review and accept just about 10% of them. Don't find a better place to hire product managers and growth leaders. Join almost 100 other companies for actively hiring through this collective. And if you're looking around for a new opportunity, actively or passively, join the collective. It's free, you can be anonymous, and you can even hide yourself from specific companies. You can also leave any time, and you'll only hear from companies that you want to hear from. check out Lenny'sjobs.com slash talent.

Nikita, welcome to the podcast. Yeah, Lenny. Thank you. I'm excited to be here. I'm excited to have you. So I don't know if you know this, but I'm actually having a kid in a couple months and I've been doing a lot of reading as you do when you're going to be a parent. And I was reading a lot of stuff on the bump, which turns out I realized was something that it was in your umbrella products. And then a part of the not worldwide. Yeah.

Yeah. And then I realized you all have that for pregnancy. You have a site to help you with proposals. You have a site for obviously wedding planning and vendors and just party planning in general. And so is the general strategy to be there for every adulting milestone in life? Is that the plan? Yes. That's a nice way of putting it.

We talk about it as being there for the big celebrations in life. Like we have these celebratory moments that mark adulthood. And so to be part of that journey, we primarily focus in the wedding space, but yes, across the whole journey. It feels like the one, the two pieces you're missing are divorce and funerals. Is that the plan or do you want to stick to happy things? I think we're sticking to celebrations. I think we're leaning on. The world needs a lot more celebration right now.

So helping folks do that. You're here. Okay, cool. It's a really smart strategy. It makes a lot of sense. Like once you get someone, you know, with their wedding and then they kind of expand from there. And they're friends too. Hmm.

Interesting. Right. Because they register on the knot and they're like, oh, what's going on here. That's right. Your registration. Yeah. Genius. So we're going to talk about some of the things you've learned along your time there.

But I wanted to start with your previous gig at Atlassian and specifically leading growth and retention at Trello. Many people listening to this podcast either use Trello and love Trello or thinking about using Trello. And so it thought it'd be interesting to hear just like, who do you find Trello's most ideal for? When is it good and smart to go with Trello versus like Jira or Linearro? or sonner or something like that. A few things. So I think Trello initially started out as being the kind of task management or planning tool for anyone, as opposed to the others you just mentioned, which tend to be in software, right, in our industry.

And that's who we're geared towards. Trello when it first started was very much on being simplicity of design, being easy to use, tactile, easy to onboard. You don't need customization. You can use it in single player mode or. or multiplayer mode. And so that meant that at the beginning, we got a lot of people using the product

that were small businesses, that were families, that were people planning their weddings potentially. And then over time, as our users became more sophisticated or had more problems to solve, that's how I think we evolved and grew with them. So some of it's around, you know, this concept of progressive disclosure, where you start with a small problem

and as it gets more sophisticated, Trillo grows with you, where they think some of the other products they start with complexity. And if you want something simpler, you kind of have to pull things away or tease things apart. And that was definitely something that helps Trello stand out. I think now many years later, you'll find that Trello is very fully featured and fully powered, and we lean into that, or they now lean into that a lot more.

But that wasn't always the case. So it sounds like Trello broadly was meant for a lot more than just software teams building product. Yes. It started off, I think, being inspired by software teams and wanting to understand how to move and manage tasks easily. That was the origin story, but then very quickly became the kind of tool that anyone could use to manage anything. And now I think we're back more. The product is way more towards the software development, and that's a lot more of the competitive advantage. But I think the people that are excited about Trello and the ones that made Trello really impactful were necessary.

early software. Got it. When you think back to your time helping grow and retain folks on Trello, is there like a big win or something you're really proud of that you think back to as like that was a huge success in that time to help Trello grow more or be more successful? Yeah, that's probably not what you'd guess. So when I started Trello, I actually joined to build out Trello's enterprise business. And so a lot of our growth and retention was actually about.

how to get more teams kind of into the product and then spreading it throughout the org. So not only software teams, but sales teams or marketing teams. And so the big push there was around collaboration. How do you create a shared perspective for everyone working on a project, not just a software team? So we had a good time thinking through what's the customer experience, but obviously in the context of enterprise, which for Trello at the time was really tricky because it's such a customer-first product, I think shifting our mindset to understand like enterprise and teams specifically

as a cohort was very different. And I think we've done a pretty good job of that or the team did a good job of that. And I think being a part now of the Atlassian suite kind of definitely leaned into that even more. Was there like a specific feature that unlocked a lot of opportunity? Or is it just broadly as a bunch of little things you had to add? I think it was broadly,

a bunch of little things. So all the enterprise features that you can imagine that all could us need to kind of operate at the enterprise level, smaller features around, you know, labels like how do you color them, how do you name them, when do they appear? When you invite people, do you invite individuals or do you invite teams? So a lot of the work was around going from like single player or two, three player mode to five, ten, twenty people. Got it. Coming back to the question of like Trello versus Jurek, because I think this might be interesting. to people just like, if you're trying to decide, should we use Trello? Should we use Jira? What's like a simple way to think about which way to go as a founder maybe or as a product team? I think that smaller teams, especially folks that are ideating, right, when you haven't landed on what you're going to build yet, I think Trello is a great product for that, for pulling ideas, for prioritizing them, for tracking how we're progressing through like discovery. I think Trello is really great for that. For things that have been a decisive.

and are ready to go and are really in the breakdown these tasks and assign it to people, then something like GER is probably a better use case. But I'm sure there are people that'll disagree with that. Cool. Building for PMs is what you were doing while you were working in Trello. I imagine that's kind of a bittersweet experience. I imagine in some sense they're like an amazing market to sell to on the other. They're probably really annoying.

What's like a surprise maybe or a lesson about working on building products for product managers? I think you're right. It is a bittersweet place to be. I think I less thought of it as building for product managers and just thought about it in the context of productivity overall. And productivity software in itself is really what's bittersweet because there are a lot of tradeoffs. And when you're dealing with a software team, for instance, how you measure productivity or define it for a PM or designer or engineer or a data scientist is probably really different. And so the impossibility of solving for all of those use cases, I think is always what's challenging. And we know that no one product is actually going to solve all of those use cases, no matter what the marketing taglines are out there. And so, it was really challenging to figure out, well, what are the core things that a product manager might need to see or a designer or a developer? And how do you make sure that that core is there? So, like, you get the 80% and then you spend time on the 20% that you know that a very small segment of users are going to use, but they're probably your core. So maybe you spend some time there. But

yeah, the answer is no one's going to be happy. And with Trello in particular, it was challenging because for a while we were in that we built a product that was easy to use for everyone. And so then trying to really narrow in on, well, what is a software development use case and what do we really need for that? And that might be very different from what a mom and pop shop is going to need or someone planning their wedding is going to need. That's a good segue way to something else I wanted to ask about. You used to build for product managers and they built for people getting married. I'm curious what is similar about those two groups and what's maybe most different?

Yeah. A lot of similar. So folks planning their weddings, I mean, think of it as an emotional high stakes thing that you're hopefully going to do once. And so the pressure is really there. The pressure and expectations are really high, not unlike product managers or other. folks in software. And ultimately, wedding planning is this huge project, right, where you have a bunch of stakeholders, friends, family, you need to manage multiple vendors. And the time horizon for a wedding, once you're engaged, is anywhere from like 12 to 18 months. So it is a long time project.

So yeah, I think there's a lot of similarities there. Some of the things that are a little bit different in terms of how we're building the product is the amount of decisions probably that go into wedding planning are far more than you'd imagine. So one of the reasons being at the knot is so interesting is we go all the way from planning tools. So actively, how do you help people find inspiration and plan their wedding day to day to our marketplace or two-sided marketplace? We have our e-commerce business that's supposed to be a registry and paper and obviously our affiliate businesses and the ads businesses. So it's a little bit different from a SaaS productivity tool, the business that we're in. But a lot of the problems that we're

solving for users are actually really similar. Which one's more, I don't know, stress inducing? That's a great question. I think that, I mean, couples, like this is a, it's such an emotional thing for people, for individuals and their families and their friends. So I think I personally feel like I empathize with that in a way that I might, that I don't do the same for product, even though I'm a product manager, because there are many projects and there are always things that we need to manage.

and that's just part of the gig, whereas planning your wedding for couples, like this is for many the most meaningful time of their lives. And everyone does this differently. So we have folks that are planning their multi-hundred, you know, person weddings, and they're 10, 15 closest friends' weddings. But the emotional side of it is the same. And you don't want to let them down because most aren't going to do it again. Yeah, okay, that's what I would have guessed.

It feels like wedding couples are going to be more stressed. Yeah. I just had an idea. I imagine you think about this. We're doing a baby shower right now, and it feels like you're missing an opportunity to be the baby shower invite platform. Yes. Okay. We've thought about it.

Okay. And also registry, registry platform. Yes. Okay. So many opportunities. All the life moments. Oh, my God. One last question about Trello.

Do you have any just pro tips for someone using Trello and may not be aware of something they could do with Trello? I think the biggest that people probably know about but are often underutilized or power-ups. which is basically our integrations. And power-ups are folks that are usually doing things that are more complex often. But Trello, you know, when you think about it with other products, like Asanas, you mentioned linear, some of what people are worried about is that it's just not powerful enough. And power-ups are a way to do that. And there are dozens and hundreds of integrations that you can use it for.

So that's worth checking out. Awesome. Great tip. Yep. Shifting a little bit and kind of zooming out, you've worked at, a lot of different companies at a lot of different levels, also a lot of different geographies. And I want to chat about that last piece. But maybe just broadly, what are a few of your biggest lessons about building teams, building successful and impactful teams?

This is kind of my jam. Excellent. It's kind of what I spent a lot of time thinking about. And I think every company you go into, you approach it slightly differently. for me it usually starts with for individuals identifying very clearly early on roles and responsibilities

like what are the expectations of a role so in software for most of us one of the things that I think I've seen done well or contributed to multiple companies is the triad product design engineering data and what does it look like for these roles

and data science that's like other yeah that's interesting you put data in there I'm trying to pull that in. That is my mission. I love that. Product design, engineering, data. It's not a try it anymore, though, but I love it. Yeah, quartet, something. It's a chair. It's just a chair.

It's a chair. Great. So I think about that a lot, like, what are the roles? What do you expect for each of them? And how do you define the responsibilities that we have to each other? I know it sounds kind of maybe, you know, on the softer side, but I think a lot of what we can solve for in creating strong teams is exactly that. And the exercise that I often do is I generally have an idea of what I think the role and responsibilities are and the expectations across these four roles.

But the exercise, especially with leaders in an org, is to have them sit down and write them for each other. So Alassian has some of this that they do in the form of playbooks. But it's basically I as a product leader, I'm going to write down what I think, the expectations and the role and responsibilities of my engineering. manager of my designer of my data. And then we look at it together and then we arrive at essentially a contract with one another about what we think that looks like and what that responsibility is to our teams. And from there we cascade it throughout the org. This is very

time intensive, right, as you can imagine, and often leads to a lot of debate because depending on the kind of orgs or people's backgrounds, our expectations might differ. But I think that contract early on is really important. This is super interesting. I want to go two levels deeper. Yeah. So what is it that you're like, is there a template that you have? Is there specific questions you're answering? Is it free form?

How do you actually know what to write in sort of one of these? There is a template. There are templates we can probably share after this to kind of run the roles and responsibilities. And it usually comes in a couple of forms. It's what the expectations as an I see. What's the expectation kind of as a manager or with your team? And then what is it to each other? And one of the things that are shared.

right? So, you know, when we're running an experiment, like a product manager is likely to write a product brief and go into the details of what that means. The data scientist is likely to help write the actual experiment brief, but we're all putting inputs into it. But then when it comes to data and analysis, my expectation is that both of you are doing that together. And is the idea the PM writes, here's what I'm planning to do? Is it the data scientist writes on behalf of the PM? Here's what I'm planning to do. Is it the data scientist writes on behalf of the PM? Here's what I expect you to do. do who's kind of taking the charge in each of these? You write your own. So as a product manager, I write what I think my role is and also what I think, what my expectations of my counterparts are and they do the same. And then we review it together. And you basically do this.

You encourage every team within your domain to do this amongst themselves. Yes. That is very cool. If there's an example, you could share that we could put in the show notes or a template, that would be great. We'll do that. Yep. What have you found as impact that comes from?

doing this like a before and after. What kind of difference do you see having done this on a team? So I'd see recently, I'd say in the past maybe five years, one of the things that has shifted and has caught some people by surprise. I don't know if it should or not is around project management. Right. So I think like 10, 12 years ago, everyone expected that they would have scrum masters. And scrum masters have like largely in many companies just kind of disappeared. But then you think, well, where did that responsibility go? Because someone has to do project management, right? And this is different from program management, like internal to a team.

And from my perspective, a lot of that now sits with engineering managers, which is a little bit different from how it was when I started in product, where actually a lot of that was put on PMs. And some of you might recall caused a lot of issues for product managers because they were the ones that were constantly like, what's happening in the sprint, what didn't make it, Why didn't it make it kind of doing a lot of that work? And I think PMs are still responsible to keep track of that,

but engineering managers are increasingly expected to be the ones that are actively, like making sure that sprint goals, for instance, are met. And that's a shift that I've seen recently that we do have to debate often. I think one of the most interesting elements of this approach is that the product manager role is so ill-defined and so different every company. And so I imagine much of the benefit here is just like, what the hell is the PM's response to it? 100%. Is there anything that you find as surprising about, like, what teams end up taking off the PM's plate or putting on the plate that maybe other companies don't? I think a lot of people end up putting a lot on the PM's plate because of that misunderstanding.

And so you end up looking at something as a group and saying, well, no one human can do all of those things all the time. So let's talk about what a shared responsibility looks like. And what I think is really powerful about the triad is, is that it's a recognition of like there are shared responsibilities, you know, who's responsible for making sure that everyone understands what we're doing and why. The PM leads that, but evangelizing that is something that would be expected of designers and engineering managers and data scientists as well. On the data scientist piece, you talked about how you're trying to embed that more and more into product teams at Airbnb with data scientists are embedded in every team, so I totally get that?

It's not everywhere. Yeah, exactly. What more can you share there of just why you found that to be important and how you're approaching that? From my experience as a product manager, it was always a blocker. Getting your hands on the data, maybe having someone to troubleshoot with. If as a PM you couldn't kind of understand or figure it out yourself, it was just always a blocker. And so then you'd also then have to go and negotiate with other teams about getting someone's resources to look at this problem. So that's one. The other is just that data scientists, as with most humans, like we get better, the more focused we are and the more

in depth we are in understanding the product itself, right? So if you have someone that's dedicated to a zone or an area of the product, then then it's much easier for them to spot patterns as opposed to attempting to understand what's happening every time a ticket comes in. And so the shift you push for is instead of like a centralized data team that you convinced to give you resources, you embed the data scientists and the team. And do you, do you call them data scientists, do you call them analysts? How do you think about that? That also varies per company. That depends on the organization

and kind of the work. Some teams require data scientists, not all. Some require analysts, right? So that just depends on what the team's working on, what's needed. Got it. Coming back to the roles and responsibilities framework, do you encourage teams to revisit that every once in a while, or is it like this team's done this thing and we're good for a while? I encourage them to revisit it. And it's usually because something's fallen off the rails.

I think if I were really great at it, I'd say every three months or like every six months, let's have a look and see how this is going. But often it happens because there's some conflict or tension or something was missed, and someone thought it was theirs or not, and we have to do a quick retro. What do you find is often that thing that is maybe missed or often causes tension? Execution. It's usually around execution and velocity. Mm, like not moving fast enough for dropping balls. Yeah.

What do you find often is a way to help with that as a leader of teams? Well, one, just identifying what the velocity issue is. It can vary. So for PMs, it's often around the velocity of decision making, right? How long does it take us to actually from saying we need to do a thing to defining it potentially and then deciding are we actually going to do it or how? And that, I think, takes a long time for most, most companies, most people. So velocity of decision making, so I think that tends to fall on the PM most often. The actual execution of it, right? The development tends to fall on both PM and engineering. So in engineering, I find that depending on the org, you know, some folks understand like breaking up tickets into small pieces and why that's valuable and how to do it.

And that's something that I think everyone in industry probably needs a refresher on, and like why that's valuable and how it works. And some of that is also shared by the PM because like if you haven't articulated clearly or well enough what we're trying to do, then it is hard to kind of break that apart. So yeah, those are the two things that are on my mind a lot. Is there anything else along the lines of what you've learned about building successful teams? I really love this roles and responsibilities approach.

outcomes and output also comes up a lot and I think that in many of the companies that I've either worked with or advised, coached over the past few years, it was all about outcomes. Like everyone was outcomes, outcomes, outcomes, which is right. You want to make sure you're doing the right thing with the right goal, and that's fine. And some folks, you know, myself included at certain points, like swung way too far on the outcome. strain and forgot that output is an indicator of that. So if you have a team that's doing all of the ideation and figuring out, you know, how to make decisions quickly and getting the right documentation and setting up the right product briefs and design briefs and experiment briefs, all the things that we know go into successful product development, that's great. But if you're also not shipping a lot of things to market quickly enough, then it just doesn't matter that much.

So that conversation is one that I think we often have to revisit on teams, on all the teams I've ever been on, that yes, outcomes are important, but also the indicator is around execution and velocity. So if that's not in line, then a lot of the other things don't matter that much. And so when you say outcome, you're saying here's the goal they're achieving or the impact they're having, or is it just the idea? Like, we know what our outcome will be, but they're not actually shipping anything. like when you say output and outcome, what are you referring to specifically? The outcomes are understanding what the goals are and what we might do to get there, right?

So OKR is one way to talk about that. Great. But embedded in that is, and how are we going to get there? And the fact is, like, the more tries you have at it, the likely you are to get it right. So if we're not actively monitoring,

like how fast does it get us take us to ship things to market? I see. So kind of like, if I can rephrase it, it's a lot of teams like know that there's talk about what they should be doing. They have a strategy. They have a goal. But what you're finding is that there's just not a lot of action a lot of times. And there's like a huge opportunity just to like get a team to actually ship more often and move faster. Yeah, there's not a lot of like understanding of our role in urgency.

Like, right, it's urgent. And software in particular, probably can't forget that because someone else is likely doing something. similar or better and faster. Makes me think of Frank Sluteman is his name. The Snowflake CEO here with this book called Amped Up. He talks about how to build thriving software companies and business in general. One of his three most important recommendations is always have urgency to never let off the gas of urgency that things always need to feel urgent.

I'll check that out. that I think product managers, like I consider product to be the ones that really need to drive urgency. Say more about that. What have you found helps in creating that sense of urgency and continuing to increase output? Mostly reminding people often, right? And I don't think that this, the question of like, well, show me, listen, everything you shipped, that's never going to work. Well, that doesn't make people feel good about the work that they're doing. but, you know, let's talk about our experimentation backlog.

Like, what do we have in there? How quickly are we getting those things out? Those are the kind of conversations that I think helped. I think that having a good pulse on competition helps as just a friendly reminder, you know, that there are others out there doing this and thinking about things very similarly, possibly to how we're thinking about it. So how do we differentiate ourselves? And a lot of that is about, like, how quickly are we getting many ideas to market?

Small tangent. The competition site is interesting to me because I've been, I've worked at a few companies where I've worked with founders who are like, we don't have competition, right? We're the only ones doing this. And then fast forward a few years. And you're like, here are all the companies that were your competition that you didn't recognize then that are our shipping great product now. This might be a tough question,

but I think there's always like a sense of we can move faster. Like it's rare that like, now we're moving fast as we can. Do you have any kind of heuristic or I don't know, kind of good feeling of like knowing and sensing like where this team's doing fine versus this team isn't moving as fast as they can? How much time do we spend on what I'd consider optimizations

versus like bigger bets? Right? And how long does it take for that to happen? Right? Because, you know, you've talked to the folks or been in the companies where you talk about something that by most measures is pretty simple. Like, you know, someone goes heads down for a week or two and gets it done. And you talk about it.

And then, you know, two quarters later, someone mentions it again. And you're like, oh, okay. So what are all the things we did in between that time to now why that thing, seemingly simple thing, didn't get done? And I think that's hard to say as a product manager because everything we do is all about prioritization. And I'm sure there are a bunch of other things that were prioritized. But they're like these little things that come up periodically or bug fixes.

Like something is broken. You know, how long does it take us to recognize it and actually fix it? Do you have a heuristic, and speaking of big bets versus optimizations of just how much time slash resources to put into each bucket? Unfortunately, the answer is it depends. Right? If you're working on a business that is 30 years old and has many acquisitions or is very different from a startup, right, or a growth stage company, I think it just varies. Yep.

That's often what I find. One last question along these lines, though, is on my mind as you're chatting. When you're finding that a team is not delivering as much output as you would think, what have you found works in helping them recognize that and not get defensive and not, you know, have all these experiences? for that's happening, just like help them see what you see? I'll tell you what I do. I don't know that I think folks might get defensive sometimes. Yeah, I think. But I'll tell you what I try.

For me, the biggest thing is just, you know, if folks are working on a sprint, it's very simply, like, what did you deliver this sprint? That's it. Just asking questions. Just ask a bunch of questions. What did you deliver? And the more questions, okay, fine, but what did you deliver to production? Great.

and how long have you been working on that? Like how long? What was the cycle time? So these questions that are really just, I think, seeking to understand because I understand complexity, right? And so that exists everywhere. But maybe helping folks see that as they're reviewing their own work or their teens work goes a long way.

Yeah, and it comes back to your approach of just focus on the output, not like what they're planning to do, what they've actually done. This episode is brought to you by H-RFs. You probably know H-RFs as one of the leading all-in-one SEO tools used by companies like Facebook, Uber, Shopify, LinkedIn, Pinterest, and thousands more. But H-Refs is not just for big companies. With their new H-Refs webmaster tools, you can optimize your personal website, like a professional, for free. You can scan your website for over 100 common SEO issues that might be hurting your performance and search engines, plus get advice on how to fix those errors.

You can have it automatically browse your website's internal and external links and get actionable insights from your backlink profiles, and you can learn what keywords your website ranks for, and see how you stack up against your competitors. Visit hrfs.com slash AWT and start improving your website's visibility. That's HRFs.com slash AWT. Shifting a little bit, you've been a PM for a long time since 2010, I believe. Yeah. And a lot of people kind of move out of PM, and so it's really cool to talk to someone that's

been in the field for a while. What have you seen in terms of how product makes you? maybe has changed, the role of product management, the role of product leadership, and also maybe other functions like designer engineering. Yeah. I think the biggest change for product kind of macro is how mainstream it is that I still find fascinating the getting degrees in product management and going to business school to transition into product management and like the whole discipline. And there's a whole business, honestly, around the business of product management, which I find really fascinating and didn't exist. And I think, for better or

worse, that comes with a lot of good and in some ways, I think, might have removed some of the quirkiness and creativity that probably is required of product. But that's probably a different podcast. So that's one, just macro. In terms of the roles, I think that what we're talking before about roles and responsibilities and defining those, for product managers, I think product managers are increasingly, I think, a bit more technical or expected to be. I think there was a moment where they're technical, and then it was, no, no, we're all generalists. And now I think we're going back to PMs need to be more technical. I think designers, the expectation is that they'll be more business-oriented, right?

Design as a means, honestly, to an end. I think that's trending and probably for the better, I think the best, designers I've ever worked with are also like exceptionally savvy business people. And I think engineers are increasingly becoming more product focused, more user focus. So, you know, product engineers are something Trello, I think, did really well. This idea that great ideas can come from anywhere in the org and any function, I think is really magical. So as you're seeing, PM's becoming more technical. I think designers becoming more business oriented. Engineers are becoming a lot more product, user focus. To me, that's amazing because it means that we're getting closer to what I'd consider

like really deep collaboration. And it's not to say that we're not experts. Like there are expertise within that that we expect of folks, but that care for other disciplines, I think is where a lot of magic happens. That's really interesting. When you say PM's getting more technical, what is, when you're hiring, interviewing, what are you looking for? Like do PMs need to learn to code? How technical do you find they need? I don't think so necessarily. I think a lot more PMs are. A lot more PMs are taking boot camps or coding classes,

which I think is all to the good. I don't know that it's a requirement, but there is more of that and I think it's very helpful. Similarly, a lot more PMs are taking more, you know, classes or digging more into data analysis, also really valuable. So, yeah, I don't think it's a requirement. I am not like a technical PM.

I don't have a tech background. I think I've been doing it long enough at this point, to do okay, but I think it's a benefit. You said that the PM is becoming more of just like a thing with training, classes, and courses. Yeah. I did a search once on LinkedIn for how many product managers there are. Guess how many PMs there are in the world that have the title PM in their LinkedIn profile?

A lot. I'm guessing a lot. Two million. That's wild. That's wild. Yeah. And there's 800,000 just in the U.S. Wow.

It's like a large. A large group that I didn't expect. Back in my ed tech days, a friend of mine, her kids were in school and she came in one day. Her son was in grade school at the time in elementary school. And he had a like this, you know, match to careers, what you see. And they had a person at a computer, this image. And it was product manager. There was an option for product manager.

And that's when I knew. I was like, okay, this is mainstream. We're about to become consultants. Yeah, I always used to joke. no one grows up and is like, I want to be a product manager when I grew up, but I think that's starting to actually get a thing. Yeah. While we're in that topic, I imagine people often ask you for advice on how to get into product management. Do you have any advice there for folks that are listening though? Maybe you want to get into that. There are many ways now.

I think there are a lot of the typical programs that a lot of the big tech companies have, I think is one way. I think getting into startups as a product manager is a pretty awesome way to get into product because it's just a lot of problem solving. The problem with that is you don't have anyone to teach you the right way, but the product will teach you the right and wrong way if you're with a team that is moving quickly. So yeah, I still think that's working on smaller products and companies is a great way to get into product management, in part because you'll get to touch all of the functions

that are kind of required parts of the product to discipline. and I think it's hard to get that experience otherwise. The PM role, we haven't talked about this. It's just like very hard and very stressful and mostly sucks in many ways. Yes. And we could talk about that if you want. But it was more of a segue to work-life balance, which I know you have some strong opinions about it.

So I don't know. You could take it in the direction, but just like thoughts on work-life balance slash how hard the PM role is. The PM role is really hard. I feel, especially now that I'm managing a lot of teams, right, and PMs at a lot of different levels, I do find that periodically I remind them with like the core of my being that like, I know this is hard, right? Like, it is hard. There are a lot of expectations.

You're expected to be competent across many areas all the time. You're expected to have an answer and you're expected to like keep your calm and like, not lose your shit. And that's really hard. It just is. It's stressful, right? So I think I spend quite a bit of time with my team, my PMs, like helping them understand that I understand that. And so when we're problem solving, let's probably not solve for everything. Let's like focus on one of many things that are expected. So yeah, it's really hard. On work life balance, as I mentioned to you, I think about this a lot. I am currently mom. And as you can imagine, like, that's a lot to to manage at any given time.

And so recently when I think about work-life balance, I don't use the word balance. I use optimization, right? It's this question of, like, what are you optimizing for right now, whether it's today or this quarter or this year, with the understanding that I don't think you can have it all at the same time,

all the time. And so I'm like increasingly coming to peace with that. Where that's been interesting over the course of my career, It's chatting with my husband about this yesterday. I was thinking about it was early in my career, I remember when we had big releases, like, folks would just work nonstop for a couple of weeks. We would stay in the office late. We would come in early.

If it was international, we just probably wouldn't sleep because we wanted to make sure we QA'd everything before we released it. And that was an expected part of the product development lifecycle. And there was a lot of my early product years. And I just did it. And it was very exciting. and I quite enjoyed it. But even then, the flip side of it for me was, I also, I was a runner back then.

So if I was training for a half marathon or a marathon, then like, you know, the next week, I'd probably do my long run in the morning and not start work until 10 a.m. Like, that was my version of balance, right? And I think we're all lucky enough. Many of us, excuse me, are lucky enough, especially in tech, that a lot of companies kind of get that form of flexibility. So now fast forward, 13 years. It is very similar.

It's like, I don't, I don't do all of the drop-offs and pickups for the kids. But, you know, there are some weeks where I'm like, this is the week. I'm going to do all of the drop-offs and pick-ups or this is the day. And that's felt much healthier for me than this expectation that I'm somehow going to balance it all. And everything is going to be equally great or cared for all the time. I think what I'm hearing is essentially, which I really like and agree with is like sometimes you're just going to have to go sprint and go hard and work really hard and go long hours. And then that doesn't need to last forever.

And then when it's not enjoy that extra time and kind of like rebuild and recharge and do the things you got to do. Yeah, that's about right. Yeah. I find the same thing. I find that just like working hard is very correlated with success. And a lot of times that's just a lot of long hours. And sometimes you can't balance it. Right.

For periods of time. Right. And it can also be, you know, at different points in your life. Right. So right now, at this particular moment of my life, I'm probably not going to go hard at a super early stage startup. Right. Because I believe that you probably need to be in person and working really hard together for a long period of time. And not everyone feel this way. I know that. I've had these conversations with lots of friends and colleagues. But so personally for me, that's probably not the decision I would make. at this moment in my life. Yeah, I get that. Another area I wanted to touch on is remote work and distributed work. I believe most of your career, you're remote or you worked with remote teams and distributed teams. And that's such a on-trend thing now where a lot of teams are working hybrid, working remotely, working on distributed teams. What have you learned about being successful working with distributed remote teams? Yes, my entire career has been with remote or distributed teams. That's right. When I started early my career, I lived abroad for a while in Shanghai.

I had a core team there, but also worked with the distributed team in Europe and Latin America, which meant all kinds of crazy hours and lots of sprints like we just talked about. Things that worked well. One, like documentation, it's a thing. Asynchronous communication, everyone just has to get used to it and better at it. So increasingly just being better communicator. whether it's on a video or written. I think that's just really important, and everyone building up that muscle is really important. For all of the roles I've been in,

this notion of what does it mean to have really meaningful and valuable in-person time that can sustain you for the remote and distributed time is really important. I think a lot of what's happened now in COVID, and even now, a lot of teams have never met their coworkers. Like, they don't onboard in person, they don't have events or off-sites as frequently.

And I think flexibility is really great, but I think that makes it really hard. And to me, what I've figured out, I think, is that it especially makes it hard to solve hard problems. Like, solving a hard problem remotely with folks that you haven't spent in-person time with, that you haven't broken bread with, that you haven't disagreed with in person

and built that trust. It's just really hard. In fact, it's much harder. So some of the things I've done even here, like the not worldwide, is periodically when there's a really gnarly problem, I like wave the flag and I say, hey, everyone, why don't we try and get together for two days and like hash some of this stuff out? And then we can go back to our remote lives. And I think folks have been maybe unsurprisingly very open to that because I think they see the like not only the efficiency, but the camaraderie that can happen there as opposed to what was happening potentially on a. you know, hang out or a Zoom call. What does that event look like?

Like, where do you do it? What's roughly an agenda? One, the agenda is pretty tight before we get there. Right? Myself or someone else were responsible for making sure that that's a well-articulated agenda that we all kind of agree on before we even get there. So I think that's one. I think 48 hours, two nights, right? And that's important to me because it is the, tends to still just be hours in a conference

room. room during the day, but you do need to build in the, and let's go have dinner since we're all in person anyway, or let's have an extended lunch and maybe an extended day. I think that's just really important. And even early in my career, when I was working more internationally, the company I worked for was pretty amazing because two or three times a year, the entire company globally came together for a week or two. And it made a huge difference. And many of the folks that I worked with, they're still, you know, friends and mentors. Are you able to share what was the challenge you're trying to overcome in one of these times?

Yeah, I can speak about it generally, which was just, we had a change in strategy, and we need to land a couple of core decisions about what we might build. And there were lots of documents and lots of conversations and back to the velocity of decision making. Like, remotely, that can be really hard because with time zone, someone sends a doc, you comment on it, you get to the other day by the end of the week. And so days and days of past, and we still haven't landed it. And people have really strong opinions, obviously, that's something that big. So it's like, nope, okay, great. We have the flag. And not everyone could make it. Most people could. And the folks who could not were yes on a screen. Was there anything specific in that offsite that helped you get to a resolution?

In that particular one, it was one very cross-functional, and the unlock there was giving the data person the space to educate all of us. That was it. It was like, you have the floor. Educate. Yeah, I find that's often the solution is people just don't have all the same information that they're basing their decision on them. So make sure everyone starts with the same foundation. Awesome. And it comes back to your push to get data integrated into every team, make that part of the four quad triad. That chair is the chair. Anything else around remote work or distributed work that you found to be incredibly impactful or important? Well, the flexibility of it, I'm sure you've talked about with others, that is really important.

I do think that the Intrello and Alessian, I think, did this really well, is having standards around a couple things. The biggest one, I think, was overlapping work hours. So everyone had general flexibility, but there were some set of hours where everyone needed to be online at the same time for the most part every day. And that made a big difference. Onboarding happened in person. I think that in-person onboarding for new folks is really important, especially for everyone. For any new person in an organization, I think how we work culturally, having a comment that you can reach out to, all of that I think is really crucial. I'm definitely of the, so much of my early learning was in person. And I have no idea how we're going to replicate

that in a non-office setting. It's just really hard. How long do you try to have that person in the office for onboarding? Is it like a week? Is it a few days? A week. Shifting a little bit. Just a few more questions. You mentioned you worked in China. You also worked in the UK for a while. Obviously in the U.S. now. What have you found to be some of the biggest differences in maybe the product culture or just culture in general working in these different areas? The confusion around what product management is universal. That's like not specific to U.S., I think, and the fact that it's changing. That I think was the same. I don't know that I found that many differences in terms of kind of the how we approached goal setting, all very similar, the need for urgency,

like all those principles, I think this are the same no matter where you are. Part of what I experienced when I started in Shanghai was the feeling that the product manager was expected to have all the answers, which, as you can imagine, was really overwhelming. And so I remember because I was young and I didn't know that much about it. product management, and I definitely did not have all the answers. I spent a lot of time helping the team help me answers, and that was a little bit of the culture shift in our team at the time. And I actually think that's kind of carried me through my entire career, right, which is trying to figure out how to share the product management load. So we're like equally

responsible for what we're building. So that was a good, good, like, unintentional learning. that I think has been really important for my career. I think that part of that learning that I've had obviously here and in London as well was the figuring out how to make room for creativity. So in Shanghai and also in London at the time, this was a decade now. So many things have changed since then. There just didn't seem to be as much room for ideas to come from anywhere, which I think is also related to what I was saying before.

So like making space for people across functions to share ideas and then across geographies to share ideas, especially in companies where English might have been the primary language, but most of the employees were not native English speakers. Like there was a lot of time I think that I felt that I wanted to spend, and I did, on just creating space for people to like comfortably share their ideas, honestly. And that for me was really formative. because I think it's been, yeah, it's really impacted how I've approached my entire career. And I don't know that I would have had I not had those experiences.

I was browsing through your LinkedIn post and you said something just like that on LinkedIn of just like how formative that experience was for you. I know it's not something people can just like, hey, I'm going to go to China and work for a startup. But it sounds like you recommend working at companies of different cultures because it feels like it kind of like is a lens. Yeah, I do. I also think, you know,

my, I am, my family, I'm Jamaican, I'm a Jamaican immigrant. And so all of our experiences inform, like how we perform our jobs and how we think about problems and being able to expand that is, yes, I would recommend it to every and anyone that gets the opportunity. And I think it's really important as product managers because I think it's really hard to be a product manager if you cannot empathize right with the people and problems that you're solving for and being out of your comfort zone obviously is one way to learn empathy I love that one final question is there before we get to a very exciting lightning round not to not count that those questions are there just any like frameworks or processes or methods that you've found to be very valuable in your career as a product

leader that you would want to share? The question I ask myself and I ask everyone in my life, probably, whether it's on my team or when folks, friends talk to me, I always ask, what are you optimizing for? Like, that's the question. It's what are you optimizing for? And it's, you know, the short, medium, long term, and product, but it's the, what are you optimizing for today, this quarter, this year, whatever time horizon. And I think that can be just a really illuminating way of thinking about, obviously, honestly, like just how are you spending your time? And I think it works for product as well. Like, every time we talk about OKR or a goal setting, ultimately it is, what are we optimizing for for some period of time? And I think that always, for me, whether

personally or in product, is very illuminating. I love that. I'm pretty sure I've asked that question a thousand times myself. One thing I find those, people get annoyed with you, just like, okay, you're such a, such a PM. Just like, I know, but it worked. It does work. But it works. What are some instances where you deploy this question? Like, is it in a meeting where someone's asking a question or just like, what are we optimizing for here? I mean, I ask this question like all the time. I ask this question to my husband. Like, what are we opt-up? I see. I'm sure. I'm sure he loves. He was a pre-empt too, so he gets it. Okay. Okay. That's helpful. I asked this to my five-year-old, honestly. Five-year-old. It's, we talk about it a lot. Like now we're going to quarterly planning all of us, right? And, And now we have information from Q1. So let's look at it and say, okay, given what we know now, what are we optimizing for? Because it might not be the same thing we did before with new information. Or it may be.

And that's usually just then helping us get better at figuring out, obviously, how we're doing tradeoffs, right? That's awesome. Because the first point isn't clear then, the tradeoffs aren't going to be clear. Yeah. The other question is what? What are we trying to solve? I feel like I need to make mugs. put these on some mugs for product managers.

Well, with that, we've reached our very exciting lightning round. I've got six questions for you. Are you ready? Yes. I don't think I've prepped this when I'm ready. Yes. Okay. Well, it'll be the most fun then.

What are two or three books that you recommend most to other people? These are not product books. I recommend Anak Matavaz. You Will Hear Thunder, a book of poetry that is excellent. I recommend almost anything by James Baldwin, The Fire Next Time I most recently reread, and back to software, high output management. What are some favorite movies or TV shows they've recently watched that you really enjoyed?

I am really into K dramas right now. Is that a Korean? Korean drama this right now. Crash landing on you is, you know, it's great. It's a love story. Wow, it's wonderful. Very out of the box. I love it.

What's a favorite interview question that you like to ask? For product managers, if we think about product in the context of artist, scientist, general manager, where do you spike? Artist, scientist general manager. Interesting. And is there one you ideally look for the answer or depends on the role you're hiring for it? Totally depends on the composition of my team. Interesting. Cool.

I like that. Different triad. what's a favorite product you recently discovered that you love? ARC by the browser company. I think they're a product that's clearly having a lot of fun. And you can feel that in the product. When I first opened it, they have an unveiling experience, which isn't something you'd expect of a browser,

and there was something really delightful about it. Yeah, I imagine you've heard the interview with Josh. I did. What a guy. What a cool product. I love it. We have a whole hour and a half on it. So check that out if anyone wants to learn more about ARC.

What is something relatively minor you've changed in your product development process that has had a tremendous impact in your team's ability to execute? Helping product teams try as product design, engineering, and data understand their shared roles and responsibilities. Awesome. Call back to our previous discussion. And final question, what's a pro tip for someone trying to use the knot or one of the other properties? Oh, good question. Two things. But one, the big one is probably checking out the not worldwide marketplace. It is the most comprehensive two-sided marketplace to find your wedding vendors to create your wedding team. And you'll find that they're really cool, small businesses on there.

Awesome. I'm going to go check that out. Nikita, thank you so much for being here. I'm going to go ask my wife what she's optimizing for and read some stuff on the bomb. Wish me luck. He said she's pregnant, right? She's optimizing for creating a human probably. Yeah, that seems right. Okay, I'm not going to ask. Two final questions. Where can folks find you if they want to reach out, learn more about what you're up to you?

And how can listeners be useful to you? I'm on Twitter and LinkedIn, easy enough to find me. I'm very responsive, actually. At least I try to be when folks reach out on anything product-related. And ask me questions. I think that's always helpful. if you have other ways of doing things, I'd love to hear about it. You mentioned also that you're doing some angel investing.

Is there anything you're looking for specifically that you want people to ping you about? I am doing some angel investing maybe a little bit less so recently, but I'm starting to ramp that up again. So if there are any early stage seed or pre-seed companies out there, you can ping me. Amazing. Gita, thank you again so much for being here. All right. Thanks a lot, Lenny. Bye, everybody.

Bye. Thank you so much. for listening. If you found this valuable, you can subscribe to the show on Apple Podcasts, Spotify, or your favorite podcast app. Also, please consider giving us a rating or leaving a review, as that really helps other listeners find the podcast. You can find all past episodes or learn more about the show at Lenny's Podcast.com. See you in the next episode.