How to foster innovation and big thinking | Eeke de Milliano (Retool, Stripe)

1. 0:00 – 3:36

   Eeke’s background

   1. EMEeke de Milliano0:00

      ... process by definition is variance reducing. Like you're introducing it because you worry that the variance in your org is too high, like you want people to sort of meet a certain standard. And the cost of that is obviously while you're 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, you know, the folks who like, you know, I think actually don't really need process to do their best work. And so that I think is always the tension that you have with process, and obviously like one of the reasons why companies introduce process much more and more as companies get bigger is because it's just, it's harder to sort of like get all these folks who kind of don't need processing. You- you actually want to reduce the variance.

   2. LRLenny Rachitsky0:50

      (instrumental music) Welcome to Lenny's Podcast, where I interview world-class product leaders and growth experts to learn from their hard won experiences building and scaling today's most successful companies. Today my guest is Eka DeEmilianio. Eka is head of product at Retool. Prior to that, she was a long time PM at Stripe. She was actually one of their very first PMs, where she helped build some of their foundational products like Stripe Checkout, Stripe Connect, Stripe Radar, and Stripe Chargeback Protection. I had a total blast chatting with Eka. We covered Stripe's internal culture and what makes it so unique and innovative, how to foster and protect innovation at your own company, what is the right amount of process by stage of company, how to build a talent portfolio, and so much more. I am really excited for you to hear this episode. And with that, I bring you Eka DeEmilianio after a short word from our wonderful sponsors. Today's episode is brought to you by Miro, an online visual whiteboard that's designed specifically for teams like yours and mine. I have a quick request. Head on over to my board at miro.com/lenny and let me know which guests you'd love for me to have on in 2023. And while you're on the Miro board, feel free to play around with the tool. It's a great shared space to work closely with your colleagues to capture ideas, get feedback, and iterate quickly and easily on anything you're working on. For example, in Miro you can build out your product strategy by brainstorming with sticky notes, comments, live reactions, a voting tool, even an estimation app to scope out your team sprints. Your whole distributed team can come together around a wire frame and draw ideas with the pen tool or even put mocks right into the Miro board. And with one of Miro's ready-made templates, you can go from discovery and research to product roadmap to customer journey flows, final mocks, you get the picture. Head on over to miro.com/lenny to leave your suggestions. That's miro.com/lenny. This episode is brought to you by Notion. If you haven't heard of Notion, where have you been? I use Notion to coordinate this very podcast, including my content calendar, my sponsors, and prepping guests for launch of each episode. Notion is an all-in-one team collaboration tool that combines note taking, document sharing, wikis, project management, and much more into one space that's simple, powerful, and beautifully designed. And not only does it allow you to be more efficient in your work life, but you can easily transition to using it in your personal life, which is another feature that truly sets Notion apart. The other day, I started a home project and immediately opened up Notion to help me organize it all. Learn more and get started for free at notion.com/lennyspod. Take the first step towards an organized happy team today, again at notion.com/lennyspod. (instrumental music)

2. 3:36 – 8:58

   Eeke’s time at Stripe

   1. LRLenny Rachitsky3:36

      Eka, welcome to the podcast.

   2. EMEeke de Milliano3:39

      Thanks so much for having me, Lenny.

   3. LRLenny Rachitsky3:40

      It's absolutely my pleasure. A bunch of people have told me that I need to have you on this podcast, and actually a big thank you to Snir Kodesh, who I believe is a colleague of yours, who gave me a bunch of interesting questions to ask you. So I hope you're ready.

   4. EMEeke de Milliano3:53

      Awesome. Very ready. Uh, Snir is the best, so yeah, excited.

   5. LRLenny Rachitsky3:57

      So you're currently head of product at Retool, but before that you spent a lot of time at Stripe. You spent six years at Stripe. And so before we get to Retool, I actually want to spend a little time on Stripe. To set a little foundation, could you just talk about some of the things you worked on at Stripe and maybe some of the things you're most proud of during that time?

   6. EMEeke de Milliano4:15

      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. And I think Stripe is kind of famous for that, and it really wasn't because, you know, we were anti-PM in any way. It was mostly just because we were building this product for developers with a lot of really talented engineers who were essentially doing the PM job. So I actually joined Stripe as the first account executive, which I think is pretty funny now that I've seen, you know, real account executives do their jobs (laughs) 'cause I, I really just had no business doing that job. But it also really wasn't your typical sales job in that most of Stripe's 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- and payments models. And a lot of it was, I think, you know, what PMs do, just like talking to customers, understanding their pain points and- and really helping them figure out how the product might do that. So, and to this day when people ask me, "Hey, like what's your advice for going into product management?" I'm like, "Well, you should go get a sales job."

   7. LRLenny Rachitsky5:18

      (laughs)

   8. EMEeke de Milliano5:18

      I think it's like pretty, pretty valuable. But it's kind of a, a long story, uh, to explain that at the time there were, uh, there was this one sort of business model, this two, the two-sided marketplace business model that was really, it was just becoming huge. And yeah, like you can't even really sort of imagine that now, but like back then, like Airbnb, Lyft, Uber, all those marketplaces, it was quite a new way of, of doing business. And so I was talking to all these customers and they had like pretty complicated payments needs, so, you know, 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, you know, with ClassPass where you pay the subscription and then it gets paid out to a bunch of, a bunch of studios. So-And then on top of that, all these platforms and marketplaces started having all these pretty complex regulatory and, and compliance requirements that were pretty different country to country. So, it's just this like 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. So at this time, this Stripe engineer, Brian Kraus, 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, of this product that we had at the time called Stripe Connect. Th- that was easily, I think, you know, one of my favorite products I worked on. Not only ... It, it ended up actually being really quite significant for Stripe's business, but also because of, you know, it was the first product, and I think that's always, always pretty special. And then the, the second product that I, I think of very fondly during my time at Stripe is this product Stripe Radar. So, you know, Stripe obviously processed a lot of payments. Wherever there was money, fraudsters will kind of follow, 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, and if you're not in payments, this, th- this is gonna maybe (laughs) 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, you know, it can be detrimental. Like the merchant who's trying to, you know, run a real business is just losing all this money because there are all these fraudsters who are, you know, buying stuff from them online. So, I really liked (laughs) working on that product. So the, the product at Stripe was essentially, uh, 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 sort of write their own rules around that too. That was really fun, as both from a like anthrological 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 (laughs) as we were trying to understand who these fraudsters were, but it was also really cool from a product perspective because of all the, I think, kind of complicated product questions around how humans should interact with AI and models, and, you know, I imagine a lot of the folks in this sort of latest movement of, 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? So, both those things were, were really, really neat.

   9. LRLenny Rachitsky8:37

      I actually use Stripe for my newsletter. It's how, you know, folks subscribe, and when I, I log into my Stripe Dash, Stripe dashboard, and there's so many products, I don't even know what many of them do, but I've-

   10. EMEeke de Milliano8:47

       (laughs)

   11. LRLenny Rachitsky8:47

       ... often seen Radar being pitched to me as a, something I should pay for. Uh-

   12. EMEeke de Milliano8:53

       Nice. Nice.

   13. LRLenny Rachitsky8:53

       ... and I feel like I should probably turn it on. That sounds really useful.

   14. EMEeke de Milliano8:56

       Mm-hmm.

   15. LRLenny Rachitsky8:57

       Um, one thing that I wanna

3. 8:58 – 11:03

   Why Stripe didn’t add PMs until hitting around 100 employees

   1. LRLenny Rachitsky8:58

      dig in on. So you said when you joined, there were no PMs at Stripe.

   2. EMEeke de Milliano9:01

      Yeah.

   3. LRLenny Rachitsky9:01

      And how many PMs were there when you moved into product at Stripe?

   4. EMEeke de Milliano9:06

      That's a great question. I wanna say maybe like three or four.

   5. LRLenny Rachitsky9:10

      Wow. Incredible.

   6. EMEeke de Milliano9:11

      Yeah.

   7. LRLenny Rachitsky9:12

      And I know you said Stripe is kind of known for being really late to PM and kind of like, I don't, I don't know if I wanna say anti-PM, but there was like a lot of sense of, "Why do- why do we need PMs? We have amazing engineers who can decide what to build." Is there anything you can share around just that general philosophy of Stripe, and was it effective? Was it good? 'Cause a lot of companies are anti-PM, and I think-

   8. EMEeke de Milliano9:32

      Hmm.

   9. LRLenny Rachitsky9:32

      ... they always point to Stripe, and Snap is another example of like, "We don't need PMs. Look how far these companies got without PMs." Is there something even unique to Stripe that allowed them not to have PMs? I think it was like 200 employees probably by the time they had their first PM. Something-

   10. EMEeke de Milliano9:44

       I think we actually had our first PM at, I wanna say, at about 100 employees.

   11. LRLenny Rachitsky9:47

       Okay.

   12. EMEeke de Milliano9:47

       Um, but, but yeah, no. (laughs) It was, it was late in the game. And actually, uh, maybe just sort of to, to pattern match, Retool also didn't really have PMs for a while, and they ... I think actually both in the Stripe case and the Retool case, the, 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 like, they get it, you know? There's, there's really no, no reason why you should have sort of some, in, in some ways, like a, a middleman trying to figure out like, "Hey, who's the customer and what is it that they need and what are their pain points?" And I think the, the moment at which it became clear like 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 sort of the whole, the whole market, all of, all of the ICPs that you're going after, and the, the organization gets more complex. I think Stripe, gosh, in particular, it's, it's just an extremely matrixed organization and business, because every time you launch a product, you're having to think about, "Well, how do we do this in other countries? It's different financial infrastructure. How do we think about the, the legal side, the compliance side?" Et cetera. And I think PMs could really kind of bring that whole story together and make the whole machine move, and, you know, in addition to sort of understanding the customers and, and the value prop and like what their overall strategy

4. 11:03 – 12:22

   Why being a PM is not for everyone

   1. EMEeke de Milliano11:03

      was.

   2. LRLenny Rachitsky11:04

      That's a really good reminder of engineers and designers can do the work of a PM, but often they don't want to. It's like there's a lot of not fun parts to it that you're like, "Oh, I wish we could have someone here do these things." And PMs enjoy that work. They're good at it, and so eventually engineers and designers realize, "Okay. I see. I see why maybe we should hire a PM."

   3. EMEeke de Milliano11:24

      I say this often actually to folks who are thinking about going into product management. It's like, "That's awesome. Just be really, really sure about what you're signing up for." It's kind of the same with like, I think a lot of people want to become a manager, but just so you know, like being a manager is like, "Hey, you're like, you're doing performance reviews a lot and you're like, you're in one-on-ones a lot." And like, you have to really love that kind of work, and I think in the product management case, it's also like you're just, 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 (laughs) to do a bunch of stuff, and if you love that, that's great, but like, you know, you gotta be sure you're, you, you know you're signing up for it.

   4. LRLenny Rachitsky12:00

      Yeah. That's a really good comparison. I, when I first became a manager, I was an engineer actually, and I was managing engineers, and then when I moved on to something as an IC engineer again, I was like, "I will never manage again." That was...... no fun at all, (laughs) why, why I want to do this. And I imagine people get into product thinking they're gonna, (clears throat) have all this control, power, influence, and then they're like, "Oh my God, this job is so freaking crazy. What did I sign up for?"

   5. EMEeke de Milliano12:20

      (laughs) It's so hard. (laughs)

5. 12:22 – 17:36

   Stripe’s internal culture guide

   1. EMEeke de Milliano12:22

   2. LRLenny Rachitsky12:22

      Yeah. That reminds me, something that I heard you did at Stripe is you wrote their internal culture guide. It was like a quick start guide to culture at Stripe that I think was maybe shared with early employees and if that's true, I'm curious what it is about Stripe's culture. If you could just, I don't know, briefly share just like, what makes Stripe so special? Clearly it's one of the most successful companies in the world, in history. I know there's been a, you know, a slow down with the market, everyone's slowed down a bit, but it feels like Stripe has been incredibly successful, continues to innovate like crazy, and hires incredible people, people that are starting amazing companies. So, I guess back to my (laughs) question, what is it that you think that makes Stripe's culture unique and special?

   3. EMEeke de Milliano13:01

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

   4. LRLenny Rachitsky13:10

      Hmm.

   5. EMEeke de Milliano13:10

      'Cause the, yeah, the idea was like, look we have like, we're kind of opinionated about how we do things here. Most companies struggle to, to describe what their culture is, like how, how does a fish describe water? But it's worthwhile getting a sense of sort of the things that, that we feel opinionated about and that you might like or you might not like, and, and actually when we, (laughs) 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, you know, there was a whole section in there that was like, "Hey, like we work pretty hard here and that is certainly not for everyone and, and you know, hopefully you're excited to come and work really hard with like really, with colleagues who really care and that's kind of the reward." But, um, so that's maybe one example. On Stripe's culture and, and, and what, what's made it so successful, I've, I've really been thinking a lot about were there, you know, one or two pivotal points or decisions for Stripe that, you know, really set it on its, its path to success and I don't think there are actually. Like every time like, well, if this hadn't happened, I, I can always sort of like reason my way into like, I think these other things would have happened and, you know, Stripe would have kind of ended up in the same place. So I think what Stripe was actually particularly good at and, you know, by the way, you should take all this with a humongous grain of salt 'cause I haven't worked there in, you know, since 2019, but at least my experience when I was there, what Stripe was really good at was just making not just like one or two big decisions, good decisions, it was like making a lot of really good decisions all the time, big or small. And that I think was quite cultural, like there was this just humongous respect and enthusiasm for thinking. Like there (laughs) was just, it was just like a, a, it was such a part of the culture that was, you know, one of the values was think rigorously, like every meeting was very much like, "Hey, how do we, how do we think about this thing from first principles?" Like no one would ever say for example, "It's a best practice to do X." Like people would be like, "Well, why?" Like they, you know, you, you had to kind of go a few levels deeper. So that was, that was I think one piece. The other piece and a lot has been written about this already is we strive to have a very strong writing culture. All communication was along from writing, business reviews, strategy memos, product reviews, it was just, there was a lot of writing that happened and I, you know, I, I very strongly believe this, I don't think you can be a good writer unless you're a s- clear thinker, um, and if you couldn't write well I, 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, you know, by sort of, by sort of input into that, uh, a lot of really good thinkers. And then I think the last thing that Stripe is really good at was not overthinking decisions 'cause that's kind of the flip side of, of this sort of like really rigorous approach is that you like lock yourself into a room and like can't come out for five days and you have to like be good at making a lot of decisions and right decisions quickly. And i- one of the things that, that we would always sort of kick around a lot was this like idea of is it a trapdoor decision, which I think is a, an Amazon concept. It's like the, uh-

   6. LRLenny Rachitsky16:10

      One way door, two way door.

   7. EMEeke de Milliano16:10

      ... if you make this decision is it like one door or is it, is it two doors?

   8. LRLenny Rachitsky16:13

      Mm-hmm.

   9. EMEeke de Milliano16:14

      Um, like can, can you come back from this decision? And I thought Stripe was actually really good at being rigorous, you know, back to the rigorous point, but what actually was a trapdoor decision? So like, I think a lot of people for example think pricing's a trapdoor decision. But actually like 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 gonna be successful, your early users are only gonna be a fraction of that pricing model and, you know, if the product's not successful then, you know, who, who cares if you change the pricing model? So, uh, I think that, I think that's a really good example of like people think that's a trapdoor decision but actually you can move much more quickly on that decision than you think. And then a decision that was definitely t- felt to us like 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 and I, I think it was right to be rigorous around that decision because you can't, like once you've given someone a title, you can't really take it away, (laughs) so you know, you, you better be damn sure about, you know, the title you want to give someone.

   10. LRLenny Rachitsky17:16

       Yeah, the titles are hilarious. I, uh, put together a career ladder doc of all company leveling names-

   11. EMEeke de Milliano17:23

       (laughs)

   12. LRLenny Rachitsky17:23

       ... across all the big companies and, (laughs) -

   13. EMEeke de Milliano17:26

       Is everyone like a lead at Stripe? (laughs)

   14. LRLenny Rachitsky17:27

       ... it's like, it's like product manager, product manager, product manager, product man-

   15. EMEeke de Milliano17:29

       (laughs)

   16. LRLenny Rachitsky17:29

       Yeah, and there's like a lead here and there. Like yeah, like VPs are basically product manager or product leader, something like

6. 17:36 – 20:52

   Stripe’s operating principles

   1. LRLenny Rachitsky17:36

      that.

   2. EMEeke de Milliano17:36

      Yep. Yep.

   3. LRLenny Rachitsky17:37

      Hilarious. You talked about this idea of first principles. People talk about that often as, "We wanna be first principle thinkers. We're gonna think from first principles." How did Stripe actually operationalize that, implement that? Or was that just like founder top down, continue questioning people and that trickles down? Or is there anything else that they did to kind of instill that mentality?

   4. EMEeke de Milliano17:57

      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, and actually, (laughs) to this day when I'm preparing like a memo or like a, a board deck or something, I imagine in my head I'm like, "What if I had to present this to Patrick?"... and like my ideas just get so much better (laughs) because it just like sort of I know, like you can kind of think about sort of the questions they would ask. So I, I think that was one. You know, I think the other one was just a surface writing culture piece, like people would just like, once you start writing things down you realize like, "Hey, that actually doesn't make a lot of sense." And then I think the, the third thing actually was there was just always a lot of questioning about like 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?" And I mean, I, I think this is kind of actually how Stripe got its start, right? Like I think when Stripe started, if you wanted to set up a merchant account, it could take weeks and everyone just assumed like that's, that's what it took. And you know, of course John and Patrick were like, "Well, doesn't actually make that much sense why it should take that long." So.

   5. LRLenny Rachitsky19:00

      You shared some of the values, I don't know if they're just called values, core values, at Stripe, but is there other ones you can share? You said one is think rigorous or don't overthink. Yeah. What are the other values?

   6. EMEeke de Milliano19:10

      Yeah. Yeah. Think rigorously was one in... I think they might have actually served, updated these on the, on the website recently, so my recollection is, is very likely out of date and Stripe would call them operating principles actually, which I think is actually better because values is almost like you can't really tell people what to value, like everyone has their own value set, but you can tell people like, "Hey, here's, here's how we operate." Another one that I love was move with urgency and focus. (laughs) It was just really this idea that, you know, you're kind of your, your biggest compatriot and your biggest, I think enemy as a startup is time. So like you just, you have to move like really, really, really fast on it. Um, customers first was the other one, or users first as, as you know Stripe would refer to customers as users. So th- those are some of my favorites.

   7. LRLenny Rachitsky19:56

      When I think back to what made Airbnb special in a similar way, the values, we call them core values-

   8. EMEeke de Milliano20:01

      Mm.

   9. LRLenny Rachitsky20:01

      ... I think were actually really, really important and-

   10. EMEeke de Milliano20:04

       Yeah.

   11. LRLenny Rachitsky20:04

       ... turned the company into what it ended up being and I was actually there around the time they created these values.

   12. EMEeke de Milliano20:09

       Awesome.

   13. LRLenny Rachitsky20:09

       I'm curious at Stripe, do you have any recollection of just how they came to these operating principles? 'Cause I imagine founders are listening and going like, "How do I-"

   14. EMEeke de Milliano20:17

       Yeah.

   15. LRLenny Rachitsky20:17

       "... how do I come up with these for our c- company?"

   16. EMEeke de Milliano20:19

       I'm pretty sure Patrick wrote them.

   17. LRLenny Rachitsky20:20

       Hm.

   18. EMEeke de Milliano20:21

       Um, yeah. I, I think they came from Patrick and John, wrote them. The other actually, the other value that I love, I don't think they have it anymore, but it's so good in the operating principles, micro pessimists, macro optimists.

   19. LRLenny Rachitsky20:33

       Wow.

   20. EMEeke de Milliano20:34

       Yeah. It was just like this idea that like what gl- long, in the long term we expect the curve to go up. Like we believe like, you know, we very much believe in the upper trajectory of just about everything, but like on the sort of day-to-day decisions, on the minutia, we're like, we're quite sort of critical like, "We'll, like how do we make sure this thing works?" And like, you know, we think about all the ways in which it doesn't

7. 20:52 – 23:21

   Why isn’t every team innovative?

   1. EMEeke de Milliano20:52

      work.

   2. LRLenny Rachitsky20:53

      So zooming out a little bit, we've been talking about Stripe. Retool also is a very first principles, innovative company. Something that I think of when I think of Retool is during the wild market days of, (laughs) of long ago last year, I know Retool is very conservative in how they raised money and the valuations they raised at which looking back ended up being a really good idea while everyone's raising it like $100 billion. I think their last round was like few billion and it's like a very reasonable, conservative way to think about fundraising. And so I guess just thinking about innovation in general, why do you think some teams are able to run like, like innovation machines, continue put out new products, disrupt industries, while other companies kind of plod along, stay conservative? Is there anything you've seen, something you bring to teams you work on to help foster innovation and big thinking?

   3. EMEeke de Milliano21:43

      Yeah. I actually think about the, the extremes of that question, so, so not, you know, why are some teams innovative-

   4. LRLenny Rachitsky21:48

      Mm.

   5. EMEeke de Milliano21:48

      ... but like why isn't every team innovative?

   6. LRLenny Rachitsky21:51

      Mm.

   7. EMEeke de Milliano21:51

      Like, I mean, no one wakes up in the morning and thinks like, "Yeah, today I want to work on like boring incremental stuff." (laughs) But most teams do end up working on like pretty incremental stuff. I always wonder like what is it that's stopping folks from being creative and, and thinking bigger and I think it comes down to like a couple of things that, you know, companies do sort of unwillingly or, or not even sort of realizing it. One is this fear of failure, like 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 gonna swing big, you w- will invariably stumble sometimes. (laughs) So, you know, I think if you want to mitigate that, you have to start shining light on failure. That's, that's really the only way, like you have to start normalizing it a little bit and obviously like if an individual or if a team is like consistently failing and not learning, that you need to, you know, you need to sort of deal with. But I think sometimes it's, it's good to fail so, you know, like, and, and when, when you do fail it, like use it as an opportunity, like don't squander that moment to, to not learn. But yeah, I think like one, one example is, you know, instead of calling something a post-mortem, call it a retrospective so that it's kind of a positive thing, like, "Hey, we're learning from this thing." And then I think the other way to kind of mitigate the feel of failure is like you have to figure out how to give folks more at-bats 'cause like obviously anything that takes one year to ship and you like haven't gotten any customer feedback, like the stakes of that are just gonna feel so, so high. (laughs) Like

8. 23:21 – 27:27

   Retool’s “crazy ideas” list

   1. EMEeke de Milliano23:21

      any, like if you get it wrong, it's, it's gonna be devastating. So you have to figure out how to lower the stakes and I honestly, I think that's in some ways it's kind of easy. It's like, well, don't put too many resources against these kind of like bigger swings, like have them be small teams. And then also like just get customer feedback as quickly as possible, like don't wait until the thing is perfect, and that way you can kind of, yeah, like limit the, limit the risk. So yeah, I think that's fear of failure, that's, that's definitely one thing that stops teams from being innovative. There's kind of a, like a, I think a very practical one, like sometimes teams are just getting bogged down by like really urgent work, like there's just too much tech debt, there's too much product debt, bugs, instability. It's like massive hierarchy of needs, like there, there's just no way that they're gonna be able to focus on the like, you know, the enlightened (laughs) like bigger, creative stuff if they're just like heads down dealing with incidents all day. So if that's the case, like yeah, like d- you know, diagnose it and, and get your team out of that. And then I think the, the last reason why teams aren't always that innovative is because (laughs) I think thinking big is really hard. (laughs) And to some people, it comes pretty naturally but, for most of us, sort of, you know, mortal souls, it's, it's just (laughs) really, really hard and it's, it takes time. And when you're at a startup and you're just grinding day-in, day-out, you're just, like, you're just try, you're treading water, you're just, like, trying to make it through the day, like, taking the time to really think about, you know, the strategy and, like, where things should go and, and get creative, it's pretty hard. So, I call this, you know, 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, like, "Hey, this is part of your job to, to think bigger." So at Retool, we have these, these team charters and we do team planning and at the bottom of every team charter, we have a section called Think Bigger, with, you know, 20% more time, what would you do that isn't on this list already? And then another, I think, really neat tradition that we had at Stripe, we have at Retool now too, is this, uh, idea, uh, uh this, this, this thing called Crazy Ideas. So, at the beginning of every year, David will send out a, a blank, like, a blank doc to the org, and it's titled Crazy Ideas. 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, you know, a 10 to 100X difference for the Retool business." And then it's just, it's literally just a call, a request for crazy ideas. And the org loves it. It's, it's amazing. The energy around it is so cool, and it's, it's not just product ideas. It's different ways of, of how we should run our organization or, like, so it, like, it's really cool marketing ideas in there. So, it's just, that doc is awesome, and whenever I have, like, a down day, I just, like, scroll through that doc. (laughs)

   2. LRLenny Rachitsky26:17

      I know that you launched three different products this year, which I wanna talk about, which maybe came out of this big thinking, but a couple more questions just to dig into some of the stuff you just shared. One is this big doc of awesome ideas. What's come out of that? 'Cause, you know, I think of, like, hackathons and people have all this energy and it's exciting-

   3. EMEeke de Milliano26:32

      Yeah.

   4. LRLenny Rachitsky26:32

      ... and then they build all these cool things and then they don't, don't go anywhere. Do things come out of this, these elite and actual ideas that people ............................?

   5. EMEeke de Milliano26:38

      Yeah. Yeah, yeah. Every, so every year that we send out the doc, we look at the past year-

   6. LRLenny Rachitsky26:42

      Mm.

   7. EMEeke de Milliano26:42

      ... the doc from the past year and we're like, "Okay, like, did, what, did, did we do anything on this list?" And, like, consistently, we do anywhere between, like, three to eight things on the list.

   8. LRLenny Rachitsky26:49

      Wow.

   9. EMEeke de Milliano26:50

      Yeah.

   10. LRLenny Rachitsky26:51

       Is there an example of product that launched that came from that list that comes to mind?

   11. EMEeke de Milliano26:54

       Actually, probably at least one, if not two, of the sort of 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, you know, I would've told you, "Retool helps you build internal frontends really, really fast." But, you know, if you were trying to, uh, like, schedule a, a query to run at a later point in time or have something trigger or, you know, uh, uh, run an ETL task, like, you couldn't do that in Retool. So, that was actually one of the crazy ideas and, and that ended up becoming Retool Workflows, which, you know, we launched just last year

9. 27:27 – 28:47

   How to cultivate a failure-safe space

   1. EMEeke de Milliano27:27

      in November.

   2. LRLenny Rachitsky27:28

      Okay. We're definitely gonna chat a bit about that. I wanna go back to the two other suggestions you had. One is embrace failure, make it okay to fail. And then two is, don't let people get sucked into urgent stuff and have time to focus on important stuff. Is there an example of just, like, how to help people embrace failure? You talked about retrospectives. Is there anything else just, like, that you've found works either as a tactic, as a process, as a framework just to, like, help people get out of that? 'Cause, you know, you hear that a lot, like, "Embrace failure," and then people are like, "Oh, but I failed and you suck." So, yeah.

   3. EMEeke de Milliano28:00

      (laughs)

   4. LRLenny Rachitsky28:00

      Is there anything else along those lines you found effective to create that feeling?

   5. EMEeke de Milliano28:04

      Yeah. To me, it's always in the follow-ups.

   6. LRLenny Rachitsky28:06

      Mm.

   7. EMEeke de Milliano28:06

      So, like, you know, have people talk about the failure in, like, these sort of public forums where usually you talk about the successes. So, like, have someone actually, like, write a note that's like, "Hey, here are all my learnings from this thing that we did," and send it to the org. At Retool, we have a, a shipped at email list, so like, if you ship something, you know, you'll, we'll send to that. Have them send that email to the org and it's, it's just kind of an awesome way to celebrate or have them present at All Hands and share what they learned. And it almost always sort of results in a, I think a really positive twist.

   8. LRLenny Rachitsky28:37

      At Airbnb, there was, I think for a period, there was an award for the biggest failure, like, project in feature.

   9. EMEeke de Milliano28:41

      (laughs) Really? That's so cool.

   10. LRLenny Rachitsky28:43

       Yeah, like, a trophy or something. Yeah, it was, like, a short-lived (laughs) idea, which is funny.

10. 28:47 – 32:03

    Fostering risk-taking and innovation

    1. LRLenny Rachitsky28:47

    2. EMEeke de Milliano28:47

       Yeah, yeah, yeah. (laughs)

    3. LRLenny Rachitsky28:48

       And then on the second bullet point of urgency creating, giving people a chance to think longer term, is there anything there that you found to be actually effective to create that culture and give PMs and product teams a chance to think longer term and not just be stuck in the fires that they're dealing with?

    4. EMEeke de Milliano29:02

       There's a couple of top-down things and, I think, a couple of bottoms-up things. On the top down, I think sometimes you just have to be willing to fund some, someone with something. Like, they come to you with an idea and you're like, "Look, yeah. Like, take an engineer and, and go do it." And you just have to kind of give folks that, that sort of organizational buy-in. Like, actually, you know, I was thinking back to that, that engineer, Brian Krause at Stripe, who started, you know, kind of poking around on these, on this marketplaces model and I was thinking, like, I can't remember a moment when someone formally said to him, "This is now your job." Like, I think he just kind of went (laughs) and looked and, and went and, and dug into it, and then at some point, I think a manager was like, "All right. This is now your job." But yeah, no. I, I think you have to be able to sort of, like, fund, fund folks' time and, and give them that. Hackathons, I think, are like, pretty good for that stuff. It is kind of a moment for folks to, to take a step back. And then, you know, I think more than anything, in people's planning processes, uh, like, I really like asking folks, you know, like the sort of the 20% more time question or the other question is like, "Look, like, if you doubled the team today, what would you do?" That shows up in our, our planning processes as well, and I think it really helps people kind of break out of this, like... I, I think you kind of end up planning towards the sort of the team that you have, not the team that you should have. So I like how folks can break out of that process.

    5. LRLenny Rachitsky30:20

       Awesome. I really like the Think Bigger bucket in your planning docs, just like, "What would you do if you had more resources?" Just maybe a quick question there, is there, like, m- d- a bunch of detail that you ask them to put into that or is it just, like, a bullet point of big ideas?

    6. EMEeke de Milliano30:31

       ... just, yeah, folks can just go, go crazy on it. It's however-

    7. LRLenny Rachitsky30:35

       Got it.

    8. EMEeke de Milliano30:35

       ... they wanna take it. Like yeah, I- I've seen folks actually sort of like create entire demos. (laughs) But I- I actually think the trick is like less structure-

    9. LRLenny Rachitsky30:43

       Mm-hmm.

    10. EMEeke de Milliano30:43

        ... in those cases, 'cause you don't really want to d- pigeonhole or, or make, or make it even that intimidating for folks. Like if someone just wants to write down a few bullets, that's great.

    11. LRLenny Rachitsky30:53

        (instrumental music) This episode is brought to you by Eppo. Eppo is a next generation AB testing platform built by Airbnb alums for modern growth teams. Companies like Netlify, Contentful and Cameo rely on Eppo to power their experiments. Wherever you work, running experiments is increasingly essential, but there are no commercial tools that integrate with a modern growth team stack. This leads to wasted time building internal tools or trying to run your experiments through a clunky marketing tool. When I was at Airbnb, one of the things that I loved about our experimentation platform was being able to easily slice results by device, by country, and by user stage. Eppo does all that and more, delivering results quickly, avoiding annoying prolonged analytics cycles, and helping you easily get to the root cause of any issue you discover. Eppo lets you go beyond basic click-through metrics and instead use your North Star metrics like activation, retention, subscriptions and payments. And Eppo supports tests on the front end, the back end, email marketing, and even machine learning clients. Check out Eppo at GetEppo.com. GetE-P-P-O.com and 10X your experiment velocity.

11. 32:03 – 35:06

    The three products Retool launched this year

    1. LRLenny Rachitsky32:03

       Okay, so you launched three new products this year. Usually companies are lucky to launch one product a year. A few questions. One, just like tell us what those three were in case people are interested and wanna check them out. Two is, was that a good idea?

    2. EMEeke de Milliano32:16

       (laughs)

    3. LRLenny Rachitsky32:16

       Is it good to launch three new products in a year? And then three, what did you do organizationally to allow for this to happen? 'cause that feels-

    4. EMEeke de Milliano32:24

       Yeah.

    5. LRLenny Rachitsky32:24

       ... really ambitious and rare, and I'm curious what you learned from that.

    6. EMEeke de Milliano32:28

       So the three products we launched were, one was Retool Workflows that, you know, I- I talked to you a little bit about. It's like if you want to be able to sort of 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, of creating these, you know, different sort of workflows, but you can write your own code on top of it as well. Second product is Retool Mobile. So you could pretty easily build, you know, crud web apps with Retool but there are plenty of folks who don't sit behind their laptop at a desk all day, and, you know, for those folks who had a lot of companies who were like, "I- I want to be able to, uh, like a mobile native app," and so we launched that product. And then the third product was Retool Database. Um, so, you know, until very recently, like if you came into Retool, you could connect your data, you know, via your- your APIs or your database directly into Retool. But what we found is that actually a lot of folks like either don't have access to their database or they're actually just like they're trying to build an internal tool and they don't necessarily want to store that data in their sort of production database. So we built... Essentially like we spin up a PostgreSQL database for you and you can just access it by a really nice UI and- and manage it directly in Retool.

    7. LRLenny Rachitsky33:38

       Amazing. Okay, back to the other two questions.

    8. EMEeke de Milliano33:41

       Yes, okay. So I think your second question was: was this a good idea?

    9. LRLenny Rachitsky33:44

       Right.

    10. EMEeke de Milliano33:45

        (laughs) Yeah. Uh, I, you know what, I think in hindsight if I, if I were to do it again, I think maybe sequencing it would have maybe been slightly better, um, just because I think what we end up doing is we kind of ended up launching or 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 head space from the org, even though actually the teams themselves were not that big. Like it was just like, you know, we had all these products and we're just waiting for them to launch and waiting for them to launch. Whereas like maybe if we'd sequenced it, I think that would have felt probably also just more satisfying to the whole organization. But I mean, it ended up working out. That's, I think that's kind of the crazy thing is like, you know, we- we kind of were able to pull off launching these, you know, these three products. And by the way, I- I should caveat that, you know, the, sort of the- the further I get along in 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- and were happening before I came along. But, um, but yeah, it was- it was really neat to see how we- we got that all over the finish line in a year.

    11. LRLenny Rachitsky34:55

        And then the last question there is just: what do you think you did to allow for this? Because it's pretty rare you can-

    12. EMEeke de Milliano35:00

        Yeah.

    13. LRLenny Rachitsky35:01

        ... build so much. And I know the team's not huge, right? Like how many people work at Retool roughly?

    14. EMEeke de Milliano35:05

        Today we're

12. 35:06 – 38:00

    How Retool was able to launch several products at once

    1. EMEeke de Milliano35:06

       around 300 people.

    2. LRLenny Rachitsky35:07

       Yeah. So-

    3. EMEeke de Milliano35:08

       Um, yeah.

    4. LRLenny Rachitsky35:08

       How- how did- how do you structure an org to build three and launch? I didn't realize they launched around the same time. It's like, I'm picturing-

    5. EMEeke de Milliano35:13

       (laughs)

    6. LRLenny Rachitsky35:14

       ... uh, Elon Musk launching three rockets at once. How do you, uh, how do you allow for that to happen?

    7. EMEeke de Milliano35:20

       Yeah, I- I'm sure our product marketing team felt, (laughs) felt that way. Um... Yeah, a couple of things. We- we started really small with all these initiatives. So, you know, I think I mentioned we- we really had one or two people working on- on each of these products for like the first six months. Um, so it was like one engineer and one designer or one engineer and- and one PM. And they really didn't get funding until it was clear that there was something there. So they just, those teams just they spent a ton of time with customers, spent a ton of time building, a ton of time prototyping, and it was kind of the moment where it was like, okay, like there's a there there that- that we started to bring more people onto the team. So that was the first piece. The second piece is that we really treated them like startups where like Retool's the VC and like Retool funds with like resources and Retool's existing customer base which is obviously quite valuable because you kind of have all these customers you can- can market to and promote to. But then the teams really had to prove out ROI either in engagement or eventually revenue in order to be able to move forward. And then the third thing, and- 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. And now a lot of them are, they're- they're very much kind of... a part of the overall organizational processes. But very early on, they, they were kind of, they were running on their own, they were, you know, meeting quite independently with like one or two or three folks from the leadership team, and they were also just quite separate from the product itself. Like, I think Retool Mobile is 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. And we eventually decided that we were gonna 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, you know, bugs, yada yada, et cetera. 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 have been able to sort of really understand that or even like sort of like get broader in that kind of thinking had we sort of been, been stuck in the, the core Retool product. But yeah, there's 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, so we have to go and invest in that now. But I, I think it's totally worth it because your team can just move more quickly, be more independent, and, and think more independently too.

13. 38:00 – 45:37

    The amount of process needed through different stages of growth

    1. EMEeke de Milliano38:00

    2. LRLenny Rachitsky38:00

       In the time that you worked at Stripe and Retool, I know we chatted before we started recording, you think a lot about what is the right level of process for companies at different stages, and I'd love to just hear your thoughts 'cause I know, I know that's a challenge a lot of companies face. How much do we put in now? Ho- Do we get inspiration from big companies? Do we try to stay lean? Something AirBnB actually ran into, I'll just mention briefly, that there was a huge resistance to process for a long time, and so the product team was just kind of a little crazy for a bit and then-

    3. EMEeke de Milliano38:32

       (laughs)

    4. LRLenny Rachitsky38:32

       ... they were like, "Okay, we need product development process. We need deadlines and specs," and, and that helped a lot. So yeah. So let me ask again-

    5. EMEeke de Milliano38:40

       Yeah.

    6. LRLenny Rachitsky38:41

       ... just how do you think about the right level of process for a stage of company and what have you learned there?

    7. EMEeke de Milliano38:45

       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 because when we were at Stripe we were trying to figure out our planning process. We actually talked to, like, Amazon and Atlassian and Apple and, like, all these companies that we really, really respect and, and look up to, and I remember, you know, taking down notes from these companies and being like, "Yeah, like, this is awesome, but there's no way that this will work for Stripe." Like, Stripe was so much smaller than any of these companies. So yeah, they were showing us where we had to go, but no idea how to get there. And so, like, yeah, Lenny, maybe you can, you can help us figure out time capsules for companies and (laughs) what-

    8. LRLenny Rachitsky39:25

       I am, I am... Yeah.

    9. EMEeke de Milliano39:25

       ... processes make sense (laughs) .

    10. LRLenny Rachitsky39:27

        I, I am working on that, roughly.

    11. EMEeke de Milliano39:29

        Oh, nice (laughs) .

    12. LRLenny Rachitsky39:29

        I'm going company by company about how they think process and about process and then maybe I'll check in-

    13. EMEeke de Milliano39:34

        I love that.

    14. LRLenny Rachitsky39:34

        ... every, every couple years.

    15. EMEeke de Milliano39:36

        Cool. I love that.

    16. LRLenny Rachitsky39:37

        All right.

    17. EMEeke de Milliano39:37

        Um, but yeah, to, to answer your question directly, uh, process, yeah, it's... It really gives people a bitter taste in their mouth, I think, and process by definition is variance reducing. Like, you're introducing it because you worry that the variance in your org is too high. Like, you want people to sort of meet a certain standard. And the cost of that is obviously is, like, while you're 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, you know, the folks who, like, you know, I think actually don't really need process to do their best work. And so, that, I think, is always the tension that you have with process and obviously, like, one of the reasons why companies introduce process much more and more as companies get bigger is because it's just, it's harder to sort of like get all these folks who kind of don't need processing. You actually want to reduce the variance. This is actually a little bit of an aside, but it's kind of relevant so I'm just gonna mention it and you can feel free to let me know if it's too much of an aside.

    18. LRLenny Rachitsky40:44

        Let's get into it.

    19. EMEeke de Milliano40:44

        But (laughs) I, uh, I was, I was just listening to this awesome podcast with, um, with Russ Roberts who's a, a professor and he hosts EconTalk, I, I don't know if you listen to it, and he was in- interviewing this guy, Ian Leslie, who's just this great writer and who's just, I think, written this article that's basically something along the lines of like what it means to be human in the age of AI. And I thought he just articulated this idea so well which is like we're all really, like, so impressed when we see, like, Jack chat GPT-3, like, spit out this, this sort of piece of writing that feels very human-like. But what we're kind of forgetting is that over the last, you know, 10, 20, 30 years, we're actually, like, asking humans to be a lot more robot-like in that, like, we're really asking everyone to, like, standardize in a lot of ways and, like, we're making people a lot more formulaic. Like, if you think about how we ask people to... Or how we teach people to write, it's like, "Well, there's five paragraphs and there's your opening paragraph," and, like, there's, you know, you state your topic and so anyway, I, I think, like, the point is, is like we actually, I think, you know, the more formulaic, the more sort of like mass-produced you're trying to make something, the more you kind of quench people's creativity and I, I think sort of the further away you get from like the really, really high highs, and that to me is kind of the cost or process and, and rules and templates. So like, if you're gonna introduce it, be really, really sure that you're okay with that cost and give folks escape hatches. So I've started referring (laughs) to this as like the, the MVP, the minimum viable process. So if I give folks a template, I'm like, "Look, use the template, but if you wanna break out of it, please absolutely do," and, like, start writing this at the top of templates now. It's like, "If this doesn't work for what you're trying to explain, like, don't use it. But, like, just know that this is the minimum viable thing." Like, this is kind of like, "We're setting the bar here, but, like, go higher if you can, please." So anyway, that's, that's my sort of like long diatribe (laughs) on process. With all that said, I do think that companies...Yeah, there's just a set of documents that are like really, really valuable that every sort of like, I guess, level of the organization should have throughout its life cycle. And then, you know, I think how sort of involved it is or how like long term it is really depends on, you know, how big you are. But, you know, those, those, those documents to me are the charter. So, uh, what is your mission, your vision and your strategy? The goals, like what are you aiming to do and how are you gonna measure success? And then the roadmap. What is the thing that you're shipping? And I think the whole company needs these, the whole function, so like in product, like you need all three of these, and then within each team, you need all three of these. And I've kind of like noticed two things about this sur- this framework for myself. Like one, I've actually noticed that teams often work their way from like the bottom up versus top down. Like, they start with a roadmap. They're like, "What are all the things we're gonna ship?" Especially early on. And then like they kind of work their way into a charter. But I, I think it's really, really worth it to, like, start from the top down. And then the, the second thing that I've noticed is that, like, your time horizon really shifts as you get more mature. So like, you know, if you're very early on, you don't have PMF, like, you should have a charter but your charter should be like three months in the future. (laughs) 'Cause you can't look that much further. And, you know, if you're, you're kind of a, a company that's humming and going, your charter is probably, you know, it's, the horizon's like maybe a, a decade so...

    20. LRLenny Rachitsky44:11

        Wow. There is, there is so much there. Uh, I could go in so many different directions.

    21. EMEeke de Milliano44:15

        Sure.

    22. LRLenny Rachitsky44:15

        One thing I wanted to follow up on a little bit is this idea, such a great point, that process brings the best people down and kind of add- averages them out to kind of create consistency, and I'm curious if there's anything else you've seen succeed in allowing the best and most innovative brains to just do their thing? I know s- I know part of it is probably hiring amazing people, but yeah, is there anything else that's like escape hatch where it's just like, "Okay this person, just go, go figure this out"?

    23. EMEeke de Milliano44:44

        Yeah. To me, the unlock for organizations is managers for this 'cause like 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 (laughs) like, "We're honestly..." Like 'cause what you're doing is you're giving them some special treatment and you need to be kind of okay with that. And y- you also need to be okay with the organizational costs for that. Like, Claire, who used to be the, the COO of Stripe would always say like, "Are you willing to break the org for this person?" And I always thought that was like a really nice framing, and you kind of then need to decide who you want to do it for too. But yeah, I think some people are just that good that like, yeah, of course we'll break the org for them. (laughs) They're like, you know, they're gonna break the org in the best way possible, so.

    24. LRLenny Rachitsky45:25

        I love that term. Uh, I think Claire's coming on this podcast. You just wrote a book, right? Is that the same person?

    25. EMEeke de Milliano45:30

        Yeah.

    26. LRLenny Rachitsky45:31

        Okay, great.

    27. EMEeke de Milliano45:31

        Yeah, she just wrote a book, yeah.

    28. LRLenny Rachitsky45:32

        All right, we just booked her. Come and well, maybe we'll spend some time.

    29. EMEeke de Milliano45:35

        That's awesome.

14. 45:37 – 47:34

    Why you should build products for your “best users”

    1. EMEeke de Milliano45:37

       (laughs)

    2. LRLenny Rachitsky45:37

       Do you have any other product building philosophies that you found especially useful in your time at Stripe and Retool, anywhere else?

    3. EMEeke de Milliano45:45

       I have a, like a couple of, I guess, sort of like mental models I use. The, the first is, um, build for your best user, not your worst user. And what I mean by that is I think it's actually really easy to kind of get stuck or to, to sort of focus on like 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 kind of end up sort of shaping the product in these like really weird funky ways (laughs) to make up for that. Whereas, like, in reality, the worst users are always like they should be a fraction of your users anyway. So, like, you shouldn't really, really be building for them. Think a really good example of this is like onboarding processes where, you know, you're, you're probably going to be building an onboarding process where you're trying to like maybe sort of collect a lot of data or try and like figure out like, "Hey, how do I help this user who, like, maybe isn't sort of well-suited for my product be successful?" Like, really should just be building an onboarding process for the user who's, like, gonna jump into your product and get it immediately. It was, I was thinking about this actually just the other day 'cause we were in this product review and we were talking about this other new product that we're thinking of exploring.

    4. LRLenny Rachitsky46:48

       More products.

    5. EMEeke de Milliano46:48

       And we're going-

    6. LRLenny Rachitsky46:49

       Never ends.

    7. EMEeke de Milliano46:49

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

    8. LRLenny Rachitsky47:05

       That's-

    9. EMEeke de Milliano47:05

       ... you know, put that on the back burner. (laughs)

    10. LRLenny Rachitsky47:07

        That's an interesting approach 'cause usually you are all trying to optimize a flow, get more people through it, which are the least good users. You're saying you found more success just like focus... Is this more initially focus on the users that will understand this and be excited about it and make that work-

    11. EMEeke de Milliano47:21

        Yeah.

    12. LRLenny Rachitsky47:21

        ... really well and then kind of over time build on that?

    13. EMEeke de Milliano47:23

        Yeah, totally. Yeah, sure. If you're like at the end, you're like trying to optimize, et cetera, absolutely. But in that sort of early product development stage, it's like it's-

    14. LRLenny Rachitsky47:31

        Got it.

    15. EMEeke de Milliano47:31

        ... it's just not worth it to, to be too focused on that.

15. 47:34 – 48:37

    Build the scooter, not the axle (why you should make something simple but functional first)

    1. EMEeke de Milliano47:34

    2. LRLenny Rachitsky47:34

       Sweet.

    3. EMEeke de Milliano47:34

       So that's, that's one. Um, the, the other that our, our head of design, Ryan, I think always kind of reminds us of is, is, um, build the scooter, not the axle. So, you know, if you're trying to build the minimum viable product for a car, like don't sort of build just, you know, the wheels and the axle. Like, build the scooter first and then from there you build the bicycle and the motorcycle and then the car and it's always just such a good reminder. Like, you always kind of want to start building the whole thing but like really try and think about, like, the slice that gets the customer to, like, complete value on a smaller thing first. So with Retool Mobile, for example, like, it, there's just so much you could be building there and we decided very specifically like, "Hey, we're only gonna build this for companies that have field workers and, like, you know, they would need to do inventory management." And like it's a very specific slice but it helps kind of get through from, you know, something that was actually like viable beginning to end. Um...

    4. LRLenny Rachitsky48:25

       Got it. So it's, it's an approach for MVPs basically. Make something simple and functional, not just something-

    5. EMEeke de Milliano48:30

       Yes.

    6. LRLenny Rachitsky48:31

       ... barely, like not actually working, but getting you to some dream product eventually.

16. 48:37 – 49:57

    The 70-20-10 framework for investing resources and time

    1. LRLenny Rachitsky48:37

    2. EMEeke de Milliano48:37

       Yeah. And yeah, and then the last one is, um, this idea of, of 70/20/10 split investments. Like I, I really think that a lot of product management can sometimes be reduced to funnels and portfolios. (laughs) So the, 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 ini- initiatives that-... aren't core, but, like, they're strategic to the company that you know you have to do them. And then 10% of your time should be going towards bets.

    3. LRLenny Rachitsky49:11

       That's actually exactly the same heuristic I have always used. One question there is how do you think about-

    4. EMEeke de Milliano49:16

       Oh.

    5. LRLenny Rachitsky49:16

       ... maintenance and bugs within that?

    6. EMEeke de Milliano49:18

       Yeah. Uh, to me that falls, like, squarely in the 70%. Um, so yeah, like, core product, tech debt, sort of the, the stuff that you kind of, the maintenance mode type stuff, and core product is obviously you're also doing a bunch of new stuff there too. But yeah, like no more than 70% of your resources should be going there.

    7. LRLenny Rachitsky49:35

       What did you say the 20% was?

    8. EMEeke de Milliano49:37

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

    9. LRLenny Rachitsky49:45

       Got it. So the way I break it up is 20% I think is where I put bugs and maintenance, and then 10% was like-

    10. EMEeke de Milliano49:50

        Oh, interesting.

    11. LRLenny Rachitsky49:50

        ... big old, big ambitious bets. So it was similar ratios, but different things go into the buckets.

    12. EMEeke de Milliano49:56

        Cool.

17. 49:57 – 50:59

    Finding time for maintenance and bug fixes

    1. EMEeke de Milliano49:57

    2. LRLenny Rachitsky49:57

       But let me ask you a similar question. How do you just, at Retool and maybe even at Stripe, think about finding time to do maintenance and bugs? Do you build it into roadmaps? Do you set off time to just fix all the bugs? I know it's probably an evolution and goes back and forth, but any thoughts?

    3. EMEeke de Milliano50:12

       Yeah. This I think is, it's, it's really one of the trickiest parts of product management in my mind. We don't have a company wide sort of process on this. It's, it's pretty team specific. Some teams do like Friday bug bashes. Other teams are just kind of, you know, as products roll out, we'll, we'll kind of work on them as they go. I was actually speaking to a product manager at a different company who mentioned that they just spent the last 18 months doing basically just product polish and bugs, and I, you know, I think they landed in a place where they just, they had to do it because they just had so much debt. But, uh, you know, luckily we're not there yet. But right now we let most of the teams just kind of do it, do it themselves and, uh, figure out what makes sense for them.

18. 50:59 – 53:29

    How Retool’s PMs keep close to customers

    1. EMEeke de Milliano50:59

    2. LRLenny Rachitsky50:59

       Okay. Awesome. I wanted to go back to something that I've heard about Retool that you all are really good at, which is PMs being really close to customers. And I'm curious what you've done there or what the team has done there that has been really effective.

    3. EMEeke de Milliano51:13

       Well, I do think every good product team figures out how to sort of 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. The first is we have a lot of PMs who used to be in customer facing roles at Retool. So, um, I, I obviously am a big fan of that. I, I think it's, 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, I really like that about, you know, PMs who have had those conversations with customers and they really, really get it. Second is because the Retool product is so technical, and I do think this just depends on what product you have, like our PMs are, are really very technical. Like everyone has, you know, either a CS degree or has, has done some sort of engineering in the past. Third is we use Slack very heavily to, to talk to our customers and interact with them. So we get this might have hundreds of Slack channels with customers every time, you know, we're testing a new product or, you know, we're, we're kind of a new customer who's, who's somewhat large comes online. Like, we will work with them in Slack to, to get their off the cuff feedback just back and forth. It's really nice. We just have this direct line to them, which is awesome. And then the fourth thing we do is we use Retool to build Retool. So, um, our product roadmap lives in a Retool app, and the app that we use to, you know, 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, that really helps as well.

    4. LRLenny Rachitsky52:57

       Wow. I didn't know that. That is very cool. So you built like a task management product using Retool?

    5. EMEeke de Milliano53:03

       Oh, yeah. Well, we, we build many... Uh, basically all of our internal tooling happens in Retool, like our PMs, the, all their team dashboards are in Retool. All of their, you know, all their... Yes. Their task tracking is in Retool, submitting, uh, Linear requests or bug requests happens in Retool and then goes to Linear. So it's just, uh, yeah, it's how we run the company.

    6. LRLenny Rachitsky53:23

       You haven't been able to replace Linear yet. That's cool.

    7. EMEeke de Milliano53:26

       (laughs)

    8. LRLenny Rachitsky53:27

       Big fan of Linear.

    9. EMEeke de Milliano53:28

       Nice.

19. 53:29 – 56:10

    Building product in a sales-led org vs. product-led growth

    1. EMEeke de Milliano53:29

    2. LRLenny Rachitsky53:29

       Okay. Two more questions and then I'll let you go. One is around product led growth, which I don't want to get too into. We talk about it a bunch on this podcast.

    3. EMEeke de Milliano53:37

       Okay.

    4. LRLenny Rachitsky53:37

       But it's interesting that Stripe was very product led growth. It was just self-serve PMs, engineers, whoever just started using it. It grew and became enterprise-y down the road. Retool, on the other hand, I think people think it's product led growth. I imagine it's actually sales led mostly. And so I'm just curious what you've learned about the difference between building product and leading product teams within a sales led org versus a product led org.

    5. EMEeke de Milliano54:03

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

    6. LRLenny Rachitsky54:11

       (laughs) So true.

    7. EMEeke de Milliano54:11

       Like whenever, whenever I talk to, to candidates, I feel like you can always tell what, you know, their company has because they'll be asking a lot of questions about the opposite. Like if they're a product led growth company, they'll be like, "Well, how are you guys thinking about enterprise?" And then if they are like more of a sales led growth company, they're like, "Well, how are you guys thinking about, you know, your self-serve motion or your product led growth?" My main takeaway just, you know, in, in sort of... And, and I, I don't know if I've even sort of used the dichotomy of product led growth or sales led growth with Retool. Like I think we do have a lot of product led growth, but we have, we work with a lot of enterprise customers and a lot of our revenue comes from enterprise customers and we have like a fantastic sales team. And I, I think the, the main thing is that you just have to really figure out your, like, interaction mechanisms with, with sales and that, that just has to be so, so tight. And it goes in both directions. There's obviously like how you get feedback from them because they are so often on the front lines talking to customers more so than product managers even. But it also goes the other way. Like if you are going to ship something or if you are going to, you know, put out a roadmap, like how do you make sure that the sales team has...... everything that they need, the sales and, you know, in, in Retool's case, the success team and the support team, has everything they need to accurately talk to customers about that. 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 gonna feel like it's, it's too high level or it's, you know, too low level for folks who maybe are new. So this year we're actually trying something different (laughs) . We are doing a science fair where each product team has a little booth and they get to sort of stand there and anyone who has questions about the product (laughs) can come, you know, from the go-to-market side can come and ask questions and get demos and go, like, as deep as they need to. So I'll let you know how that goes, but I'm excited to, to, to experiment with it.

    8. LRLenny Rachitsky56:04

       Okay. Are there gonna be foam core boards and will there be ribbons?

    9. EMEeke de Milliano56:07

       (laughs) There'll, there may be prizes. Who knows? (laughs)

    10. LRLenny Rachitsky56:09

        Oh

20. 56:10 – 58:43

    The product talent portfolio: how to build diverse, balanced teams

    1. LRLenny Rachitsky56:10

       my God. I can't wait to see a picture of this.

    2. EMEeke de Milliano56:12

       (laughs)

    3. LRLenny Rachitsky56:13

       Final topic. You have this concept that you call the product talent portfolio. What does that mean and how have you found that useful in your product leadership life?

    4. EMEeke de Milliano56:25

       Yeah. Yeah, it's back to the, like, all of product management is portfolios and funnels. I think it's really tempting as a manager to build a team in your image because you understand their skill sets and you value those skill sets, and you're gonna be able to detect and assess those skill sets better. But the best product teams in my mind have really figured out how to balance the, you know, the, the talent portfolio. So instead of sort of having a bunch of PMs who all spike in one particular area, figure out how you can, you know, have or create complementary skill sets for the whole PM team so that the whole is much stronger. 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, you know, 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 sort of more conventional traditional product management skillsets. 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 that sort of, you know, the core, uh, and, you know, in the Retool case sort of the core Retool product management, you know, vibe. So that's one example. I think there's, like, others as well, like some PMs are just incredible execution machines, other PMs are, like, amazing visionaries. Like, you kind of want a little bit of all of them, and you want to also balance within all of your different pillars, so, you know, like, we have three different s- or product pillars at, at Retool and there's kind of needs for all those pillars and I always push the leads to sort of hire people who don't look like them (laughs) so that, you know, we, we have balance everywhere.

    5. LRLenny Rachitsky58:07

       I love that. Do you actively as you're hiring, like, "Hey, were you strong in these areas? Here's the person we need here. We want, like, this specif-, like, super strategy mind person." Is that actually how you think about this?

    6. EMEeke de Milliano58:20

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

    7. LRLenny Rachitsky58:35

       Amazing. Any last pieces of wisdom or thoughts before we get to our very exciting lightning round?

    8. EMEeke de Milliano58:42

       I think that's it

21. 58:43 – 1:02:55

    Lightning round

    1. EMEeke de Milliano58:43

       on my end.

    2. LRLenny Rachitsky58:43

       Okay. We got through everything we, I was hoping to get through.

    3. EMEeke de Milliano58:46

       (laughs)

    4. LRLenny Rachitsky58:46

       So with that, we've reached our very exciting lightning round. I've got six questions for you. Are you ready?

    5. EMEeke de Milliano58:52

       I'm ready.

    6. LRLenny Rachitsky58:53

       What are two or three books that you recommend most to other people?

    7. EMEeke de Milliano58:57

       Bird by Bird: Instructions on Writing and Life by Anne Lamott. It's incredible, so touching, really great. Also I think product managers should be great writers, so love that. And then the other book that I was gonna say but I'm glad you mentioned Claire is Claire's book, Scaling People, which is coming out. I, I had a very small hand in ghostwriting for her a little bit in the first draft.

    8. LRLenny Rachitsky59:18

       Whoa.

    9. EMEeke de Milliano59:18

       So I use a lot of the early chapters from that book (laughs) still in management, and I still recommend, you know, recommend sort of the tactics in there. So I'm, I'm excited for her to, to get it out.

    10. LRLenny Rachitsky59:29

        Wow. I've been hearing about ghostwriting as a career recently and it feels like it could be an option for you down the road.

    11. EMEeke de Milliano59:35

        (laughs)

    12. LRLenny Rachitsky59:35

        And I'm excited to read the book. I haven't gotten a copy yet, and I think you can pre-order it now and we'll link to it in the show notes.

    13. EMEeke de Milliano59:41

        Nice.

    14. LRLenny Rachitsky59:42

        What's a favorite other podcast that you like to listen to other than maybe the one you're on right now?

    15. EMEeke de Milliano59:46

        Mm. Yeah. (laughs) This one's great. I can't choose between these two. The one is, um, Lex Fridman and then the other is, um, Econ Talk by Russ Roberts. I, I really like that both of them are... Like their agenda is, like, curiosity, which I love.

    16. LRLenny Rachitsky59:59

        Totally resonate there. What is a favorite recent movie or TV show that you've enjoyed?

    17. EMEeke de Milliano1:00:04

        Is it too basic to say White Lotus?

    18. LRLenny Rachitsky1:00:07

        Cool. It co- that's, like, the most mentioned one which is, says a lot, right? That just says to how good that is 'cause I, I love it too.

    19. EMEeke de Milliano1:00:14

        (laughs)

    20. LRLenny Rachitsky1:00:14

        But that works, that works. Uh, season one or season two?

    21. EMEeke de Milliano1:00:17

        Oh, season two all the way.

    22. LRLenny Rachitsky1:00:19

        Yeah, same.

    23. EMEeke de Milliano1:00:20

        (laughs)

    24. LRLenny Rachitsky1:00:20

        I'm excited for season three. (laughs) No spoilers. Favorite interview question that you like to ask candidates?

    25. EMEeke de Milliano1:00:27

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

    26. LRLenny Rachitsky1:00:31

        Hmm. Interesting, 'cause most people look for do they believe it's luck versus, like, their ma- in- made skill.

    27. EMEeke de Milliano1:00:38

        Yeah.

    28. LRLenny Rachitsky1:00:38

        So you don't even allow them to say luck. Interesting.

    29. EMEeke de Milliano1:00:41

        Yeah, 'cause, uh, you know, I think humble people will always say luck in some way and, you know, I always kind of want to know, like, did you, like, how self-aware are you basically and I, I think, and how curious are you? And I think people have really sort of gone back and reflected on i- why, why are they where they are today really, really says a lot about how they think about the world.

    30. LRLenny Rachitsky1:01:00

        I love that. What are some SaaS tools that you love or use often at-

Episode duration: 1:02:55