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.' 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.

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.

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.

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.'

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. 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.

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.'

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.' 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.

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.

Build the scooter, not the axle. 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.

Build for your best user, not your worst user. 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.

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.

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.

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. 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.

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. '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.'

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.

We started really small with all of these initiatives. 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.

We were really deliberate about keeping these teams separate from the rest of the org, especially early on. 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. 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.