#124 – When doors become hallways: A repeatable product-building process (Scott Klein & Mike Haney)

What does it mean to be a product person? Product managers are responsible for shaping the product, shipping the product, and syncing their people. Being in charge of product isn’t easy, but it’s a vital role for any company. In this episode, Levels Editorial Director Mike Haney chatted with our Head of Product, Scott Klein. They explored Scott’s role in our company, what it means to be a Head of Product, and how the functional area of product works in a remote async environment.

07:15 – Product is a tough role

People often come laterally into the product field because there isn’t a straightforward path to being a product manager.

People don’t go to school for four years to get a Bachelor’s of Science in product management. You’ve got very famous colleges like RISD or SCAD, where you might go get a design degree. You could go to Harvard or Stanford for computer science. There’s no equivalent for product management. And we often see people coming in laterally into the field because it’s this cross functional mix of, you got to kind of know how software gets built, you got to kind of know how people interact with software products, you got to kind of know how designers work and what makes them tick and get them to do good work, and then you got to put it all together in a way that is largely in the background. I think when PM is really functioning well, it largely goes unnoticed. The trains are just running on time. People feel like there’s predictability. We’re still working toward getting that, a lot of predictability and reliability here at Levels. But it just sort of recedes into the background, and it just seems like the people that are actually “producing” the stuff, I’ll use heavy air quotes for “producing the stuff,” but the code, the designs, it’s just all running in a way that feels smooth. So that’s what we mean when we say product.

11:03 – Focus on the customer experience

When numbers can’t get you to the right solution for a feature, it’s time to look to the customer experience.

Take a feature like scoring, for example. Inside the product, we have zone scores and we have metabolic day scores. There’s some friction right now about how people feel about the metabolic day score. It may feel a little bit punitive, a little bit punishing. This is a good example of a feature where there’s not a lot of numbers that can help get you to the right solution. There needs to be an immense focus on the customer experience, what they’re looking to get out of it, why they feel the way that they feel, and then working with designers specifically to see if we can solve this using pixels, using interactions that can lead to a much better emotional outcome for the user. So I think we’re already actually just really deep on the GM scientist bench. They’re not formally part of the product org, but they’re serving that function inside of the company in a way that we don’t have to show up in that manner. So we’re looking to complete the other side of it.

17:45 – Do more experiments

Experimentation is an important part of the product process, especially when you’re a young company or creating a new product.

When we think about experiments, let’s take growth for example, it’s very easy to run a growth experiment where we might AB test an email subject line. And within 24 hours, we get back a quantitative answer about which email subject line was performing good. It’s easy to talk about those as experiments, because they’re easy to implement, they turn over quickly, and there’s a quantitative number at the end of it. But I knew that we had a lot of appetite to experiment, especially in the early stages of the product building, so talking to customers, doing some design work. But that we needed to just find a way to call that an experiment. The early parts of the memo were really saying, “Hey. We have a very experimental product organization, it just looks a little bit different than what you would think about, in terms of, for example, a gross product experiment.” And so we talked about the commonalities of having understanding of the problem, coming up with a hypothesis…So almost in line with the scientific method word for word, coming up with a thesis for how to solve this problem, and then running through a solution, and the solution in this case is not going to production code and actually releasing something to the wider user base. It might be a static screenshot. It could be a clickable prototype in Figma. But that these are actually experiments under the hood. We’re just running more on qualitative data and a little bit of quantitative data to help guide us, as opposed to quick turnaround, one hour change quantitative results type of feedback situations.

19:46 – Be thoughtful about changes

As your company and your product grows, you have to be more and more thoughtful about how you make changes to the product.

I think as we grow, and especially as the surface area of the product gets a little bit more complex, we need to just take maybe one step back and be a little bit more thoughtful about the changes that we’re going to make, the impact that it’s going to make. How do we test along the way to validate and make sure we’re on the right track? And so it was really a function of trying to figure out, “Well, who’s in the room at what time?” So in the early phases we’ve got, like I said, in the shaping phase, we’ve got PM and design that are driving a lot of the work, and then engineering gets more involved as time goes on. And I think in a more general statement way, our investment in this experiment is increasing as our conviction about its success goes up. Along the way, we’re sort of testing, we build a little bit, we show it to members, we build a little bit more, we show it to members. We spec out a little bit more, we show it to members. As long as we’re continuing to gain conviction, by the end, we’re investing a lot of time and resources just in terms of our time to get this thing built. And so it was, “How do we increase that investment in lockstep and make sure that every phase change along the way, that the people that are in the room are the right people, and we can have a pretty explicit thumbs up to say, ‘Yep, I think we’re on the right track, let’s keep going,’ or, ‘Hey, maybe we missed a little bit, we need to back up and recalibrate a little bit’?”

22:42 – It’s not just a numbers game

With every product you have to clear a minimum threshold of numbers, but after that it’s more about feel than the numbers alone.

I think that there’s more of a diligence to do across your user base, as opposed to just a numbers game. I think it’s easy to just run volume through it as a way to say, “Well, we did our diligence,” but you then miss on the back side because you didn’t actually get the spread of understanding who your users are and getting a spread of opinions around things. But yeah, I think that there’s definitely a good bit of, you’ve got to clear some minimum threshold in terms of count, just raw numbers. But I think in terms of the conviction to move forward, a lot of it’s on feel, and I think a lot of it is, people have spent decades of their career understanding what that feels like in a way.

23:42 – Land your products

Don’t think about your products as having launched, think about them as already having landed. You need to have confidence in the success of your products.

I think part of that phase gating forces you to be honest with yourself about how things are going, because we don’t just want to get to the building phase. We actually want to spend time building stuff that we know is going to land. Our Head of Design comes from Google, and one of the Google-isms that he brought in is that we shouldn’t go and think about products as having launched, we should think about them as having landed. I think what that means is, by the time you get to the point that you’re releasing widely to the customer base, you should have a pretty good idea about how things are going to land with them, and not as this rocket launch that we’re just hoping is successful and gets to orbit.

25:06 – Focus on alignment

When you’re working in an asynchronous organization, you have to work extra hard to make sure everyone is aligned.

One of the things that I think has been maybe the most hard to get right is really understanding when you have alignment. When I think back to the friction points that we’ve had in the past couple months, it generally stems back to, “Hey, I thought we were in agreement that we were going to do this thing?” And it turns out we aren’t. I’m trying to personally figure out how we get way more explicit about being in alignment. About doing projects in the first place, what problems these projects are trying to solve. When we have concerns, how do we resolve them in a way that everybody is feeling resolved instead of, we just had one conversation about it and there’s still some unresolved in this? There’s something, I think, about being in the room and having the fidelity of body language and facial expression that at least in my past roles, this concept of alignment hasn’t come up nearly as fiercely as it has at Levels. I should say that all of it is in good nature. People are wanting to move forward. Developers are excited to start building stuff. We’ve got designers that are really digging into wanting to solve some of the hairier interaction problems, and just really providing value in terms of the Levels app. And so we have to make sure that we’re not completely snuffing out and killing people’s fire to go work on these meatier things.

36:52 – Good async enables good sync

When your company is mostly asynchronous, that puts a lot more pressure on your synchronous communication. If you prep in async, you can make the most of your real-time meetings.

I think alignment and approval, if you want to call it that, these are the toughest meetings, because we’ve spent tens or hundreds of hours of work, and it’s the one 60 or 90 minute period where everybody’s expected to have done a pre-read, come in, and say, “Are we good to go on? Because we’re about to invest another 400 collective hours in this. Are you ready to go?” But we’re only going to have that one meeting, right? We’re going to have a one hour meeting to spend 400 more hours of work. That amount of leverage, I think, makes these things really hard, because if we miss, we miss in a big way, and we don’t want to do that. So yeah, when we think about literally having your name on the line, put an emoji, check the thing, tag your thing in Notion, whatever it is in a way that is the most affirmative assent possible that you can give to that, it seems so dumb in a way, but this is the entanglement that we have to have, where we’re going to get 90 to 95 percent of the benefit doing the async thing in our work culture way. But for that last bit, it’s so important that we get it right, especially with the people that we have in the room, that we got to do this weird thing that just feels weird, but it enables that first 95% to begin with.

40:40 – When a door becomes a hallway

The longer you work on a product or commit to a process, the harder it is to turn back because you’ve invested so much time in it.

I tend to think about these also too, as the org grows, that they kind of become two-way hallways instead of doors. You open a door, you can walk right back through it, but hallways you have to walk down. And so I think as the org grows, you run into longer and longer hallways where sure, we could easily turn around and go back, but you’ve got to walk that time back. Especially in product where we’re about to spend hundreds of engineering hours working on something, we just want to make sure that as we get through the hallway, it’s still a two way hallway, as we get further and further down the hallway, are we still comfortable with being in the hallway in the first place? I think that’s a lot of what the product creation process memo was for, was, “I don’t want to fly blind down a very long hallway for a long time, and then hope when we get to the end of it that we’re in a good place.” We have a lot of facilities along the way to make sure that there’s lights on the floor and there’s a path and we’ve got something at the end of the tunnel that’s telling us how far we’ve got left. And there’s more people in this hallway journey with us that we can talk as we’re going. I don’t want us to run those hallways alone, because to walk all the way back takes a long time. And so it’s still two way, but it’s still wasted time at the end of the day, and just make sure that we’re cutting down on the amount of wasted time that we have.

46:08 – Making real-time decisions

Product managers are the ones who have to call the final shots and make the last decisions, which is a lot of pressure.

One of the fundamental powers that a product manager holds is something that I call last mile decision making. You talked about this as being an editor. You’re not doing the photos, you’re not doing the initial copy, because you want those people to push as far as they can into their craft and really test the limits of what’s possible, and it’s up to you as the editor to make the final trade off calls around, “Here’s what our readership needs.” PM is the same way. You want design pushing the boundary as much as possible. You want engineering pushing the boundary on speed and care-taking for the app as a whole into the future, and it’s up to us to make trade off calls in real time about what’s important. And when you cross that last mile decision making up with remotes and the fact that we’re not in the same room, and there’s a lot of emotional energy that gets exchanged as part of that last mile decision making, that’s been the hardest to do. And I think you can compensate some of it by just communicating.

Scott Klein (00:06):

Our head of design comes from Google, and one of the Google-isms that he brought in is that we shouldn’t go and think about products as having launched, we should think about them as having landed. I think what that means is, by the time you get to the point that you’re releasing widely to the customer base, you should have a pretty good idea about how things are going to land with them, and not as this rocket launch that we’re just hoping is successful and gets to orbit.

Ben Grynol (00:35):

I’m Ben Grynol, part of the early startup team here at Levels. We’re building tech that helps people to understand their metabolic health, and this is your front row seat to everything we do. This is a whole new level.

Mike Haney (01:02):

As Ben says at the top of each one of these episodes, part of why we make this podcast is to give people a peek inside what we’re doing here at Levels, what we’re building and how we’re building it. Sometimes that’s for the benefit of folks outside the company, listening to these shows and wondering, “Yeah, how do they do asynchronous internal communications?” or “How do they make decisions when they’re remote?” But sometimes it’s actually for the folks inside the company.

Mike Haney (01:25):

I think we’ve all found an awful lot of value, as members of the Levels team, in some of these episodes that help us learn more about either some of our coworkers or other parts of the company that maybe we don’t interact with as much. Today’s episode is very much in that vein. It’s about diving into specific functional areas of the company, and just trying to reveal more about what do they do, how do they work, and how are they unique here at Levels?

Mike Haney (01:50):

I’m Mike Haney, Editorial Director here at Levels, and today I had a conversation with Scott Klein, who’s our Head of Product. I had this conversation because I am not part of the product organization, although I do have some experience in product, which we talk about a little bit in this episode. But I really wanted to approach this conversation as somebody who’s not super familiar with what product does and particularly how product works in a remote async company at this particular phase of being a startup. That’s where Scott and I kicked it off, was defining what product looks like and what it means to do it here at Levels. Here’s my chat with Scott.

Mike Haney (02:32):

I thought maybe where we’d start, we’re going to get into some of the details about what’s on Scott’s mind now, there’s a couple of pretty interesting memos that have come out. I think we’re at a pretty interesting point for the product for the company. I guess in an early stage startup, you could probably pinpoint any point as being interesting, but being here a year and a half, this feels particularly interesting to me. It just feels very rapid, lots of change and maybe more consequences than in the past. But maybe just to level-set all of that, it might be helpful to go back and just establish what we mean when we say product.

Mike Haney (03:05):

As a little bit of background in this, my suggestion for these podcasts was that people who are not in this functional area should do the interview. So I’m the Editorial Director, I’m a journalist by training, I am not a product person. That said, I spent three years as a product owner. I was part of a project that became a software company. I was a co-founder, and I was sort of the prototypical user, which means I was the one always telling the developers early on, “Oh, it should do this” and “What if it did that?”

Mike Haney (03:33):

I was accidentally creating user stories, and at some point, somebody’s like, “You know, what you are is, you’re the product owner.” And then I became the product owner and I had to figure out what that job was, and I read Lean Startup and all the books and I did it for three years, and then finally went, “You know what? This is just not my expertise.” And I started meeting people like yourself who had done this for years, and I was like, “Oh, they know what it means to do this and live and breathe it and understand it,” and we hired proper product people and I went back to doing word stuff.

Mike Haney (04:02):

So I have some familiarity with it, but I also know what it’s like when somebody goes, “Oh, I own the product,” to go, “What does that mean?” Particularly in the context of a software product. You say product to most people and they go, “Right, a thing that’s made in a factory and then sold on shelves.” So what do we mean when we say product here? What encompasses the product organization at Levels?

Scott Klein (04:22):

You know, product in general, and I think product managers, it’s such an amorphous blob of a title. We’re actually just getting kicked off, I think actually hiring our first product manager that wasn’t a co-founder, or I came in laterally to work on product and was hired as a software engineer.

Scott Klein (04:38):

In all these intro calls, I spend so much time talking to these people about what type of product person they are. Because you’re right, people have titles like Product Lead, Product Owner, Product Manager, Director of Product, VP of Product. And they all have different flavors, and you might hire different flavors based on what your product organization needs at the time. When we think about product though, there’s a couple frameworks we can maybe use to couch what we mean by a product person. And these are largely dictated by the activities that I think a product manager will substantially spend their time doing.

Scott Klein (05:12):

One of the frameworks that we think about in terms of activities, I borrowed from somebody named Lenny. Product managers are responsible for shaping the product, which is deciding what it should look like, feel like, how it should interact. What do people substantially emotionally feel when they use the product? They’re responsible for shipping the product. So, how do we actually get the engineers and the designers tasked with creating user stories, delivering code, testing it, making sure that it functions well, scoping what’s in, what’s out? And the third thing that they do is sync the people.

Scott Klein (05:44):

So it’s a lot about communications, driving schedules, planning for different projects going on, making sure the resources are allocated. This is the shape-ship-sync framework that you can think about. Maybe one more way to think about how we think about product and largely the activities that we’re working on, I presented as part of the “What is product?” memo that I wrote coming into this role this triangle, if you will.

Scott Klein (06:08):

Ust imagine a triangle if you can, I know we’re in podcast format. But there’s three legs to the triangle that we can talk about. There’s the general manager role. A product owner might substantially function in the GM role. You’ve got the artist role. This is something where you work heavily with design. This is very user centered work. How are things supposed to interact and feel when we present the product to the user? And then there’s the scientist portion. This is, what does our funnel look like? What features are getting adopted? Are they activating well? Is there specific features of the product that are leading to more conversion or more revenue? That’s the scientist leg.

Scott Klein (06:39):

And the main, maybe, piece of this triangle to know is that most product managers generally fall on one of the edges between two of the legs. It’s exceedingly rare to get somebody who’s actually really, really good at all three of GM, artist, and scientist. When we go to hire for PM like we’re doing right now, we’re saying very explicitly, “Hey, we really need a GM artist that’s going to be able to come in, help define features, and then help see them through to completion when we go to build them.” So that’s maybe just a couple frameworks to sort of help think about what we mean when we talk about product.

Scott Klein (07:14):

But product is a tough role, I will say, as well, because people don’t go to school for four years to get a Bachelor’s of Science in product management. You’ve got very famous colleges like RISD or SCAD, where you might go get a design degree. You could go to Harvard or Stanford for computer science. There’s no equivalent for product management. And we often see people coming in laterally into the field because it’s this cross functional mix of, you got to kind of know how software gets built, you got to kind of know how people interact with software products, you got to kind of know how designers work and what makes them tick and get them to do good work, and then you got to put it all together in a way that is largely in the background.

Scott Klein (07:53):

I think when PM is really functioning well, it largely goes unnoticed. The trains are just running on time. People feel like there’s predictability. We’re still working toward getting that, a lot of predictability and reliability here at Levels. But it just sort of recedes into the background, and it just seems like the people that are actually “producing” the stuff, I’ll use heavy air quotes for “producing the stuff,” but the code, the designs, it’s just all running in a way that feels smooth. So that’s what we mean when we say product.

Mike Haney (08:21):

Yeah. I had a similar thought, or at least the analogy that I was able to draw when I was doing product work was, it’s very similar to an editor’s role when we think about creating content, which is, the editor’s not writing the words, they’re not taking the pictures. They’re the people behind the scenes, assigning and shaping and helping to do it. I always liked that part of editing. I liked the idea that you were very much driving the bus, but nobody knew you were there, and if you did your job great, the success is that people don’t know you’re doing anything. And it feels like PM is the same.

Mike Haney (08:53):

I’m curious on that. I found that triangle analogy really helpful, or that triangle diagram, to think about those three aspects of product management, product ownership. When you talk about, “We’re looking for somebody who’s that GM and artist role,” what is it about the organization that allows us to focus the product there and less on the scientists? Is it that there are other roles here that are fulfilling that part of it? Or how do you think about structuring the overall engineering or, I guess product would be the largest umbrella for that part of the company, that would encompass design, product, people, and engineering, to stand up all three of those legs of the stool, to mix our metaphors here?

Scott Klein (09:41):

Yeah, yeah.

Scott Klein (09:43):

To answer your question directly, where we’re at as a company right now in terms of the people that we have at the organization, we have a lot of people that in another company you could make the case that they’re functioning in a product role already. They just tend to be on the GM scientist leg of the triangle.

Scott Klein (10:01):

We have a number of people that we say that we’ve hired into GM roles, and these people are generally across things like our funnel tracking, CGM subscription rates, demographics of the users. So I would actually make the case that these are actually already product people. We already have these people functioning as product people. But the way that we’ve just drawn the lines around what a product manager is, they’re not explicitly included.

Scott Klein (10:28):

And so the reason we’re focusing on GM and artists, that leg right now, is because we already have a lot of people on the GM scientist leg that are well across the metrics, the strategy, the overall landscape of where we’re heading as a business and the current results of who our customers are and how they’re performing in terms of revenue or whatever. We already have a lot of those people. So I think we’re a little bit light on the GM artist side of it.

Scott Klein (10:51):

And I think really, symptomatically, how this shows up is, when we’ve got new greenfield features, specifically ones that are highly ambiguous to start out with… So we take a feature like scoring, for example. Inside the product, we have zone scores and we have metabolic day scores. There’s some friction right now about how people feel about the metabolic day score. It may feel a little bit punitive, a little bit punishing.

Scott Klein (11:16):

This is a good example of a feature where there’s not a lot of numbers that can help get you to the right solution. There needs to be an immense focus on the customer experience, what they’re looking to get out of it, why they feel the way that they feel, and then working with designers specifically to see if we can solve this using pixels, using interactions that can lead to a much better emotional outcome for the user.

Scott Klein (11:38):

So I think we’re already actually just really deep on the GM scientist bench. They’re not formally part of the product org, but they’re serving that function inside of the company in a way that we don’t have to show up in that manner. So we’re looking to complete the other side of it.

Mike Haney (11:53):

Can you say a little bit more about how the product role, whether that’s you or whether that’s the new person we’ll ultimately hire, what do their day to day interactions look like with the other legs of the product stool of design and with engineers? How do you communicate? What kinds of information, metrics, requirements et cetera are you trading back and forth?

Scott Klein (12:14):

Yeah. Yeah. Well, I think what they’re doing on a day to day basis depends largely on what phase of a project we’re in. A couple weeks ago I took a week to write the first draft of a memo toward us building a repeatable product building flow or product creation process. And one of the things that that memo tried to set out to clarify was that specifically a GM artist type of product manager, they go through two very distinct phases. When we’re building, let’s say, a new feature, we’re trying to rethink or realign on a new feature.

Scott Klein (12:46):

So you take that scoring feature I just talked about. At the early outset of a feature like that, where we’re trying to reimagine the way that we score people’s day based on CGM data, based on their food log data, based on their exercise data that they bring in, you’re going to be spending a lot of time upfront with the design function of the org and the customers, really trying to understand, “What is it that we’re doing right now that’s working? What is it we’re doing right now that’s not working? And how can we just think about, well before we lay down any lines of code…” Engineers are maybe in the room just to get information and to see the process work out. But we’re really trying to understand from the design and usability standpoint, “What are you trying to get done as a customer, and how can we do better for you? How can we show up better for you?”

Scott Klein (13:32):

This is substantially what I call the shaping function of a product manager role. You’re spending so much time without actually formalizing a solution. We’re really just trying to understand, “Do we understand the problem? Do we understand exactly…” A lot of times problems will show up proximately in one area, but the root cause may be a couple layers down the stack. Can we drill down the stack in a way that we really start to understand the emotional pain there for the customer?

Scott Klein (13:54):

And then once we feel like we’ve got good clarity on that, we can continue to work just with design to do maybe some static mock-ups or some clickable walkthroughs, put them back in front of customers. Are they testing well? Do we feel like they’re responding qualitatively in a way that we really enjoy? And then that shaping part of your job starts to ramp down, once we get confidence around what we’re doing, and the shipping part of your job starts to ramp up.

Scott Klein (14:18):

This is really when you start to interface with engineering. They’re not coming in blind, but it’s time to operationalize. So we’re creating tickets, we’re coming up with milestones, we’re scoping, what’s in, what’s out? Doing some t-shirt size estimates. Do we feel like we have a grapple on what we’re about to build?

Scott Klein (14:33):

And so these two big buckets of work, I guess shipping and shaping, you start with the shaping function as almost a hundred percent of your time. And then as the project moves through the phases, the shaping starts to ramp down because we’ve got clarity, and the shipping function ramps up. And then you’re really in ship mode until you get something built, launched, tested, verified. And then when we iterate, the levers come down and up respectively again.

Scott Klein (14:56):

So you’re back into shaping mode. “Okay, we’ve got some data. Where do we go from here? Is it time to invest more? Do we feel like we’ve substantially solved the problem? And we sort of go from there. PMs may be working on separate projects all at the same time, but based on the phase of the project that they’re in, is usually when they’re either in product shaping mode versus project shipping mode.”

Mike Haney (15:17):

That’s a really helpful visual. I like the idea of those levers going up and down. Maybe unpack a little bit more the memo you just worked on, the idea of a repeatable process. What led you to work on this, and what kind of insights did you find, or what did you illuminate as you worked on that memo?

Scott Klein (15:35):

The biggest thing that I think that we are grappling with, maybe more as a company and not just for product in particular, is we talk about having this cultural value of wanting to experiment, really embracing experiments, in a way that we are both listening to our customers, but also wanting to try new things, and understanding that we cannot sit in an ivory tower and just think about the right answers all day long. We actually need to ship stuff in a way that we can test our assumptions and validate them and feed those learnings back into the work that we’re doing later on down the road.

Scott Klein (16:09):

One of the things that the memo, I think, really unpacked, or that I had to really explore was, as I went into writing the memo, I had a lot of unease about thinking about, how do we balance being a very thoughtful and deliberate product organization with also being a high velocity product organization? I think on one failure case, if… I can paint both failure cases. One failure case is, you sit in a room, you don’t talk to any customers until you feel like you have the perfect solution, and then you build that, still not talking to anybody, and hope that it lands really well. This takes forever. You’re oftentimes off in ways that take a while to recover from.

Scott Klein (16:48):

The other side of the spectrum is the one that I feel like we were maybe tending toward, and that was giving me some pause because I felt like it was equally as unthoughtful, which is to say, “We need to just think of low value, high velocity ideas, and do as many of them as we possibly can.” And it’s almost like you’re got this bag of random seeds that you’re throwing on the ground, and if we water one of them, we’re just going to discover a giant oak tree one day, and that’s going to be this new product direction that we go in.

Scott Klein (17:15):

I think through just my experience, I’ve come to realize that that almost never happens. That every large tree that a product team is able to cultivate is done through proper tending and care and grafting and watering and sunshine over months and years of really cultivating what it is to build a good product. So as part of the memo for the product building process, I really had to come to a definition of what it meant to do experiments from the product team.

Scott Klein (17:44):

Because when we think about experiments, let’s take growth for example, it’s very easy to run a growth experiment where we might AB test an email subject line. And within 24 hours, we get back a quantitative answer about which email subject line was performing good. It’s easy to talk about those as experiments, because they’re easy to implement, they turn over quickly, and there’s a quantitative number at the end of it. But I knew that we had a lot of appetite to experiment, especially in the early stages of the product building, so talking to customers, doing some design work. But that we needed to just find a way to call that an experiments.

Scott Klein (18:21):

The early parts of the memo were really saying, “Hey. We have a very experimental product organization, it just looks a little bit different than what you would think about, in terms of, for example, a gross product experiment.” And so we talked about the commonalities of having understanding of the problem, coming up with a hypothesis…

Scott Klein (18:40):

So almost in line with the scientific method word for word, coming up with a thesis for how to solve this problem, and then running through a solution, and the solution in this case is not going to production code and actually releasing something to the wider user base. It might be a static screenshot. It could be a clickable prototype in Figma. But that these are actually experiments under the hood. We’re just running more on qualitative data and a little bit of quantitative data to help guide us, as opposed to quick turnaround, one hour change quantitative results type of feedback situations.

Scott Klein (19:14):

So yeah, I think that was the first big part of the memo. The second big part was just to paint a picture of who gets involved when. I think that as we get to becoming a larger company, one of the things that I think helps you succeed in the early days of being a startup is tending toward action. So the default should be, whenever there’s problems that come up, we should just tend toward action. Because generally just having somebody say, “I’ll take care of that. I’ll pick up the mantle here,” is a really good start into solving something.

Scott Klein (19:46):

And I think as we grow, and especially as the surface area of the product gets a little bit more complex, we need to just take maybe one step back and be a little bit more thoughtful about the changes that we’re going to make, the impact that it’s going to make. How do we test along the way to validate and make sure we’re on the right track? And so it was really a function of trying to figure out, “Well, who’s in the room at what time?”

Scott Klein (20:06):

So in the early phases we’ve got, like I said, in the shaping phase, we’ve got PM and design that are driving a lot of the work, and then engineering gets more involved as time goes on. And I think in a more general statement way, our investment in this experiment is increasing as our conviction about its success goes up.

Scott Klein (20:25):

Along the way, we’re sort of testing, we build a little bit, we show it to members, we build a little bit more, we show it to members. We spec out a little bit more, we show it to members. As long as we’re continuing to gain conviction, by the end, we’re investing a lot of time and resources just in terms of our time to get this thing built.

Scott Klein (20:40):

And so it was, “How do we increase that investment in lockstep and make sure that every phase change along the way, that the people that are in the room are the right people, and we can have a pretty explicit thumbs up to say, ‘Yep, I think we’re on the right track, let’s keep going,’ or, ‘Hey, maybe we missed a little bit, we need to back up and recalibrate a little bit’?” That’s what the memo addressed.

Mike Haney (21:00):

I’m curious about that experimentation phase, the edge cases or the failure cases at either end make perfect sense. As you say, the messiness is in the middle, right? So how do you think about how many small experiments to run, or how much data to get along the way, before a project can be marked as effectively done? Obviously the whole product is always in iteration. We will keep improving, we will keep making changes, particularly at this phase of the company. But at some point, scoring for instance, you’re just going to have to put it to bed and move on to a next thing. So how do you get a sense of…

Mike Haney (21:37):

Is it something you’re able to plot out at the beginning of this process, or is it something you find as you go to say, “We’re going to put 10 iterations in front of 50 customers each, and that’s going to give us the amount of data we need”? Or is it more of a feel thing of, “Boy, they really hated this one, but by the second time, we got pretty much all thumbs up, so I think we’re good. Let’s keep rolling”? How do you know how to sort out that middle between overbuilding, over-perfecting, and over-experimentation, and just continuously noodling and nothing ever gets done?

Scott Klein (22:12):

That’s a good question. My personal approach is less about numbers of customers that we put it in front of, and more, did we do enough diligence on the spread of the types of customers that we put it in front of? So when we think about something like scoring, have we hit our existing users with it? Did we hit a brand new user with it? Did we hit a very metabolically capable already person with it, versus a beginner who’s just coming into this system?

Scott Klein (22:42):

I think that there’s more of a diligence to do across your user base, as opposed to just a numbers game. I think it’s easy to just run volume through it as a way to say, “Well, we did our diligence,” but you then miss on the back side because you didn’t actually get the spread of understanding who your users are and getting a spread of opinions around things.

Scott Klein (23:00):

But yeah, I think that there’s definitely a good bit of, you’ve got to clear some minimum threshold in terms of count, just raw numbers. But I think in terms of the conviction to move forward, a lot of it’s on feel, and I think a lot of it is, people have spent decades of their career understanding what that feels like in a way.

Scott Klein (23:21):

Part of what the memo did was try to create what I’m calling phase gating, just to say, “Hey, let’s say we come up with some designs, we talk to 10 customers. Are we able to create couple super clips and a couple thematic things that we can pull out of those interviews, and go to people outside of the process so far, and tell a narrative that they buy, that makes sense, that they believe in?” And I think part of that phase gating forces you to be honest with yourself about how things are going, because we don’t just want to get to the building phase. We actually want to spend time building stuff that we know is going to land.

Scott Klein (23:54):

Our Head of Design comes from Google, and one of the Google-isms that he brought in is that we shouldn’t go and think about products as having launched, we should think about them as having landed. I think what that means is, by the time you get to the point that you’re releasing widely to the customer base, you should have a pretty good idea about how things are going to land with them, and not as this rocket launch that we’re just hoping is successful and gets to orbit. Does this make sense about just the approach that we’re taking?

Mike Haney (24:22):

I like that a lot. I remember the brief time I spent doing this work, the amount of anxiety I would have around releasing a feature, no matter what we had done, was crippling for that reason, because it is the, “We’ve worked on this for six months, and now boom, everybody.” And not an insignificant amount of times, you would have at least some portion of the user base that goes, “What the hell’s wrong with you people? Why would you do this to me? I hate you.” And that’s challenging.

Mike Haney (24:53):

I like the notion of landed. I want to shift slightly, although I suspect this very much relates back to what we’ve just been talking about, which is, how is product different in a remote async company?

Scott Klein (25:06):

One of the things that I think has been maybe the most hard to get right is really understanding when you have alignment. When I think back to the friction points that we’ve had in the past couple months, it generally stems back to, “Hey, I thought we were in agreement that we were going to do this thing?” And it turns out we aren’t.

Scott Klein (25:34):

I’m trying to personally figure out how we get way more explicit about being in alignment. About doing projects in the first place, what problems these projects are trying to solve. When we have concerns, how do we resolve them in a way that everybody is feeling resolved instead of, we just had one conversation about it and there’s still some unresolved in this? There’s something, I think, about being in the room and having the fidelity of body language and facial expression that at least in my past roles, this concept of alignment hasn’t come up nearly as fiercely as it has at Levels.

Scott Klein (26:16):

I should say that all of it is in good nature. People are wanting to move forward. Developers are excited to start building stuff. We’ve got designers that are really digging into wanting to solve some of the hairier interaction problems, and just really providing value in terms of the Levels app. And so we have to make sure that we’re not completely snuffing out and killing people’s fire to go work on these meatier things.

Scott Klein (26:43):

But in terms of product, I think a successful product process is one where you’re not surprised late in the game that people are working on stuff that we weren’t really sure they should be working on, or that we’re building something for a problem that we weren’t sure was a problem in the first place.

Scott Klein (27:02):

I was scared to put in the memo the thing around phase gating, but I think it was in response to us having very blurry boundaries in between us understanding the problem and us moving to design, or us starting with design and then moving to development. It all just ran together in a way that we were missing the amount of alignment that we needed to really say, “Okay, yes. Everybody that has a vested interest in this project is actually thumbs up, signature on the line. We’re ready to move forward with the next phase.”

Scott Klein (27:29):

I think this is maybe the toughest thing for us, is balancing that as a startup, we’re hiring people with a lot of fire in the belly. They generally will take initiative rather than waiting to be told it’s okay to do something. And so we can oftentimes leapfrog ahead when we’re not quite ready to go.

Scott Klein (27:45):

And so how do we balance those two things without there being that collective group in the room where you can see people’s unease, or you can see people wondering about something, or you might see somebody in the one desk over working on a project, you just pop over and say, “Hey, tell me what you’re working on here, because I didn’t think we were getting started on this quite yet.” There’s a lot of just incidental body language and noticing of working on things that can go unchecked for weeks or months at a time, and then in the worst case, we just run into issues a little while later.

Scott Klein (28:17):

So that’s probably been the hardest thing at async and remote, is just clarity and alignment about where we are on the project, and everyone’s buy-in for whether we’re ready to go or not.

Mike Haney (28:26):

That resonates, because when I did my brief in as a product person, our company was split between Sweden and the US, and the entire development team was in Sweden. And so for two to three years, I would go one week a month to Sweden, for that exact reason, to be in the room with the group of devs when we talked about the sprint planning or we went over the user stories or we did whatever, and I can still picture the kinds of responses you’re talking about when I’d go, “Hey, so and so. Feels like maybe you have a thought about that, or like that’s not quite working.” Or just somebody would jump up to a whiteboard and scribble a thing, and then you’d all talk about it.

Mike Haney (29:01):

I think about that all the time here when I think about you guys running this side of the company fully remotely and how you get over some of those things. And we should say as context, this is I think a challenge that we’re working through right now in the company at large, which is at this point in our growth, we’re a little over 50 employees now, how do we get alignment on projects and initiatives and priorities across the company? How do we make decisions? How do we know when something’s finalized? We’re obviously very memo heavy here, but comments and memos are not quite cutting it anymore as a way to say, “Yeah, I think we’re good on this.”

Mike Haney (29:39):

We need more process. And it sounds like part of the solution to this challenge within the engineering, or the product organization, rather, is process. That you’re just having to put a little bit more bureaucracy, for lack of a better word, onto what happens, and that that’s probably an inevitable part of growth.

Scott Klein (29:59):

I think it scares us, to be honest. I think it scares me. I think that part of us joining a startup is that you have a bit of an allergy to heavy process, heavy bureaucracy. And so you have these extremely fierce counteracting principles of, we’re missing fidelity because of the remote situation, so we want to add some process, but we’re small and we don’t want to behave too corporate-y to start out with. On a more general level, I think I’ve been here not quite a year yet, but I’m noticing that there’s sort of this forced entanglement of, when you go remote, you maybe get 90% of the benefit, but you have to lean so hard into the final 10% for it really to compliment and work well.

Scott Klein (30:46):

None of us want to be remote and be on Zoom all day, for example. We have a lot of time in space to run our own schedules. Even the first time I spent time with people at the company in person… So much of our time is in our own homes and whatever. Spending time with people in person, it was just a generational leap in my relationship with them. So I think about the entanglement of, “Let’s be remote and async,” but I have to get on a plane a couple times a year and just go see the people that I work most intimately with. Not so that we can talk about work, but just like, “How are your kids doing? What’s your wife up to?” Just to build that personal basis for me to better give you feedback about your work and understand you as a whole individual.

Scott Klein (31:25):

I think the same thing with when we talk about being… we have this external posture of being extremely async, but I think as we’ve grown, especially in the last, I would even say three months, we’re noticing a lot more synchronous meetings, because what used to work for us, async, is missing the last 10%. So we have to lean as hard as we can into that final 10% being synchronous.

Scott Klein (31:45):

Otherwise, we’re just trading one set of problems for the next. If you just go from completely sync to completely async, I’m not sure it’s on balance fundamentally better. You just have a different set of problems. So yeah, when I think about product and I think about this entanglement, there is a big piece of, we’re going to get 90% of the benefit, but the last 10%, we have to do in a way that may seem counter to our values, but it’s only at the end result of us committing to that value to begin with. Does that make sense?

Mike Haney (32:14):

Yeah, that makes perfect sense. I’m reminded of something that came up. We had a recent all company chat about this decision making process, and Sam, our CEO, saying in that meeting, “None of us wants to be in a situation where people are putting meetings on our calendar all day long and we’re spending the day in sync calls. But we shouldn’t lean so hard into async that we are not having sync calls when they are just what is necessary to make a decision.”

Mike Haney (32:40):

I kind of think about it from the perspective of… And maybe this is just because I’ve been here a year and a half now, and so I’ve had some practice in internalizing the async remote nature and being able to think of that first, that that’s become my baseline. I think when you start here, if you come from a synchronous company, which a lot of people are, that’s your baseline, and everything you’re doing async and remote feels weird, and you have to force yourself into, “Oh, I shouldn’t just call this person. I should look in Notion for the answer, or I should write this as a memo instead of just sending an email.”

Mike Haney (33:15):

But once you’ve been here a while and you start to establish those as your baseline, then I think it becomes a lot easier to go, “You know what? I can just get on the phone and have an hour call with Ben, and it doesn’t mean that we’re now a synchronous company. It doesn’t mean that he and I are bugging each other. It doesn’t mean we’re going to do this all the time.” Sometimes you just have to do those things, especially as you get bigger.

Mike Haney (33:39):

I’ve been thinking a lot about where, again, process, not to get too bureaucratic, but where process can help alleviate some of that as well. One of the things I think we do pretty well here is, because we’re so intentional about sync calls and conversations or interactions, we prep a lot beforehand. You go into those calls having exchanged a bunch of threads, written a memo, commented on the memo, probably said, “Hey, here’s the three things I want to get to in this call that we’re going to market as a decision that feels very different than meetings I used to be in.”

Mike Haney (34:13):

Even product meetings where there was a real delineated, desired outcome of, “Hey, we have to plan a sprint,” or, “We have to solve this user story.” Those things can still just get meandering, and you end up in some other tangent, and I feel like we’re better here at not doing that. And I think part of it’s because we put this process in place of, “Look before you get on a sync call, here’s what we’re going to do,” or, “Here’s the memo format we’re going to fill out.” And I know you guys do a lot of documentation on the product side. I’m curious if that’s been your experience as well.

Scott Klein (34:42):

It totally has. I can give one example. Most software teams will run some sort of scrum, agile sprint planning, whatever you want to call it. We’re not an adherent to a specific wing of that worship style. But we started trying to do completely self-directed async sprint planning, and it was going okay, but it never got to a great spot. But I’m glad that we tried it, because it gave us a lot of material and fodder to back it off a little bit when the time was right.

Scott Klein (35:14):

I’m hiring for a PM right now to work with us, and what I tell them is that we default pretty hard to async as an opening move, and then when we need to reel it back in, we can. And oftentimes that’s exactly the right move. But to your point, you’re right. The sync time that we do have is very clear and directed. I think we respect people’s time in that way.

Scott Klein (35:35):

So to where we ended up on the sprint planning side of things is, we moved from async to sync, but then the team got big enough that the sync planning meeting felt like an old bureaucratic sync planning meeting, where everybody was just in the room waiting their turn for two hours, and that also didn’t feel great. So we now have a lot of async allocation up front as much as possible, so that the same time that we do have is extremely efficient and people just end up dropping off when their thing’s done.

Scott Klein (36:01):

I think we’re actually in a really good groove right now, and the feedback from the team has been great, which is, “Hey, you still respect my time. I appreciate the work that you’re doing to put in beforehand, just to get things roughly allocated. When there’s changes, they’re communicated in a way that makes sense.” So I think we’re at a good spot with sprint planning, the sync portion that we have of it, because we tried the async thing first and got a bit of a temperature check on if it was or it was not working.

Scott Klein (36:25):

So yeah, I intend for us to find other things like that in the product org as time goes on. Specifically on alignment though, the one thing that I will say is that some of the toughest things, like alignment meetings, happen when they are… So if you imagine a two by two or a matrix of, you’ve got importance of the decision and frequency by which you make that decision, and there’s this scary quadrant, which is we almost never have the meeting, but it’s really, really important that we get it right. You know?

Scott Klein (36:52):

And I think alignment and approval, if you want to call it that? These are the toughest meetings, because we’ve spent tens or hundreds of hours of work, and it’s the one 60 or 90 minute period where everybody’s expected to have done a pre-read, come in, and say, “Are we good to go on? Because we’re about to invest another 400 collective hours in this. Are you ready to go?” But we’re only going to have that one meeting, right? We’re going to have a one hour meeting to spend 400 more hours of work.

Scott Klein (37:15):

That amount of leverage, I think, makes these things really hard, because if we miss, we miss in a big way, and we don’t want to do that. So yeah, when we think about literally having your name on the line, put an emoji, check the thing, tag your thing in Notion, whatever it is in a way that is the most affirmative assent possible that you can give to that, it seems so dumb in a way. I can’t believe that we [inaudible 00:37:39], but this is the entanglement that we have to have, where we’re going to get 90 to 95 percent of the benefit doing the async thing in our work culture way.

Scott Klein (37:48):

But for that last bit, it’s so important that we get it right, especially with the people that we have in the room, that we got to do this weird thing that just feels weird, but it enables that first 95% to begin with.

Mike Haney (37:58):

I want to talk a little bit about where we’re at in the company right now. Because you just talked about that idea of investing, having certain phases or gated decisions that are going to have a real impact that are really important, because they’re going to direct a lot of work. It made me think about something we talk a lot here about, of decisions being two-way doors, that part of the reason we don’t run a lot of fire drills, we run a relatively low stress organization, is that we believe most decisions are two-way doors.

Mike Haney (38:25):

But one of the things I’ve noticed is that as the company grows, as we get more members, as we approach lift off and eventually launch general public availability, hopefully multiple times, many more people using our product, that the number of two-way doors we have, or at least what feel like low consequence two-way doors on decisions is going down and decisions just feel more important, they feel weightier, they feel harder to reverse.

Mike Haney (38:50):

And so I’m curious how you’re thinking about that from a product perspective now. Do you feel like we’re at a phase where some of these decisions we’re making are more consequential, that there’s less room… This really is probably back to the experiment conversation, but where there’s less room to just throw stuff out there and try it? And as we leave the intentional, “Hey, we’re in beta, man. We’re just trying to figure it out,” and everybody’s on board with that, and if you sign up for the wait list, we tell you, “Look, this product ain’t baked yet, so be cool with that,” to, “Hey, I paid money for this. Why doesn’t this thing work?” Kind of phase, where do you see product right now in the evolution of the company?

Scott Klein (39:27):

I would say on the face, I very much buy into, people generally will turn things into a one way door when they don’t need to be. What I don’t want to do is conflate the amount of things, sorry, the amount of people that something touches with the amount of time it takes to roll back the decision.

Scott Klein (39:46):

I think that one example is, we’re about to do a new signup flow for some of the new partners that we’re working with, and there was a question of, do we do every 28 day recurring deliveries or do we just do it monthly and you have a two or three day gap at the end of the month? That’s a decision that from an engineering standpoint would be very easy to roll back if we wanted to. So I would easily label that a type two decision. The problem is, it touches so many people that it feels like it’s turning into a one way door.

Scott Klein (40:13):

And so I think we’ve got to be careful to conflate, “Hey, this decision touches growth, it touches ops, it touches membership, it touches development, it touches design, touches five separate groups that need to know about it.” They all might be a two-way door in their own regard. It just starts to masquerade as a one way door because it feels like, “There’s a lot of people I got to go tell about this if we change our mind.” So I think we’ve got to be careful in that regard.

Scott Klein (40:40):

I tend to think about these also too, as the org grows, that they kind of become two-way hallways instead of doors. You open a door, you can walk right back through it, but hallways you have to walk down. And so I think as the org grows, you run into longer and longer hallways where sure, we could easily turn around and go back, but you’ve got to walk that time back. Especially in product where we’re about to spend hundreds of engineering hours working on something, we just want to make sure that as we get through the hallway, it’s still a two way hallway, as we get further and further down the hallway, are we still comfortable with being in the hallway in the first place?

Scott Klein (41:14):

I think that’s a lot of what the product creation process memo was for, was, “I don’t want to fly blind down a very long hallway for a long time, and then hope when we get to the end of it that we’re in a good place.” We have a lot of facilities along the way to make sure that there’s lights on the floor and there’s a path and we’ve got something at the end of the tunnel that’s telling us how far we’ve got left. And there’s more people in this hallway journey with us that we can talk as we’re going.

Scott Klein (41:40):

I don’t want us to run those hallways alone, because to walk all the way back takes a long time. And so it’s still two way, but it’s still wasted time at the end of the day, and [inaudible 00:41:48] just make sure that we’re cutting down on the amount of wasted time that we have.

Mike Haney (41:52):

I think the title for the show is going to be When Doors Become Hallways.

Scott Klein (41:55):

I like it.

Mike Haney (41:58):

I really like that analogy for where we’re at right now.

Mike Haney (42:02):

What are you, broadly speaking, excited about on the product side right now? Given the process changes you’re putting in place, given the growth of the staff we continue to hire in engineering, you’re bringing on a PM, our design staff has grown from one to two, but you know, is growing there as well. And then we’re approaching what feels to me like a really huge moment in the company, when we’re going to have general availability and anybody can go to the website and click Buy.

Mike Haney (42:26):

From a product perspective, I’m sure we could talk about all the things you’re terrified about, or maybe not, maybe you’re better at handling anxiety than I am, but what are you excited about?

Scott Klein (42:37):

I’m excited about us adding one level of thoughtfulness and deliberateness to the way that we’re building stuff. Like I said earlier, I think every startup has to tend toward action if they want to survive. We did the exact right thing for the first couple years of the product’s life, in order to get out and to get feedback and to take that captive first layer of customers and give them something that we could then build upon. But I think as we look to hire experienced designers and experienced product people, they’re all used to working in a certain way that makes sure we cut down and we minimize the amount of wasted time that we have, and that really puts the user at the center.

Scott Klein (43:18):

I think that’s the best part of taking a much more deliberate approach of understanding user pains, coming up with what we feel like is solutions, not in code, but maybe in design and some clickable prototypes. I have the benefit of having interviewed a lot of really senior product managers over the last two weeks. You’re hitting me at the perfect time for this. And what was so cool and exciting to me is that all of them have had really good success in their careers working in this way.

Scott Klein (43:44):

I think PM is a craft. Just like I said, we don’t have a four year degree to go to it. There’s something about PM that over the last maybe five, seven years has really coalesced around how to repeatably build product in a way that minimizes the “launch and hope for the best” mentality, and instead really gets you confident along the way about what you’re building, keeping the user and our members at the center of it the entire way through, such that as we increase our investment in things, there’s no question about why we’re doing this. It should just be very glaringly obvious.

Scott Klein (44:17):

We’ve got a couple projects having to do with the way that people input their food logs and the way that we’re doing scoring, for example, that are really ripe to get this process off the ground, to give it some legs and for people to see, “Hey, just because we’re being a little bit more deliberate and thoughtful upfront, it doesn’t mean we’re sacrificing speed. It doesn’t mean we’re thinking incrementally. We can still think really big, but we’re just doing it in a way that helps us be confident in the way that we’re spending our engineering time.”

Scott Klein (44:45):

So I’m excited that we’ve at least got some language around it, that that language lines up with almost all the PMs that we’re talking to that we could possibly hire, that it aligns well. I just want to see, for people that have been at the company for a while, for them to see, hey, we can keep our speed up if we’re being deliberate about stuff. Because we’re just going to see products roll off the line, and users are going to love it. That’s going to be such a cool moment for us to see.

Scott Klein (45:08):

It seemed like we took maybe a slightly slower or slightly more corporate approach to thinking about product in the way we did it, but things are just working. They’re working in a way that should not be surprising to us. And I think that’s going to be a really exciting moment, that we’re putting thought in the right places, we’re putting time in in the right places, and we’re putting the right people in at the right time in order to get that process to grow.

Mike Haney (45:29):

All right. The last thing I’ll leave you with is, you’ve been at this a while, you’ve you’ve built your own company before coming here. What are you still learning, or what have you learned recently, or what are you still trying to learn about product and about building good product?

Scott Klein (45:45):

I think so much of what I’ve been continuing to learn is how different things can be in a remote context. Your question earlier really spoke to it, that product sits at the nexus of a bunch of other people doing actual work to get stuff realized and brought to life. And one of the fundamental powers that a product manager holds is something that I call last mile decision making.

Scott Klein (46:15):

You talked about this as being an editor, right? You’re not doing the photos, you’re not doing the initial copy, because you want those people to push as far as they can into their craft and really test the limits of what’s possible, and it’s up to you as the editor to make the final trade off calls around, “Here’s what our readership needs.” PM is the same way. You want design pushing the boundary as much as possible. You want engineering pushing the boundary on speed and care-taking for the app as a whole into the future, and it’s up to us to make trade off calls in real time about what’s important. And when you cross that last mile decision making up with remotes and the fact that we’re not in the same room, and there’s a lot of emotional energy that gets exchanged as part of that last mile decision making, that’s been the hardest to do. And I think you can compensate some of it by just communicating.

Scott Klein (47:05):

But I think more to the point, I’m starting to think a lot more about how do we have these higher authority frameworks, documents, approaches that let us all collectively come up with the answers in general, such that when the real time decision making comes into play, it’s not a surprise, and it doesn’t feel like Scott has this fiefdom in product where he’s just the puppet master making the calls and pulling the strings in a way that doesn’t make sense.

Scott Klein (47:31):

And so yeah, much to your question about what’s harder about remote and async, I think we have to put a lot more grown up and deliberate thought into those higher level authority structures or frameworks or ways of thinking, such that when these specific situations come up, no one feels like it came out of left field or that it was random, that it feels like we’ve done the hard work and the hard thinking and the hard trade off calls a lot up front. That in the moment, they’ll make sense in a way that people believe in and can get behind.

Mike Haney (48:02):

Well, I think that’s good place to leave it. Is there anything else you want to say about product? Anything we didn’t get to that you feel like is a useful part of this discussion?

Scott Klein (48:11):

No, I still continue to think product is kind of hard. Funny enough, when I took this role, I had a lot of people tell me, “I don’t know why you’re taking this job, the Head of Product. It’s got to be the worst job in any company, and so good luck.”

Scott Klein (48:29):

But I think it is work that is well worth doing. It’s work that I still continue to find to be fun, and that I’m taking a very much more long term approach to, of I want us to grow the product org up. It’s going to just take a lot of time and effort and putting one foot in front of the next, and we’re going to get to a good spot, where it’s repeatable and people trust it and feel like it’s good, and so I’m excited to get there.

Mike Haney (48:53):

And then it’s going to change all over again, because we’re going to be three times the size with 10 times the members.

Scott Klein (48:57):

Yes. Yeah, we’re going to build it up just to tear it down once it’s done.