Season 2, Ep. 13 – Complexity and prioritization: How we decide what to build with VP of Product, Grey Garner

Transcript

Faith (00:05):

Hi, Grey.

Grey (00:06):

Hello, Faith. 

Faith (00:07):

Welcome back to the Frontier!

Grey (00:09):

Well, thank you.

Faith (00:10):

This is episode like 11 for you. How many episodes have you done so far?

Grey (00:15):

In this season? I’ve done one, so…

Faith (00:18):

Oh, it feels like you’ve been here for every episode with us.

Grey (00:21):

Well, that’s nice. I’m following along. I’m watching, I’m a fan of the show.

Faith (00:27):

Oh, you’re watching, Are you watching on YouTube?

Grey (00:29):

Mm-Hmm. Yeah. And other platforms.

Faith (00:34):

Quick plug. We’re on YouTube.

Grey (00:35):

I like it. <Laugh>. Yeah. Smash that like button, or whatever you’re supposed to say.

Faith (00:40):

Yeah. I don’t know what the kids do on YouTube. I’m such a, like, traditionalist when it comes to my podcasts. I want them in my ears. I wanna be listening to them while I like rake leaves or walk the dog or something. I can’t watch, you know?

Grey (00:59):

Oh, interesting. Yeah, for sure. I had the same thing, ‘cause most of the time, I’ll do podcasts in the car. And so to think of it video is, it’s almost like a special event. Like, oh, this has video! I have to watch that. I have to consume this in a completely different environment. Context. You know? 

Faith (01:18):

I mean, it works for some people. That’s why YouTube is a thing. But I think I’m just like such a freak about multitasking that it’s hard for me.

Grey (01:25):

Yes.

Faith (01:26):

But I do miss—I was thinking the other day—like the time that I used to spend in the car, just getting back and forth from the office made me a smarter, more curious person, because I was always listening to something. 

Grey (01:39):

Yeah. And I think that’s a great point. And I think a lot of people are probably feel the same way. You know, I certainly miss the commute side more than I miss the office side (Faith: Yes) in a lot of ways. Like some days, that’s not true, ‘cause I hated, you know, like rush hour traffic and whatnot, and I kind of wished I could be doing something different. But there was some value in that, you know? There’s some value in a commute sometimes, so, yeah. 

Faith (02:04):

Yeah, there is.  It’s like also a clean transition, which there are no more transitions in my life. It is <laugh> wake up and open the laptop and–the laptop is just my constant companion. I think I need to work on that, actually. <Laugh>. 

Grey (02:19):

Well you’re gonna have a great new office space, so you can have a brisk walk to the to the office.

Faith (02:26):

Let me tell you, the lead up to this office I think has been more dramatic and longer than any sort of like blockbuster film that has been released this year. It’s been like “Coming soon: Faith’s office!” and six months later, ‘how’s the office?’ Still not there. It’ll be great. In the meantime, I’m just—yeah. We’re taking it day by day. <Laugh>.

Well, Grey, this episode is basically like product management 101, I think. When I was sitting down to prepare for it, it was like, this is basically like, here’s what product managers do and how to think about corralling all that stuff. So we’re talking about how we decide what to build. And when I think about our GitHub for the product, it is the Wild West. There are infinite things that our engineering team could be working on at any given time, and they rarely fit nicely together into, you know, puzzle pieces that make sense and tell a larger story. But like, somehow you have to do that, that’s your job. (Grey: Mm-Hmm.) So I guess to start, let’s maybe like establish who you are and why people should listen to you about this. You’ve been on the podcast before, so if people wanna hear the long story they can, but like—TLDR, how did you get into product?

Grey (03:48):

TLDR, I got into product a long time ago with a SaaS app that was in the market and had traction. We had tons of customers, and we realized that we didn’t have a product roadmap, we didn’t have a product function, and the engineers were busy actually refactoring the underlying architecture. So they didn’t have time to do it. So a co-founder and I basically said, what do we want this to look like? And so he and I sat down and basically formed the product function and the company. And so there was a lot of learning on the go and a lot of mistakes, right? Like inevitably, you’re gonna make mistakes, but that was certainly like trial by fire. So since then, you know, I was able to help build that team and saw that company go from, you know, very small to very large and the product go from small in scope to very large in scope.

But usually it’s more of what we’re talking about today, which is, you know, How do you decide what do you build? How do you right size something? How do you put your head around, you know, disparate concepts maybe from different teams that have a common through line? It’s sort of the nuance of like the what to build stuff that dovetails inevitably with business strategy. It dovetails inevitably with, you know, workflows and goals of KPIs and business. So it’s much more sort of on the business side of, you know, the why and the what, not so much the how—that’s for much smarter people than me. <laugh>

Faith (05:22):

<Laugh>. Yeah. We’ll see if we can get the engineering team in here. Cool. I am very fascinated. I didn’t realize that you kind of built the plane while you flew it. As it relates to like learning how to be a product manager, when I think of product management, it feels like something to me that you kind of need to read the books about. Like you can do it as you go, but there’s like—so many people have created frameworks and methodologies that are kind of widely accepted as best practice. (Grey: Mm-Hmm.) So I’m curious, like how did you do that learning? And also how do we think about that here? Like what sorts of frameworks and prioritization methods do we use?

Grey (06:03):

Yeah, it’s a great question. And in the beginning of my product journey, I didn’t know what I didn’t know. So a lot of the stuff that was established in terms of, you know, how to think about product and what are even best practices were, to a large degree, just being established for SaaS platforms. They were being established at that point for, you know, startups and how to think about—the notion of MVP has not always been around. The notion of a minimum viable product is an offshoot of Steve Blank’s work and, you know, lean startup stuff and the agile manifesto and all that, which, in the grand scheme of technologies, is (Faith: new) These are all new ideas, newish ideas. So a lot of this stuff  is establishing best practices by trial and error, and then trying to consume as much about what other people were having success with and what these sort of nascent methodologies were starting to say and why.

And so you know, in those early days, there wasn’t much to go on in terms of, you know, established frameworks and that sort of thing. And now, you’re right, there are lots of really smart people who have sort of figured out a way to, you know, reduce down at least a mental model about, you know, how you should think about things. But it’s ultimately—at the end of the day, they’re all basically kind of dissecting the same thing, which is how do you take complex ideas and break them down into smaller ones? And then how important are those ideas to do now versus later? I mean, it’s prioritization and it’s complexity. And part of, you know, the inherent in agile development are those two things. It’s how can I build something of value in the shortest of time. And so time and value are core components of what you’re doing. And so, you know what, we don’t do anything that’s magical, you know, that’s above and beyond those two sort of core principles. But we do have some things that sort of guide our thinking, and we can get into some of those things if—But I feel like I’ve been talking for like three straight minutes. So maybe get another question in there—

Faith (08:25):

I wanna get into that, because I feel like the easy answer to this question is like, Yeah, we use (inaudible) and that’s just, you know, by the book, that’s what we do. But it sounds like we have something that might be a little bit more—I mean, not proprietary, because you’re right, like everybody kind of works off the grid of value versus complexity—but I’d love to hear you describe it, and maybe we can coin the term and trademark it, and you and I can go write a book, and that’ll be our retirement plan. So we started it here.

Grey (08:57):

Ok. Sweet. Let’s riff. And so like I think for us—Ok, lemme reset—For us, we have to strike the balance. This is not true with all apps, but for us, it’s really important— if we wanna start at the top of what we’re trying to do as a business—it’s really important for us to balance the needs of our many stakeholders with the business’ need to be unique and differentiated and innovate. And so—

Faith (09:27):

Let’s just pause there really quick, because I feel like there’s gonna be folks listening to that to us who might be a more traditional SaaS company, where they’re building with really one main customer, which is their buyer, right? Like their end user. (Grey: Mhm) And you mentioned we’ve got lots of stakeholders. So the product team—our product is a product that’s used by two different end users, so hires and job seekers. (Grey: Right) And also, I don’t—maybe you could throw a percent on this—but not a small portion of our entire code base is built just for Gun.io staff.

Grey (10:10):

That’s right. And there are key stakeholders. Well, because, you know, Gun delivers value through human interaction, primarily. You know, the relationships, the nuance in matching a developer with a company, maintaining a relationship with a client over time to be a partner with them and hiring. All these things are sort of human centric in terms of what bonds one of our users to us. (Faith: Mhm) You know, the relationship that devs have with our dev team in order for them to really get to know our talent and really understand things like aspirations, things like industries, think about like the types of challenges and the types of teams—where they’re gonna thrive. All these things are very difficult to capture in a database, you know? They’re predicated on relationships.

And so what we have to do is is build staff tools that do the things that robots should do while facilitating the things that only humans can do right now. And then maybe over time—and we’ll get into this—like the innovation is how do we start to chip away and learn about what those human, those really nuanced human interactions are and start to chip away at what that might mean to productize those, to automate those? So yeah, like our internal stakeholders are—it’s a huge part of the consideration set when we’re thinking about what to build and why and where we wanna focus our energy. A lot of the more innovative things that we’ve done as a team have not been end user. They’ve been holder staff stakeholder facing, and they’re very discreet, right?

Everyone wants—at the end of the day—everyone wants to make connections and find great gigs. But the workflows and the types of conversation that our talent are having in, you know, the data that we’re collecting in the app, the relationship that they’re building with dev, the interactions that they have with one another in our communities is just a very different thing than what hiring companies are coming to the table with their own set, their own world, right? Their own context, their own industry, their own strategy, their own teams. And then they’re coming to us to really sort of understand that and pair them with this other side so that the contexts are really very different. And then obviously, you know, internal staff trying to do that again and facilitate those interactions, that’s a completely different context than either two end users, right?

So yeah, I mean, that adds a layer of—it adds a layer of complexity that it maybe a typical SaaS app doesn’t have. Like to your point, when you know if the SaaS is—if it’s selling this set of features to this kind user—yeah, you may have two or three different types of personas. They’re using that, but they’re buying the app, right? And in this case, they’re not buying that. They’re buying the outcome of the collective team and the product and everything. So it’s just a different flavor.

Faith (13:21):

So at the very top of our prioritization framework is like identifying the customer, the stakeholder, the end customer of the epic—or the set of issues. What happens next?

Grey (13:36):

Yeah. I think identifying is true. Understanding is a whole different thing. And so I think having expertise in the different domains is super critical for us, because they are, you know—like I said, they’re just very different contexts. And so the talent domain is very different than the sales domain. And so really having a fundamental understanding of what that space looks like is key. And that’s the lion’s share of the time. And then that ultimately leads to the collaboration aspect of it, which is—ok, we’re both seeing the same challenge here. How can product bring some notion of creativity to the solution set and, you know, provide some kinda context for the stakeholder to give feedback on that? So like, yeah, I mean, it’s identification and then it’s really understanding, and then it’s—and then you can get to something that is, you know, a, a wild idea or something that’s a little bit more sort of tangible in terms of a solution. So the solutions, you know, once you do the first few things, right, the solution thing is—it’s not always the hardest part. 

Faith (14:49):

Right? As somebody who is—I feel like I’ve gotten better at this over the years, but I’m definitely like a feature happy teammate. Like I used to just dump everything into GitHub like, we need to build this now, how cool is this idea? So I’d love to hear about our process for deciding what to say no to. Because feasibly, you know, everything would be net positive, but we cannot build everything. We’re still a pretty small, scrappy team. How do we decide what to say no to?

Grey (15:25):

I think unless it’s just an idea that’s misaligned with this strategy of the business, it’s less no and more like no now, because most ideas—to your point—we’re a small team, and at this point, we know our domains pretty well and can articulate what we need to build and functionality and that sort of thing. So we don’t really have—I don’t think—our problem isn’t that there are just these crazy ideas that everyone wants, and there’s no place to put them, and they’re misaligned. I think a lot of— it’s when and what, what are we trying to drive that this helps do? So it’s more about aligning the idea with the business outcome on a timeline, if that makes sense.

Faith (16:17):

Right.

Grey (16:18):

‘Cause there are plenty of things that are great ideas that we could do today, but if we did them, they would be outpacing the progress on another team that needs to have a couple things in place before that’s really gonna make sense on this other side. So it’s a little bit of trying to build the whole thing sort of equally that—and the two sides, plus the staff tools in between don’t outstrip the pace of any other aspect of the app or the business. 

Faith (16:49):

Right?

Grey (16:49):

So I’d say it’s more of a timing question than it is like, wait—how on earth are we ever gonna do something like that?

Faith (16:55):

I would add to that, like, timing is a factor, and obviously naming what results we’re trying to drive. But I would say another question that you often push back on is like, how have we tried this already? Like, how are we doing this manually now to prove that productizing it is the right choice?

Grey (17:19):

Yeah, that’s a great point. And I think that for technology companies, having—being you know, everyone’s—everyone, I think, would probably say that they’re data driven, you know?

Faith (17:32):

No one wants to say no, though. “It’s all qualitative over here.”

Grey (17:34):

“It’s just gut driven.” That’s right. So everyone’s data driven, but that doesn’t necessarily mean that the way that you’re collecting the data or the way that you’re interpreting the data is to a clear next step. And so I think what does inevitably is—to your point—is pushing back on, all right, well, what was the methodology that led to the data? And then how are you interpreting the data from there? And so what that does is it puts pressure on teams to be a really intentional about the things that they sort of want. And then have a clear, A-B about, you know, how to accomplish that the most efficiently. ‘Cause writing code and getting a product team involved and building features is a very expensive way to go about stuff.

And so you need a certain level of certainty there. But at the same time, you know, sales teams are sales teams, and marketing teams are marketing teams, and operations teams are operations teams, and they’re very focused on the things that only they do, You know? And they do really well. They’re not thinking about like, data driven experiments and AB testing over some time period to like—they’re just not, that’s not their thing. So I think for technology companies—and one of the things that we’re trying to do is really, you know, imbue product technology thinking into the way that the teams plan their quarters or years or whatever. And that’s gonna necessarily include a pretty introspective look at, Hey, where are we today? Where do we wanna be? What are the things that are in the way of that? And how do we test something in a fairly short period of time first, so that whatever we ask for makes a ton of sense? ‘Cause that’s how product teams ultimately get faster, right? If you’re constantly reacting, you’re always gonna feel slow. But if everyone’s doing their homework, and we can get—like what I said, the solution side of the equation isn’t always the hard part. It’s the pre— it’s the homework that goes into that, that really—that if each team can come to the table with sort of product like thinking, or if product can actually help facilitate that in other teams, then it will feel like your cycles really increase.

Faith (19:58):

Right. And without that kind of period of experimentation and the diligence around that, it’s impossible to have the complexity versus value conversation, because you have no way to grasp potential value of that future.

Grey (20:16):

That’s right.

Faith (20:17):

I’m curious about the way that we—or just in general, you know—you’ve got some experience with some great product teams. You’ve seen, I think, the full gamut of how this works—you mentioned if you’re always reactive, you’re always gonna feel slow. And I feel like when I look at the work to be done in the product and engineering world, there is a massive kind of collection of disparate requests that might be kind of one off issues that are quick fixes to, you know, reports of bugs, to feature requests that are like maybe blocking somebody and are simple, but require a context change. And then, you know, bigger picture stuff that’s like, you know, if we do this and we do it well, it’s gonna be a huge needle mover for the business. How do we go about kind of like managing and organizing that work? Is it a question of ownership, or do we think about our sprints as like thematic based on the kinds of work that’s being done?

Grey (21:30):

I think we think of our roadmap thematically. And I think to me, there’s a—to me, there’s balance, and think—you know, if you were gonna do this—actually, you did do this. Say you wanna run a marathon in the spring. Then there’s a strategy of how you’re gonna get from I’ve never run a marathon to I wanna run a marathon. (Faith: Mhm.) There’s a thing that—there’s a road map for that. And it has big blocks in it, you know, which is I need to be—I need to hit some milestone at some point the future to know that I’m on track. But then there is, I need to start every morning. I need to drink 30 ounces of water every morning.

Faith (22:14):

Yeah. There’s maintenance.

Grey (22:16):

There’s that. So if I drink 30 ounces of water every morning between now and the time the marathon hits, I’m not gonna be able to run a marathon. There are other things that I need to do other than that, but that is also extremely important. So I think that, you know, when we think about it, we’re very intentional about making sure that we have balance across our milestones. Whether that’s—our milestones are basically sprints. And we tend to think of sort of a monthly horizon as, as a decent sort of more ethical oriented milestone. So each week is— it needs balance. Each month needs balance, each quarter needs balance. And, then a year timeframe needs balance. Because if you’re not chipping away at something that is unknown and maybe really large in scope, then you’re never going to. But we don’t expect to finish. 

But we absolutely do expect to fix a bug as soon as we hear about it. And so the balance is over what horizon and what scope and then what level of solution is known versus unknown. If you strike a balance in every increment of work around those things, then you’re going to be—the marathon will be here, and you’ll feel prepared, you know? (Faith: Yeah.) But if you’re shortsighted and you’re reactive and, you know, there are tons of bugs and all the workflows are broken, you know, you may not be able to be balanced, I mean, the thing’s on fire. But under normal operating conditions, I think that you should have a fairly—almost 33/33/33 of like close-time horizons, mid-time horizons and innovate—even if that’s—I don’t know what it is. Even if it’s, I’m gonna spend, it’s like 20% of my time, I’m gonna spend 20% of my week thinking about a space that I have no known solution for, but it’s a really interesting question. That’s, I think, how product teams can stay to have a consistent pace and actually hit longer term goals.

Faith (24:28):

That’s a really good insight. I feel like product teams, there’s never gonna be a shortage of short to mid horizon requests coming in or ideas, but the thing that we have to be intentional about is keeping something that’s more of an innovative challenge pinned that’s more of like a year out kind of thing. That’s really good insight.

Grey (24:54):

And much more fun to collaborate with other teams on than why this workflow sock so bad. You know what I mean? (Faith: Yeah.) Like, that’s just kind of mundane. But yeah. But if you’re intentional about it, and again, like, I think this is the part about, you know, product and engineering teams I think have the responsibility in technology companies to model behaviors in other teams. And this is where I think, you know, product can really influence, positively influence the way that the business functions is by taking these sorts of principles and taking them to other teams, pulling other teams in and collaborating with them, introducing other ways and thinking about problems. Introducing—especially for very high paced teams that are very much in the now a different time horizon as a mental break for directionally in the business—I think all those are also responsibilities of product and engineering to the business.

Faith (25:53):

Speaking of collaboration, you mentioned earlier when we were talking about your process for prioritization, how important it is to understand your customer, and whether that customer is an internal team or an end user that’s external to the company. And I think we are kind of at this point as a business, and I would imagine many listeners have been there as well, where we’re moving from historically being a pretty small team, where everybody, just by nature of our roles, absorbs through osmosis what’s going on in other departments. So we’re just kind of getting to the size now where our, our teams are becoming a bit more siloed, and we have to be a lot more intentional around how we collect those requests from teams, how we understand challenges that teams are facing, even if they haven’t quite identified the challenge themselves. And I think our product team does a really good job of staying connected and keeping those kind of lines of collaboration open with other teams. So can you walk us through how you approach that?

Grey (27:06):

Yeah, I think—and thank you by the way—that’s really important to us. I think transparency is one of the— especially remote teams and, and so many companies are remote now, and so many engineering teams are remote, even if they’re core companies—you know, one of the things that we hold very dear in terms of values of the team is transparency, because it’s important to know what is happening in the product, right? It’s important to know when and why, and what’s released and how to use it, and all of that stuff that the output side of the equation, but maybe more importantly is the input side of the equation, because we then become the lens for teams in the other teams, you know, because it’s unlikely that the sales and and operations are gonna talk all that much above and beyond sort of getting a contract filled, or sales and our dev team are gonna talk that much beyond fulfillment on a specific job, finding a candidate for a specific job, but said they’re not gonna have sort of, Hey, what are your long term goals? What are your strategic things that you’re trying to hunt down? So they—so product needs to provide a lens into the strategic direction and what’s important on a quarterly timeframe, say for other teams. So it’s the input side of the equation where transparency, I think, really helps. And so if you have product managers that are dialed in with the team, that can translate some of those things, obviously at the product level. But you know, at the business level first, like, how are we gonna translate that into business needs? And how are we sharing that? And cross-pollinating across teams, sharing what we release, providing the why about why, why these things were even built in the first place, really can help illuminate what’s going on at a more holistic level in the business, to your point, and really does break down silos. We sort of feel like we’re the hub of a multi-spoke wheel, you know?

Faith (29:10):

Yeah. And I would say—as an outsider who does not sit on the product team—the tactical things I experience are like, you and I meet biweekly to just kind of share ideas and challenges across product and my area, which is growth marketing, products planning meetings are often open—and so if anybody has—if anybody’s coming to the table with something that they wanna advocate for you know, here’s the experiment I ran, here’s why I think we should like, make this part of our roadmap. Those meetings are open, which I think really encourages that sort of collaboration. The product actually sends an NPS survey to other teams, which I think is unique. I think maybe in larger companies, teams send NPS surveys to each other especially if they’re end customers and internal team. But, you know, we mentioned kind of why our product is unique, and I think that’s just a really cool way to see, you know, are we communicating with folks in the way that we intend? And, you know, does everybody see the value that we’re driving? So I think that’s pretty unique.

Grey (30:32):

Thanks. It’s stressful—

Faith (30:37):

Oh my gosh. Yeah.

Grey (30:39):

It’s stressful, but, you know, it’s super valuable and the time that we’ve been doing that, you know—it’s usually a company with a couple of other questions that helps us maybe drill down into where we can improve and that sort of thing. And you know, being willing to say, you know, to have a sense of sort of humility about what we’re doing, you know, certainly like openness to feedback—I think there’s a little bit of like, you know, you’ve gotta walk the walk kind of idea here, you know, and so yeah, I think that it just cuts straight to the core. You know, if we can’t maintain an excellent NPS score with our internal stakeholders, and it’s unlikely we’re gonna able to do that for other stakeholders that we don’t have quite the tight a relationship with, that we don’t know quite as much about. So I think that it sort of starts as like a— it’s a core discipline, you know, that ultimately, over time, you know, really pays large dividends, especially over long time horizons, but it’s scary getting those numbers back.

Faith (31:47):

Yeah. That also just like survey style feedback is hard. But huge, huge props to you.

So for folks listening who maybe are newer to product management, or they’re kind of experiencing some of the growing pains that we touched on, do you have any favorite resources where you look to see kind of how other folks in this space think about problems as you encounter them?

Grey (32:14):

It’s almost like—I look at it almost like if there were a stack overflow for product that would be cool, I’ve probably read it. But it’s sort of like, okay, I know this sort of—but I wanna get somebody else’s take on it—is there a thread I can go tap for just a couple different points of view on how different people have solved this? And I don’t have anything  to—honestly, that’s my go-to for someone that is just starting out in terms of like resources and that sort of thing. Just a super lame answer. But like, I do think the key there though is not getting too caught up in a methodology, too caught up in a framework to where the tail starts to wag the dog. You know, I think the more that you can lean out and really be sort of—if you’re gonna over index on something, over index on like maybe non-essential like requirements and get more into motivations and that sort of thing, like someone would tell you that they want something, and it may be true and it may be important, but like, why do they want that? What else are they trying to accomplish? How is this gonna affect them or their teams? You know, long term goals is—I mean, it really comes down to like core stuff—is curiosity. It’s humility, it’s empathy. It’s those sorts of things that when you hit a challenge, those are the things that you inevitably fall back on that are ultimately probably more valuable than reading a medium article on the next framework. You know? 

Faith (33:53):

A hundred percent. Yeah. I find myself kind of bing between as a growth marketer who’s like, relatively—I mean, I’ve been doing growth marketing for four years—so pretty new. I find myself often being like, Oh my gosh, well, I need to read how everyone else is doing this. Like, surely there’s a best practice. And in a lot of cases there are, right? Like, here’s the best way to organize your Google Ads campaigns. And this is, you know, tried and true. (Grey: Sure. Absolutely.) But Teja and I talked about this last month actually, there’s like, the best growth marketers are not the best at following a manual. They’re the best because they’ve done something that no one else has done before. They’ve found a new way to provide value in some way. And I think product is similar to that, right? Like, it’s less about following instructions and doing what worked for other people and more about kind of approaching your work with a sense of creativity and like, willingness to try new things. 

Grey (34:53):

Yeah, a hundred percent. It’s a great point. And much better than my answer.

Faith (34:57):

<Laugh>. I would add though, for resources, I have been so inspired. Do you read Lenny’s newsletter?

It’s really good.

Grey (35:08):

What’s that you read? 

Faith (35:08):

Yeah, it’s just called Lenny’s Newsletter. And he also has a podcast. Can you guess what it’s called?

Grey (35:14):

<Laugh> I mean, there could be so many names. I’ll go with Lenny’s podcast.

Faith (35:18):

Yes. Bingo. I’ll send you a hat. But it’s so good. I think we’re kind of in this space right now, especially with product and growth, where there’s just like a lot of yelling on Twitter and—

Grey (35:34):

In general

Faith (35:35):

Just yelling, just everyone’s yelling. And, you know, “experts” and hot takes and the, and threads that feel like are written with such urgency that you’re like, Oh my God, wait, am I doing everything wrong? And I find, especially Lenny’s podcast to be so powerful, but also like, gentle, right? Like you just, the way the topics are kind of approached—it’s a delight to listen to. So if you haven’t listened to it, I recommend it. This podcast is not sponsored by Lenny’s podcast <laugh>.

Grey (36:12):

Love a good tip. Yeah, that’s cool. It’ll go on the playlist.

Faith (36:15):

Yeah, for sure. On your non-com commute. Really full circle. 

Grey (36:21):

From my office to the kitchen.