Shipping Products

"It was a pretty big effort to rewrite Wordle in our tech stack, give people the ability to store their stats and streaks, bring games to all of our major surfaces. We just tried to do it in a thoughtful way, where we didn't break anything."

"PR has its time in place, but I think doing it before you have validation that customers definitely want, the thing is quite risky and it can lead to a lot of sun cost once you get it out because you need to see it through."

"The Sora Android app, like a fully new app, we built it in 18 days and then 10 days later, so 28 days total, we went to the public... number one app in the app store with a handful of engineers. I think it was two or three possibly in a handful of weeks."

"Execution eats strategy for breakfast... if you have great strategy, perfect strategy but poor execution, you don't win because your strategy never makes it to the market. And what's even worse is that you have learned nothing. You don't know whether it was your strategy that was wrong or whether it was your execution that was wrong."

"Let's actually just deploy it really quickly to show people how you can deploy... We use Google Cloud. So we abstract all of that away from you, but we use Google Cloud behind the scenes."

"They understand that there needs to be relentless focus on execution, and if something is 99% done, it's closer to 0% rather than 100%."

"Get it out as fast as you possibly can. Everything they tell you about making sure that you get a product out really quickly is totally true. The faster you get it out, the more feedback you get. That is a positive thing. And now I index on that when we try to build."

"We started the company August 2012... summer of 2017 we made our first money. Don't do that. Get to market faster. I wish we had... get something that you can have that people can see the vision of, of where you're going, but don't do what we did. Get to market faster."

"Velocity of shipping is our number one core value in development team. So we do anything and everything to just keep it going up, up, up and into the right... we lean on our engineers to do a lot of product work. We call them product engineers, and they have to go and they have to announce the thing that they've shipped."

"The most important thing you have to do in a product is make trade-off decisions... The idea is like, 'This is the person who makes those.' ... It has to be that you can keep it in somebody's head. So yeah, called the chief engineer."

"Our engineering goal is every engineer should ship a marketable product every week."

"I think the recipe for all this is constantly small teams have a single-threaded focus, give them the resources they need to execute big lofty goals, very tight timelines, and then shield them from the chaos that is the rest of the organization."

"Action is the first principle of business. You do stuff and my book is very oriented towards that. The idea was not to tell you what to do, but to give you guideposts while you're on that journey. People that are enthused about it, I encourage you to do stuff."

"The secret of product quality is blood, sweat, and tears... a great product is made up of a thousand little details and so you're never really done. There's a humility that comes from the process also of why the best product builders will say nine nos for every yes. Because when you say yes, it's like adopting a puppy. A feature is like adopting a puppy. It grows into a beast that you have to take care of."

"One good indicator is if each new Office Hour there is really exciting new stuff, right? We're not talking about the same thing we talked about two weeks ago or four weeks ago. They've already done that stuff... progress on this weekly or biweekly timescale is a really good indicator of someone who'll succeed."

"Product managers are the mode of power behind execution and impact. And if you stall out or you don't do your job, the project's probably going to stall out as well. And so you're the ones, especially with a TPM, if you're lucky enough to have one in the back of the ship, kind of beating the drum and driving everyone forward."

"I find proof of existence to be an incredibly powerful proof, rather than proof by theory or proof by debate. It's like, 'Look, we did it one time. Hey, I'm holding the piece of paper.'"

"In many of those companies, they should focus on creating these sort of areas or pods where a company can, a team can get in the reps that they're trying to be able to do... Shipping and learning, going through the full loop."

"For execution, it would be things like me attending another PMs meeting. 'Oh, I heard this person is amazing at executing. Let me just see how they're on a meeting.' And then you're like, 'Whoa, things we didn't notice.'"

"Worse is better and tech debt is a champagne problem. And what do I mean by that? It's really to help me combat this perfectionism because perfect doesn't exist and you should instead go with good enough because when you ship, that's the moment when you get to learn a lot from your users."

"Literally the first two years I was at the company, the stated product strategy for Twitter was refine the core. It was like, we're not making any big bets here, team. Our goal is to keep turning the knobs that are working."

"The median time from a post going live to a note showing up was five hours, which is like crazy fast. Typical fact checking is like two to four, at least it's really common to see it take two to four days."

"We actually believe that when you start building the thing you actually start realizing more how it should work and how it should be better. A lot of times with the teams we tell them, 'Just put it there in, I don't know, the first week almost. After you have some designs in place or some design ideas, just put it into the app and ship it to production.' It's only visible to us so we internally can test it out."

"We have this philosophy, we call iterative deployment, and the idea is we're all learning about these models together. So there's a real sense in which it's way better to ship something even when you don't know the full set of capabilities and iterate together in public."

"We were given a pretty strict deadline that we needed to launch by and I pushed it out three times. That's not because of this one animation, but it's because of a series of decisions where we said, 'This is what we believe we need to ship, and this matters much more than hitting some artificial external GA date.'"

"How do you get to a very high ship velocity, and the ability to experiment and learn fast. At a broader level, especially during the initial phases, if you're not learning, you are really not doing anything well. You've got to be learning. You've got to be learning good things, bad things, doesn't matter. You've got to be learning. Having the experimentation velocity, having a building culture where engineers are able to check in code, see the results, and then quickly come into another release and stuff like that, I think that's really important for a consumer product."

"In terms of delivery principles, things like small frequent uncoupled releases. For most companies that's CI/CD, instrumentation of everything, monitoring of everything."

"We have a product quality list, which we lovingly at Rippling call the PQL... it articulates in the simplest ways the standards we want you to meet when you ship a product. It doesn't apply to every product, not every line applies to every product, but it's comprehensive and it provides me with a framework for iterating over time as we learn."

"Feature flags are the bane of my existence... I added a line to the fucking PQL that said, 'You are allowed to have one feature flag that governs your entire product at ship.' It's an extreme standard that might not be achievable, but it's the standard we aspire to."

"I just think about putting things early on staging and getting people involved in the cycle as opening up the doors to the product development process, and hopefully, that just elevates the quality of the product."

"We really rapidly became bottlenecked on other things like our merge queue... We had to completely re-architect it because so much more code was being written and so many more pull requests were being submitted... I've just found all these new bottlenecks in our system, there's an upstream bottleneck, which is decision making and alignment."

"If you look at people who are at the pinnacle of their craft, you can basically tell how good the output is going to be of their work product by how fast they're going. If they're going really fast, and they're obviously not being sloppy and then leaving a mess all over the place, it's like, 'Yeah. Well, they got there because this is just second nature to them,' and they're able to go at a really rapid pace and try stuff."

"What it really looks like is you have some rough time budget for how long you think something's going to take. By the time 10% of it has passed, after week one, you have something that works that tests some kind of key hypothesis internally."

"It means you don't need a pixel perfect design. It means you don't need to make sure that all of the little UI bugs and stuff like that are solved because none of that really matters. What matters is you have working software that you can interact with, and you can see if it feels good."

"I just really want to jump to the punchline of like, 'Okay, why can't we do this now?' or, 'Why can't we do it tomorrow?' ... if this was the most important thing and you wanted to truly maximally accelerate it, what would you do? That doesn't mean that you go do that, but it's really a good forcing function for understanding what's critical path versus what can happen later."

"You won't know what to polish until after you ship. And I think that is uniquely true in an environment where the properties of your product are emergent and not knowable in advance. ... shipping is just one point on the journey towards awesomeness, and you should pick that point intentionally where it doesn't have to be the end of your iteration at all."

"Speed and stability move together. Most people only think about this from the speed standpoint, which means when you move faster, you are more stable, which means you're pushing smaller changes more often, right. Because if you're pushing all the time, it's going to be very, very small changes, which means you have a smaller blast radius."

"Most teams can move faster. But faster for what? We can ship trash faster every single day. We need strategy and really smart decisions to know what to ship, what to experiment with, what features we want to do in what order and what rollout."

"if you're also not shipping a lot of things to market quickly enough, then it just doesn't matter that much."

"the more tries you have at it, the likelier you are to get it right. So we're not actively monitoring how fast does it take us to ship things to market."

"What we'll wind up doing often is have a team do a two-week customer love sprint, almost like a hackathon, but with that burndown list of what we think is the lowest effort, highest impact changes that we can make to generate more love from our customers... At the end, the goal is to ship all of them. This isn't hacks that you throw away."

"In my opinion, your tempo framework is more important than your org design. And so if you've ever had a team that seems really, really smart, but they're always planning or they don't really ship a lot... you probably don't have enough alignment on what good looks like in terms of tempo."

"We have a principle called Ship to Learn. And, we've actually changed it since... Ship fast, ship early, ship often is what it says now... If you ship early, and fast, and learn fast, you can change fast, and you can improve fast."

"How much to spend time ahead of launch really does depend on the markets and the structure, the nature of your business model... That's why when you have mission-critical products like email where you are interfacing with customers, with candidates, with investors, it turns out to really matter. Email is mission-critical. It's not something where you can simply launch with a half-baked product."

"We basically got, I mean, this was probably five to 10 people worth of people originally... We had that for a while, and then we got to a point where it was feeling good, the trusted testers were liking it, reporting good stuff, and then we it to this Labs moment."

"I did not leave the office for the last 22 days, slept for four hours a night upstairs, and if anyone had a question, I could tell them who to talk to. That was so thrilling. It was so thrilling to make those decisions, to cajole this team, none of whom were in it for the money, to make something we were proud of."

"The very first thing that anyone, when you're starting off, produces is outputs, okay? The output can be launching a product, it can be analyzing and running an experiment, and it could even be just being a part of the team and contributing to a go-to market strategy. So focus on that output significantly."

"Outputs is shipping products, but it also comes in smaller things. For instance, if you are sourcing content for your homepage, what are the different avenues that you can source content from? What is the easiest to source? What is the most difficult to source? Just ranking it all in that order goes a long way."

"the speed that we shipped at Seth HQ was just beyond. It just blew away what I think normal people think of as fast, but it was also still so good. And so I think that rigor and that refusal to accept anything but excellence was just so awesome. And it really spoke to me because I care a lot about craft."

"As part of the GSD updates, hopefully we encourage people to share high fidelity updates, which is not just imagery, but actually a demo. ... This short circuits a lot of misunderstandings, because you're like 'I'm going to try it.' And you're not waiting until the end."

"assume you don't know. And the follow up to that value is, 'So we got to get going.' It's like dropping in a new city. You just got to walk out the door of your Airbnb turn left and ... Maybe you'll turn right and then you'll hop on the subway, but you just got to get going and see what you find. And so, we have this attitude of... I've no idea what I'm doing. I have no idea what's going to happen. So we've just got to get going."

"If you can continuously push up what you ship by a week, you're going to end up lapping competitors who are just one week behind because you're going to start the next thing a week sooner, and you're getting that 1.1, 1.01x return."

"I want to make sure a project is perfectly executing, because only then can we really reevaluate whether or not this strategy is right or wrong. We're in the worst of all worlds where we are imperfectly executing and therefore, at the end of the day, the project might fail, but we don't know why."

"Everyone says we go fast, but it's like, yeah, we had a hackathon in November, we had another hackathon in December, we started the company officially in January, we got the prototypes out to initial users in February, we did a launch in March, we got our first customers in April... basically truly pushing the pace in every spot where we possibly could has really made a difference for us."

"We have a motto in the product org, it's very simple, single sentence, deliver customer value faster with high quality. That's it. Everything that we do... is based on this one single statement and it has three attributes."