Eeke de Milliano on Stripe, Innovation Culture, and Process as Variance Reduction

Eeke de Milliano

Process, by definition, is variance reducing. You're introducing it, because you worry that the variance in your org is too high. You want people to sort of meet a certain standard.

Eeke de Milliano

And the cost of that is obviously, while you are reducing the standard and bringing folks up to the average, you're also bringing other folks down to the average. And oftentimes, the folks you're bringing down are your highest performers, your most creative thinkers. The folks who, I think actually don't really need process to do their best work.

Eeke de Milliano

And so, that, I think is always the tension that you have with process. And obviously one of the reasons why companies introduce process much more and more, as companies get bigger, is because it's harder to get all these folks who don't need processing. You actually want to reduce the variance.

Eeke de Milliano

Thanks so much for having me, Lenny.

Eeke de Milliano

Awesome. Very ready. Snir is the best, so yeah, I'm excited.

Eeke de Milliano

Yeah. So when I joined Stripe, I joined Stripe in 2013. It was pretty small at the time, it was around 50 people. And Stripe didn't have any product managers at that time.

Eeke de Milliano

And I think Stripe was kind of famous for that. And it really wasn't because we were anti-PM in any way. It was mostly just because we were building this product for developers. We had a lot of really talented engineers, who were essentially doing the PM job.

Eeke de Milliano

So I actually joined Stripe as the first account executive, which I think is pretty funny, now that I've seen real account executives do their jobs. Because I really just had no business doing that job. But it also really wasn't your typical sales job, in that most of Stripes volume was inbound. So I was really just spending all of my day talking to customers, helping them figure out how Stripe might work for their particular business flows, and payment models.

Eeke de Milliano

And a lot of it was, I think, what PMs do. It was just talking to customers, understanding their pain points, and really helping them figure out how the product might do that. And to this day, when people ask me, "Hey, what's your advice for going into product management?" I'm like, "Well, you should go get a sales job. I think it's pretty valuable."

Eeke de Milliano

But, it's kind of a long story to explain that, at the time there was this one sort of business model, the two-sided marketplace business model, that was just becoming huge. And you can't even really sort of imagine that now, but back then, Airbnb, Lyft, Uber, all those marketplaces, it was quite a new way of doing business.

Eeke de Milliano

And so, I was talking to all these customers and they had pretty complicated payment needs. So it was like, one payer putting in funds and it's getting paid out to a recipient. So an Airbnb guest and an Airbnb host. Or multiple payers putting funds in and it's getting paid out to one recipient, like a GoFundMe campaign. Or one payer putting in money and it going out to multiple recipients, like with ClassPass, where you get a subscription and then it gets paid out to a bunch of studios.

Eeke de Milliano

And then on top of that, all these platforms and marketplaces started having all these pretty complex regulatory and compliance requirements that were pretty different, country to country.

Eeke de Milliano

So it was just this really complicated financial infrastructure problem, and Stripe actually didn't really have the right solution for it. And no one else in the market did, either.

Eeke de Milliano

So at the time, this Stripe engineer, Brian Krausz, started poking around at this problem. Because I was talking to so many of these customers, we started talking about this problem together and poking around. And that actually resulted in us launching this sort of evolution of this product that we had at the time, called Stripe Connect.

Eeke de Milliano

That was easily, I think, one of my favorite products I worked on. Not only, it ended up actually being really quite significant for Stripe's business. But also, because it was the first product and I think that's always pretty special.

Eeke de Milliano

And then, the second product that I think of very fondly during my time at Stripe, was this product, Stripe Radar. So Stripe obviously processes a lot of payments. Wherever there's money, fraudsters will kind of follow.

Eeke de Milliano

And there were certainly some merchants who were just particularly vulnerable to payments fraud. So, someone's using stolen credit card information to essentially purchase a good.

Eeke de Milliano

And if you're not in payments, this is going to sound kind of shocking. But if a merchant processes a payment from a customer and that customer used a stolen credit card, the merchant is ultimately on the hook for those funds. So it can be detrimental. The merchant who's trying to run a real business is just losing all of this money, because there are all of these frauds who are buying stuff from them online.

Eeke de Milliano

So I really liked working on that product. So the product at Stripe was essentially, we built a bunch of machine learning models to try and predict when a payment was fraudulent. And then we built a product on top of that, to help customers understand why we were blocking payments, and help them write their own rules around that too.

Eeke de Milliano

And that was really fun, both from an anthropological perspective. Because we were kind of hanging out in corners of the internet where you wouldn't usually go if you were doing only legal things. So we were trying to understand who these fraudsters were.

Eeke de Milliano

But it was also really cool from a product perspective, because of all the kind of complicated product questions around how humans should interact with AI and models. And I imagine a lot of the folks in the latest movement in AI are thinking a lot about that too. It's like, "How do you explain a model to humans? How do you let them interact with it?"

Eeke de Milliano

So, both those things were really, really neat.

Eeke de Milliano

Nice.

Eeke de Milliano

That's a great question. I want to say maybe three or four.

Eeke de Milliano

Yeah.

Eeke de Milliano

I think we actually had our first PM at... I want to say at about 100 employees.

Eeke de Milliano

But yeah, no, it was late in the game. And actually, maybe just to pattern match. Retool also didn't really have PMs for a while.

Eeke de Milliano

And I think actually both in the Stripe case and the Retool case, the thing that both of these companies have in common is, you're building for developers. The people who are building the product are the customers in a lot of ways. So, they get it. There's really no reason why you should have, in some ways, a middle man trying to figure out, "Hey, who's the customer, and what is it that they need?" And what are their pain points?"

Eeke de Milliano

And I think the moment at which it became clear, "We really do need PMs at Stripe." And I think we felt the same way at Retool is, your customer base starts expanding. You start having different kinds of customers. You need to understand the whole market, all of the ICPs that you're going after.

Eeke de Milliano

And the organization gets more complex. I think Stripe... Gosh, in particular, it's just an extremely matrixed organization in business. Because every time you launch a product, you're having to think about, "Well, how do we do this in other countries? There's different financial infrastructure. How do we think about the legal side, the compliance side, et cetera?"

Eeke de Milliano

And I think PMs can really kind of bring that whole story together and make the whole machine move. In addition to understanding the customers, and the value prop, and what the overall strategy was.

Eeke de Milliano

I say this often actually, to folks who are thinking about going into product management. "That's awesome. Just be really, really sure about what you're signing up for."

Eeke de Milliano

It's kind of the same as, I think a lot of people want to become a manager. But just so you know, being a manager is like, "Hey, you're doing performance reviews a lot. And you're in one-on-ones a lot." You have to really love that kind of work. And I think in the product management case, it's also like, you're constantly working across a lot of different teams. You're trying to influence a lot of people who don't report into you directly, to do a bunch of stuff.

Eeke de Milliano

And if you love that, that's great. But you've got to be sure you know you're signing up for it.

Eeke de Milliano

It's so hard.

Eeke de Milliano

Yeah, that quick guide to Stripe's culture. I think we wrote it, maybe when we were around 150 people or so. And we actually wrote it to share with candidates.

Eeke de Milliano

Because the idea was like, "Look, we're kind of opinionated about how we do things here. Most companies struggle to describe what their culture is. Like, how does a fish describe water? But it's worthwhile getting a sense of the things that we feel opinionated about, and that you might like or you might not like."

Eeke de Milliano

And actually, when we put out the guide, our metric of success was that, more of the right people would apply to Stripe and fewer of the wrong people. And there was a whole section in there, I was like, "Hey, look, we work pretty hard here and that is certainly not for everyone. And hopefully you're excited to come and work really hard with colleagues who really care, and that's the reward." So, that's maybe one example.

Eeke de Milliano

On Stripe's culture and what's made it so successful. I've really been thinking a lot about, "Were there one or two pivotal points or decisions for Stripe, that really set it on its path to success?" And I don't think there are, actually. Every time I'm like, "Well, if this hadn't happened..."

Eeke de Milliano

I can always reason my way into, "If these other things would've happened, Stripe would've kind of ended up in the same place."

Eeke de Milliano

So I think what Stripe was actually particularly good at... And by the way, you should take all this with a humongous grain of salt, because I haven't worked there since 2019. But, at least my experience when I was there, what Stripe was really good at was just making, not just one or two good decisions. It was making a lot of really good decisions all the time, big or small.

Eeke de Milliano

And that, I think, was quite cultural. There was this humongous respect and enthusiasm for thinking. It was such a part of the culture. One of the values was, think rigorously. Every meeting was very much like, "Hey, how do we think about this thing from first principle?"

Eeke de Milliano

No one would ever say, for example, "It's a best practice to do X." People would be like, "Well, why?" You had to go a few levels deeper. So that was, I think, one piece.

Eeke de Milliano

The other piece... And a lot has been written about this already. Stripe had a very strong writing culture. All communication was along from writing business reviews, strategy memos, product reviews. There was a lot of writing that happened.

Eeke de Milliano

And I very strongly believe this. I don't think you can be a good writer, unless you're a clear thinker. And if you couldn't write well, I think it was actually pretty hard to be successful at Stripe, at least in the early days. So I think Stripe just cultivated a lot of really good writers, and by input into that, a lot of really good thinkers.

Eeke de Milliano

And then, I think the last thing that Stripe was really good at, was not overthinking decisions. Because that's kind of the flip side of this really rigorous approach, is that you lock yourself into a room and can't come out for five days. You have to be good at making a lot of decisions, and the right decisions, quickly.

Eeke de Milliano

And one of the things that we would always sort of kick around a lot was just the idea of, "Is it a trapdoor decision?" Which I think is an Amazon concept.

Eeke de Milliano

It's like, "If you make this decision, is it one door, or is it two doors? Can you come back from this decision?"

Eeke de Milliano

And I thought Stripe was actually really good at being rigorous... Back to the rigorous point. About what actually was a trapdoor decision.

Eeke de Milliano

So I think a lot of people, for example, think pricing is a trapdoor decision. But actually, it's really easy to grandfather your existing users into some existing pricing model and change pricing for future users. And if you believe that the product's going to be successful, your early users are only going to be a fraction of that pricing model.

Eeke de Milliano

And if the product's not successful, then Who cares if you change the pricing model? So I think that's a really good example of, people think that's a trapdoor decision, but actually you can move much more quickly on that decision than you think.

Eeke de Milliano

And then, a decision that definitely felt to us very much like a trapdoor decision, that I think Stripe took a long time being really rigorous about, was titles. I think Stripe's kind of famous for not really having titles.

Eeke de Milliano

And I think it was right to be rigorous around that decision, because once you've given someone a title, you can't really take it away. So you better be sure about the title you want to give someone.

Eeke de Milliano

Is everyone a lead, at Stripe?

Eeke de Milliano

Yep. Yeah.

Eeke de Milliano

I definitely think it's founder, top-down. They were really good about hiring people who thought that way, too. So it's just all that stuff. It just really, really trickles.

Eeke de Milliano

And actually, to this day, when I'm preparing a memo, or a board deck, or something. I imagine in my head, I'm like, "What if I had to present this to Patrick?" And my ideas just get so much better, because I can sort of think about the questions they would ask.

Eeke de Milliano

So, I think that was one. I think the other one was just sort of this writing culture piece. Once you start writing things down, you realize, "Hey, that actually doesn't make a lot of sense."

Eeke de Milliano

And then, I think the third thing actually was, there was just always a lot of questioning about the status quo. So if something had been done in an industry for a long time, people would always be like, "Well, why was it done that way?"

Eeke de Milliano

And I think this is actually how Stripe got its start. I think when Stripe started, if you wanted to set up a merchant account, it could take weeks. And everyone just assumed that's what it took. And of course John and Patrick were like, "Well, it doesn't actually make that much sense why it should take that long."

Eeke de Milliano

Yeah, think rigorously was one. And I think they might have actually updated these on the website recently, so my recollection is very likely out of date.

Eeke de Milliano

And Stripe would call them operating principles, actually. Which, I think is actually better. Because values, you can't really tell people what to value. Everyone has their own value set. But you can tell people like, "Hey, here's how we operate."

Eeke de Milliano

Another one that I loved was, move with urgency and focus. It was just really this idea that you're biggest compatriot and your biggest enemy as a startup, is time. So you have to move really, really, really fast on it.

Eeke de Milliano

Customers first, was the other one. Or, users first, as Stripe would refer to customers as users. So those are some of my favorites.

Eeke de Milliano

Oh, awesome.

Eeke de Milliano

I'm pretty sure Patrick wrote them. Yeah. I think they came from... Patrick and John wrote them.

Eeke de Milliano

Actually, the other value that I love... I don't think they have it anymore, but it was good, the operating principles. Micro pessimists, macro optimists.

Eeke de Milliano

Yeah. It was just this idea that, "In the long term, we expect the curve to go up. We very much believe in the upward trajectory of just about everything. But on the day-to-day decisions, on the minutiae, we're quite critical. How do we make sure this thing works?" And we'd think about all the ways in which it doesn't work.

Eeke de Milliano

Yeah, I actually think about the extremes of that question. So not, "Why are some teams innovative?" But, "Why isn't every team innovative?" I feel like no one wakes up in the morning and thinks, "Yeah, today I want to work on boring, incremental stuff."

Eeke de Milliano

But, most teams do end up working on pretty incremental stuff. I always wonder, "What is it that's stopping folks from being creative and thinking bigger?" And I think it comes down to a couple of things that companies do sort of unwillingly, or not even realizing it.

Eeke de Milliano

And one is this fear of failure. I think leaders want the upside of innovation, but they're not really willing to deal with the cost of innovation. Which is like, "Look, if you're going to swing big, you will invariably stumble sometimes."

Eeke de Milliano

So I think if you want to mitigate that, you have to start shining light on failure. That's really the only way. You have to start normalizing it a little bit. And obviously, if an individual, or if a team is consistently failing and not learning. That, you need to deal with.

Eeke de Milliano

But I think sometimes it's good to fail. And when you do fail, use it as an opportunity. Don't squander that moment to not learn.

Eeke de Milliano

But yeah, one example is, instead of calling something a postmortem, call it a retrospective, so that it's a positive thing. Like, "Hey, we're learning from this thing."

Eeke de Milliano

And then, I think the other way to kind of mitigate the feeling of failure is, you have to figure out how to give folks more at BATS. Because obviously, anything that takes one year to ship, and you haven't gotten any customer feedback, the stakes of that are just going to feel so, so high. If you get it wrong, it's going to be devastating. So you have to figure out how to lower the stakes.

Eeke de Milliano

And honestly, I think in some ways it's kind of easy. It's like, "Look, don't put too many resources against these bigger swings. Have them be small teams." And then also, just get customer feedback as quickly as possible. Don't wait until the thing is perfect. And that way, you can limit the risk.

Eeke de Milliano

So yeah, I think fear of failure, that's definitely one thing that stops teams from being innovative.

Eeke de Milliano

There's a very practical one. Sometimes teams are just getting bogged down by really urgent work. There's too much tech debt. There's too much product debt. Bugs, instability. It's a massive hierarchy of needs. There's just no way that they're going to be able to focus on the enlightened, bigger, creative stuff if they're just heads-down dealing with incidents all day. So if that's the case, yeah, diagnose it and get your team out of that.

Eeke de Milliano

And then, I think the last reason why teams aren't always that innovative is because, I think thinking big is really hard. And to some people it comes pretty naturally. But for most of us mortal souls, it's just really, really hard. And it takes time. And when you're at a startup and you're just grinding day-in, day-out, you're treading water just trying to make it through the day.

Eeke de Milliano

Taking the time to really think about the strategy, and where things should go, and get creative. It's pretty hard. So I call this... You have to give teams permission to think. So create these moments in your company culture, in your overall business processes, where you're asking people, you're literally saying, "Hey, this is part of your job to think bigger."

Eeke de Milliano

So at Retool, we have these team charters and we do team planning. And at the bottom of every team charter we have a section called, Think Bigger. "With 20% more time, what would you do that isn't on this list already?"

Eeke de Milliano

And then another really neat tradition that we had at Stripe, and we have a Retool now, too. Is this thing called, Crazy Ideas. So at the beginning of every year, David will send out a blank doc to the org and it's titled Crazy Ideas.

Eeke de Milliano

And the Prompt is, "Crazy ideas are ideas that we shouldn't, obviously, do. There's a 90% chance that they make no sense. But in the 10% chance that they do, they will make a 10x to 100x difference for the retail business." And then, it's literally just a request for crazy ideas.

Eeke de Milliano

And the org loves it. It's amazing. The energy around it is so cool. And it's not just product ideas, it's different ways of how we should run our organization. Or, it's really cool marketing ideas in there.

Eeke de Milliano

So, that doc is awesome. And whenever I have a down day, I just scroll through that doc.

Eeke de Milliano

Yeah. Yeah, yeah. So every year that we send out the doc, we look at the doc from the past year, and we're like, "Okay, did we do anything on this list?" And consistently, we do anywhere between three to eight things on the list.

Eeke de Milliano

Yeah.

Eeke de Milliano

Actually, at least one, if not two of the three products that we launched this last year were on the crazy ideas list at one point. Like, a year ago, if you'd asked me, "What is Retool's product?" I would've told you, "Retool helps you build internal frontends really, really fast."

Eeke de Milliano

But if you were trying to schedule a query to run at a later point in time, or have something trigger, or run an ETL task, you couldn't do that in Retool. So that was actually one of the crazy ideas. And that ended up becoming Retool Workflows, which we launched just last year, in November.

Eeke de Milliano

To me, it's always in the follow-ups. So have people talk about the failure in these sort of public forums, where usually you talk about the successes. So have someone actually write a note that's like, "Hey, here are all my learnings from this thing that we did." And send it to the org.

Eeke de Milliano

At Retool we have a shipped email list. If you ship something, you'll always send to that.

Eeke de Milliano

Have them send that email to the org. It's just an awesome way to celebrate. Or have them present it all-hands and share what they learned. And it almost always results in, I think, a really positive twist.

Eeke de Milliano

Really? That's so cool.

Eeke de Milliano

Yeah, yeah, yeah.

Eeke de Milliano

There's a couple of top-down things, and a couple of bottom-up things.

Eeke de Milliano

On the top-down, sometimes you just have to be willing to fund someone with something. Like, they come to you with an idea and you're like, "Look, yeah, take an engineer and go do it." And you just have to give folks that sort of organizational buy-in.

Eeke de Milliano

Actually, I was thinking back to that engineer, Brian Krausz at Stripe, who started poking around on this marketplace model. And I was thinking, I can't remember a moment when someone formally said to him, "This is now your job." I think he just went and looked, and went and dug into it. And at some point, I think a manager was like, "All right, this is now your job."

Eeke de Milliano

But yeah, no, I think you have to be able to fund folks' time and give that. Hackathons, I think, are pretty good for that stuff. It is kind of a moment for folks to take a step back.

Eeke de Milliano

And then, I think more than anything, in people's planning processes, I really like asking folks the 20% more time question. Or the other question was, "Look, if you doubled the team today, what would you do?" That shows up in our planning processes as well.

Eeke de Milliano

And I think it really helps people kind of break out of this... I think you end up planning towards the team that you have and not the team that you should have. So, that's how folks can break out of that process.

Eeke de Milliano

Folks can just go crazy on it. It's however they want to take it. I've seen folks actually create entire demos.

Eeke de Milliano

But I actually think the trick is less structure, in those cases. Because you don't really want to sort of pigeonhole... Or make it even that intimidating for folks. If someone just wants to write down a few bullets, that's great.

Eeke de Milliano

So the three products we launched, one was Retool Workflows that I talked to you a little bit about. It's like, if you want to be able to, essentially create a workflow. Like schedule an alert, run a task, you can kind of do it in the Retool way. Where it's this visual, sort of easier builder of creating these different sort of workflows. But you can write your own code on top of it, as well.

Eeke de Milliano

The second product is Retool Mobile. So you could pretty easily build incredible web apps with Retool. But there are plenty of folks who don't sit behind their laptop at a desk all day. And for those folks... We had a lot of companies who were like, "I want a mobile native app." And so, we launched that product.

Eeke de Milliano

And then the third product was Retool Database. So until very recently, if you came to Retool, you could connect your data via your APIs, your database, directly into Retool.

Eeke de Milliano

But what we found is that actually, a lot of folks either don't have access to their database, or they're just trying to build an internal tool and they don't necessarily want to store that data in their production database.

Eeke de Milliano

So we built... Essentially, we spin up a post [inaudible 00:33:32] database for you. And you can just access it via a really nice UI and manage it directly in Retool.

Eeke de Milliano

Yes. Okay. So I think your second question was, "Was this a good idea?"

Eeke de Milliano

Yeah. You know what? I think in hindsight, if I were to do it again, I think sequencing it would've been slightly better. Just because, I think what we ended up doing is, we ended up launching the idea behind all three of these products at around the same time. And they all ended up maturing at around the same time, and that was just a lot of headspace from the org. Even though actually, the teams themselves were not that big.

Eeke de Milliano

It was just like, we had all these products and we were just waiting for them to launch and waiting for them to launch. Whereas, maybe if we'd sequenced it, I think that would've felt more satisfying to the whole organization.

Eeke de Milliano

But, I mean, it ended up working out. I think that's kind of the crazy thing. It's like, we were able to pull off launching these three products.

Eeke de Milliano

And by the way, I should caveat that, the further I get along my career, the more I realize I'm just kind of building on the shoulders of giants. And a lot of these ideas, et cetera, were very much in the works and were happening before I came along.

Eeke de Milliano

But yeah, it was really neat to see how we got that all over the finish line in a year.

Eeke de Milliano

Today, we're around 300 people.

Eeke de Milliano

Yeah, I'm sure our product marketing team felt that way. Yeah, a couple of things. We started really small with all of these initiatives.

Eeke de Milliano

So I think I mentioned, we really had one or two people working on each of these products for the first six months. So it was one engineer and one designer, or one engineer and one PM. And they really didn't get funding until it was clear that there was something there.

Eeke de Milliano

So those teams, they spent a ton of time with customers. They spent a ton of time building, a ton of time prototyping. And it was kind of the moment where it was like, "Okay, they are there." That we started bringing more people onto the team.

Eeke de Milliano

So, that was the first piece. The second piece is that, we really treated them like startups. We're like, Retool's the VC, and Retool funds with resources and Retool's existing customer base. Which is obviously quite valuable, because you have all these customers you can market to and promote to.

Eeke de Milliano

But then, the teams really had to prove that ROI. Either in engagement, or eventually revenue, in order to be able to move forward.

Eeke de Milliano

And then the third thing... And this one, actually I think it can be quite controversial. Is, we were really deliberate about keeping these teams separate from the rest of the org, especially early on. Now, a lot of them, they're very much a part of the overall organizational processes.

Eeke de Milliano

But very early on, they were running on their own. They were meeting quite independently with one, or two, or three folks from the leadership team. And they were also just quite separate from the product itself.

Eeke de Milliano

I think Retool Mobile's actually a really good example, where we had a lot of debate about whether or not we should build Retool Mobile out of the core web app builder. Because a lot of the primitives are the same.

Eeke de Milliano

And we eventually decided that we were going to run it as a separate team, because we wanted the team to be able to move really, really quickly. And we didn't want it to get bogged down in, what are just the realities of running a product that has product market fit, like bugs, yada, yada, et cetera.

Eeke de Milliano

And I think that was absolutely the right call, because Retool Mobile actually has quite a different target customer. Which, we only really realized maybe like halfway through the project. And I don't think we would've been able to really understand that, or even get broader in that kind of thinking, had we sort of been stuck in the core retail product.

Eeke de Milliano

But yeah, there was a cost to that, too. Which is like, "Okay, now we have these two products, and we have to..." I think obviously the strength will be, "How do all these products interact with each other, and how do they build on top of each other?"

Eeke de Milliano

So, we have to go and invest in that now. But I think it's totally worth it, because your team can just move more quickly, be more independent, and think more independently, too.

Eeke de Milliano

Yeah. What I would really love from companies is just sort of like this time capsule, where you can see what their processes were when they were like 20 people, and 50 people, and 100 people, and 500 people.

Eeke de Milliano

Because when we were at Stripe and we were trying to figure out our planning process, we actually talked to Amazon, and Atlassian, and Apple, and all these companies that we really, really respect and look up to.

Eeke de Milliano

And I remember taking down notes from these companies and being like, "Yeah, this is awesome, but there's no way that this will work for Stripe." Stripe was so much smaller than any of these companies.

Eeke de Milliano

So yeah, they were showing us where we had to go, but no idea how to get there. And so, yeah, Lenny, maybe you can help us figure out time capsules for companies and what processes make sense.

Eeke de Milliano

Oh, nice.

Eeke de Milliano

Cool. I love that. But yeah, to answer your question directly. Process... Yeah, it really gives people a bitter taste in their mouth, I think.

Eeke de Milliano

Process, by definition, is variance reducing. You're introducing it, because you worry that the variance in your org is too high. You want people to sort of meet a certain standard.

Eeke de Milliano

And the cost of that is obviously, while you are reducing the standard and bringing folks up to the average, you're also bringing other folks down to the average. And oftentimes, the folks you're bringing down are your highest performers, your most creative thinkers. The folks who, I think actually don't really need process to do their best work.

Eeke de Milliano

And so, that, I think is always the tension that you have with process. And obviously one of the reasons why companies introduce process much more and more, as companies get bigger, is because it's harder to get all these folks who don't need processing. You actually want to reduce the variance.

Eeke de Milliano

This is actually a little bit of an aside, but it's kind of relevant, so I'm just going to mention it. And you can feel free to let me know if it's too much of an aside.

Eeke de Milliano

But, I was just listening to this awesome podcast with Russ Roberts, who's a professor. He hosts EconTalk. I don't know if you listen to it.

Eeke de Milliano

And he was in interviewing this guy, Ian Leslie, who's this great writer and has just written this article that's... Basically, something along the lines of what it means to be human in the age of AI.

Eeke de Milliano

And I thought he just articulated this idea well. Which is, we're all really so impressed when we see ChatGPT-3 spit out this piece of writing that feels very human-like.

Eeke de Milliano

But what we're kind of forgetting is that, over the last 10, 20, 30 years, we're actually asking humans to be a lot more robot-like. In that, we're really asking everyone to standardize in a lot of ways. And we're making people a lot more formulaic. If you think about how we teach people to write, it's like, "Well, there's five paragraphs. And there's your opening paragraph. And you state your topic."

Eeke de Milliano

So anyway, I think the point is, the more formulaic, the more sort of mass produced you're trying to make something. The more you kind of quench people's creativity, and the further away you get from the really, really high highs. And that, to me, is the cost of process, and rules, and templates.

Eeke de Milliano

So if you're going to introduce it, be really, really sure that you're okay with that cost. And give folks escape hatches.

Eeke de Milliano

So I've started referring to this as the MVP, the minimum viable process. So if I give folks a template, I'm like, "Look, use the template. But if you want to break out of it, please absolutely do." And I've started writing this at the top of templates now.

Eeke de Milliano

It's like, "If this doesn't work for what you're trying to explain, don't use it. But just know that this is the minimum viable thing. We're setting the bar here, but go higher if you can, please."

Eeke de Milliano

So anyway, that's my sort of long drive on process. With all that said, I do think that companies, there's just a set of documents that are really, really viable. That every sort of level of the organization should have throughout its lifecycle.

Eeke de Milliano

And then, I think how sort of involved it is, or how long term it is really depends on how big you are.

Eeke de Milliano

But those documents, to me, are the charter. So, "What is your mission, your vision and your strategy?" The goals, "What are you aiming to do and how are you going to measure success?" And then the roadmap, "What is the thing that you're shipping?"

Eeke de Milliano

And I think the whole company needs these, the whole function. So in product, you need all three of these. And then, within each team you need all three of these.

Eeke de Milliano

And I've kind of noticed two things about this framework for myself. One, I've actually noticed that teams often work their way from the bottom-up, versus top-down. They start with a roadmap. They're like, "What are all the things we're going to ship?" Especially early on. And then they kind of work their way into a charter. But I think it's really, really worth it to start from the top-down.

Eeke de Milliano

And then, the second thing that I've noticed is that your time horizon really shifts as you get more mature. So if you're very early on, you don't have PMF, you should have a charter, but your charter should be like three months in the future. Because you can't look that much further.

Eeke de Milliano

And if you're a company that's humming and going, your charter is probably... The horizon's maybe a decade.

Eeke de Milliano

To me, the unlock for organizations is managers, for this. Because you need managers to both detect the high performers and be like, "This person doesn't need the process." And then you need managers to give that person air cover to be like, "We're honestly..." Because what you're doing is, you're giving them some special treatment and you need to be kind of okay with that.

Eeke de Milliano

And you also need to be okay with the organizational cost for that. Claire, who used to be the COO of Stripe, would always say, "Are you willing to break the org for this person?" And I always thought that was a really nice framing. And you kind of need to decide who you want to do it for, too.

Eeke de Milliano

But yeah, some people are just that good that like, "Yeah, of course you'll break the org for them." They're going to break the org in the best way possible.

Eeke de Milliano

Yeah.

Eeke de Milliano

Yeah, she just wrote a book. Yep.

Eeke de Milliano

That's awesome.

Eeke de Milliano

I have a couple of, I guess, specific mental models that I use. The first is, build for your best user, not your worst user.

Eeke de Milliano

And what I mean by that is, I think it's actually really easy to get stuck, or to focus on, "What if there's abuse of this product?" Or think about all the ways in which the product won't be used well. And then you end up sort of shaping the product in these really weird funky ways to make up for that.

Eeke de Milliano

Whereas in reality, the worst users, they should be a fraction of your users anyway. So you shouldn't really be building for them.

Eeke de Milliano

I think a really good example of this is onboarding processes. Where, you're probably going to be building an onboarding process, where you're trying to collect a lot of data. Or trying to figure out, "Hey, how do I help this user who maybe isn't well suited for my product to be successful?"

Eeke de Milliano

Really, you should just be building an onboarding process for the user who's going to jump into your product and get it immediately.

Eeke de Milliano

I was thinking about this actually just the other day. Because we were in this product review, and we were talking about this other new product that we're thinking of exploring.

Eeke de Milliano

Yeah, exactly. And we're kind of going down this path of like, "Oh, well if this gets really big, there's going to be all this abuse of the product." And Anthony, our founder was like, "Wouldn't that be an amazing problem to have?" And we're like, "Yeah, that's a really good point."

Eeke de Milliano

So we kind of put that on the back burner.

Eeke de Milliano

Yeah, totally. Yeah, sure. If you're going to look at the end, and you're trying to optimize, et cetera, absolutely. But in that sort of early product development stage, it's just not worth it to be too focused on that.

Eeke de Milliano

So, that's one. The other one, our head of design, Ryan, always kind of reminds us of is, build the scooter, not the axle.

Eeke de Milliano

So if you're trying to build the minimum viable product for a car, don't build just the wheels and the axle, build the scooter first. And then from there, you build the bicycle, and the motorcycle, and then the car.

Eeke de Milliano

And it's always just such a good reminder. You always want to start building the whole thing. But really try and think about the slice that gets the customer to complete value on a smaller thing first.

Eeke de Milliano

So with Retool Mobile for example, there's just so much you could be building there. And we decided very specifically, "Hey, we're only going to build this for companies that have field workers and they would need to do inventory management."

Eeke de Milliano

And it's a very specific slice, but it helps get through from something that was actually viable, beginning to end.

Eeke de Milliano

Yeah. And then the last one is this idea of 70/20/10 split investments. I really think that a lot of product management can sometimes be reduced to funnels and portfolios.

Eeke de Milliano

So the 70/20/10 investments model in my head is just like, 70% of your building time should really be going to your core product, that has product market fit. 20% of your time should be going to strategic initiatives that aren't core, but they're strategic to the company, that you know have to do them. And then, 10% of your time should be going towards bets.

Eeke de Milliano

Yeah. To me, that falls squarely in the 70%. So yeah, core product, tech debt, sort of the maintenance mode type stuff. And core product, obviously you're also doing a bunch of new stuff there too.

Eeke de Milliano

But yeah, no more than 70% of your resources should be going there.

Eeke de Milliano

Strategic initiatives that aren't your core, but you just know, based on your strategy, you have to do these things.

Eeke de Milliano

Cool.

Eeke de Milliano

Yeah. This, I think, is really one of the trickiest parts of product management, in my mind.

Eeke de Milliano

We don't have a company-wide sort of process on this. It's pretty team specific. Some teams do Friday bug bashes. Other teams are just, as products roll out, will work on them as they go.

Eeke de Milliano

I was actually speaking to a product manager at a different company, who mentioned that they just spent the last 18 months doing just product polish and bugs. And I think they landed in a place where they had to do it, because they just had so much debt. But luckily, we're not there yet.

Eeke de Milliano

Right now, we let most of the teams just kind of do it themselves and figure out what makes sense for them.

Eeke de Milliano

Well, I do think every good product team figures out how to get close to customers. But just based off of my observations from Retool, and what I've seen at other companies, there are a couple things that are more pronounced at Retool than I've seen in a lot of other places.

Eeke de Milliano

The first is, we have a lot of PMs who used to be in customer-facing roles, at Retool. I obviously am a big fan of that. I think there's just nothing like really understanding the value of your product, at the moment where a customer actually has to put money down. And so, I really like that about PMs, who have had those conversations with customers and they really get it.

Eeke de Milliano

Second is, because the retail product is so technical... And I do think this just depends on what product you have. Our PMs are really, very technical. Everyone has either a CS degree, or has done some sort of engineering in the past.

Eeke de Milliano

Third is, we use Slack very heavily to talk to our customers and interact with them. So at this point, I think we have hundreds of Slack channels with customers. Every time we're testing a new product, or a new customer who's somewhat large, comes online. We will work with them in Slack, to get there off-the-cuff feedback, just back and forth. It's really nice. We just have this direct line to them, which is awesome.

Eeke de Milliano

And then, the fourth thing we do is, we use Retool to build Retool. So our product roadmap lives in a Retool app. And the app that we use to have feature flags for particular features, is a Retool app. So PMs are just in the product all day long, every day. They're their own customers in a lot of ways, and that really helps as well.

Eeke de Milliano

Oh, yeah. Well, we built many... Basically, all of our internal tooling happens in Retool. Like, our PMs, all their team dashboards are in Retool. All of their task tracking is in Retool. Submitting linear requests or bug requests happens in Retool, and then goes to Linear. So yeah, it's how we run the company.

Eeke de Milliano

I have a couple of insights on that. One interesting insight is that, teams that have one always want the other.

Eeke de Milliano

Whenever I talk to candidates, I feel like you can always tell what their company has, because they'll be asking a lot of questions about the opposite. If they're probably a growth company they'll be like, "Well, how are you guys thinking about Enterprise?"

Eeke de Milliano

And then, if they are more of a sales-led growth company, they're like, "Well, how are you guys thinking about your self-serve motion, or your product-led growth?"

Eeke de Milliano

And my main takeaway, just in... And I don't know if I would even use the dichotomy of product-led growth, or sales-led growth, with Retool. I think we do have a lot of product-led growth. But we work with a lot of enterprise customers, and a lot of our revenue comes from enterprise customers, and we have a fantastic sales team.

Eeke de Milliano

And I think the main thing is that, you just have to really figure out your interaction mechanisms with sales. And that just has to be so, so tight.

Eeke de Milliano

And it goes in both directions. There's obviously, how you get feedback from them, because they are so often on the front lines talking to customers. Moreso than product managers, even.

Eeke de Milliano

But it also goes the other way. If you are going to ship something, or if you are going to put out a roadmap, like, "How do you make sure that the sales team has everything that they need..." The sales, and in Retool's case, the success team and the support team, "Has everything they need to accurately talk to customers about that?"

Eeke de Milliano

And I've always actually found that really hard, because it's really hard to figure out the right altitude. If you're giving a presentation on the roadmap, people are either going to feel like it's too high level. Or, it's too low level for folks who maybe are new.

Eeke de Milliano

So this year, we're actually trying something different. We are doing a science fair. Where, each product team has a little booth. And they get to stand there, and anyone who has questions about the product can come... You know, from the go-to-market side, can come and ask questions, and get demos, and go as deep as they need to.

Eeke de Milliano

So, I'll let you know how that goes. But I'm excited to experiment with it.

Eeke de Milliano

There may be prizes. Who knows?

Eeke de Milliano

Yeah. Yeah, it's back to like, all of product management is portfolios and funnels.

Eeke de Milliano

I think it's really tempting as a manager, to build a team in your image, because you understand their skillsets and you value those skillsets. And you're going to be able to detect and assess those skillsets better.

Eeke de Milliano

But the best product teams, in my mind, have really figured out how to balance the talent portfolio. So instead of having a bunch of PMs who all spike in one particular area, figure out how you can create complimentary skillsets for the whole PM team, so the whole is much stronger.

Eeke de Milliano

And one way in which I like to do that is, I really like to balance product teams with homegrown product managers, who really get the product. They've probably been in it. They're amazing culture carriers, often. They really set the tone. But they may not have seen product management at other companies, and they may not have some of the more conventional and traditional product management skillsets.

Eeke de Milliano

So I want to balance that with product managers who've come from other companies, and have done it, and can bring a little bit more of that product manager rigor. Even though they don't have, in the Retool case, the core Retool product management vibe.

Eeke de Milliano

So, that's one example. I think there's others as well. Some PMs are just incredible execution machines. Other PMs are amazing visionaries. You kind of want a little bit of all of them.

Eeke de Milliano

And you want to also balance within all of your different pillars. So we have three different sort of product pillars at Retool, and there's leads for all those pillars. And I always push the leads to hire people who don't look like them, so that we have balance everywhere.

Eeke de Milliano

Yeah. I do a little personal exercise for myself every six months, where I chart out the team that we have today, and write down all of the strengths that we have, all of the weaknesses that we have, as a team. And then I try to hire specifically for those weaknesses.

Eeke de Milliano

I think that's it on my end.

Eeke de Milliano

I'm ready.

Eeke de Milliano

Bird by Bird: Instructions on Writing and Life by Anne Lamott. It's incredible. So touching. Really, really great. Also, I think product managers should be great writers. So, I love that.

Eeke de Milliano

And then the other book that I was going to say, but I'm glad you mentioned Claire, is Claire's book, Scaling People, which is coming out. I had a very small hand in ghost writing for her a little bit, in the first draft. So I use a lot of the early chapters from that book still, in management. And I still recommend the tactics in there, so I'm excited for her to get it out.

Eeke de Milliano

Nice.

Eeke de Milliano

Yeah, this one's great. I can't choose between these two, though. One is Lex Fridman. And then the other is EconTalk by Russ Roberts. I really like that both of them are... Their agenda is curiosity, which I love.

Eeke de Milliano

Is it too basic to say White Lotus?

Eeke de Milliano

Oh, season two, all the way.

Eeke de Milliano

To what do you attribute your success? And you can't say luck.

Eeke de Milliano

Yeah. Because I think humble people will always say luck in some way. And I always kind of wanted to know, "How self aware are you, and how curious are you?"

Eeke de Milliano

And I think people who have really gone back and reflected on why are they where they are today, really says a lot about how they think about the world.

Eeke de Milliano

Yeah. Well, first and foremost, it's Retool. And then, the other SaaS tools that we use a lot, Slack, Gong, Linear and FullStory.

Eeke de Milliano

Yeah. Have you heard of Rewind?

Eeke de Milliano

Nice. Yeah. I mean, I think it's really incredible what they've done.

Eeke de Milliano

It basically records everything that you're doing on your computer and then makes it really easy for you to search it. Which, it's just incredible. I don't know if you work this way, Lenny. But I feel like nowadays, I don't really go to tabs anymore. I kind of directly search for the thing that I'm searching for. And I think Rewind just fits that user behavior so, so well.

Eeke de Milliano

Definitely find me online on Twitter. It's @EekeDM. And, how can they help us? Try out the Retool product and give us some feedback.

Eeke de Milliano

Yes.

Eeke de Milliano

Thanks, Lenny.