Lessons from Mark Zuckerberg on moving fast in product development

Here’s Mark Zuckerberg talking to Tim Ferriss about product development on virtual reality gear:

… being able to just work on a project that’s a 15-year project, where there’s—a lot of it is an engineering problem that you just need to go build, but a lot of it is also unknown, right? So there’s six or seven key unknowns that we just have multiple teams going out and trying to attack different approaches at that. I just think it’s a fascinating and fun way to make progress. And of course each year you’re intercepting and launching a new product. So I find this to be some of the most exciting work that I’ve ever gotten to be a part of. And I hope that for the rest of my career that I get to engage in more projects that are sort of longer term oriented with this mix of engineering and science and in, kind of, continual milestones. I think it’s just a great way to make progress in the world.

Who says the commercial world fixates on short timelines and DoD has the “patient capital” to focus on the long-run? In many ways, I think DoD’s funding in impatient, driven by unrealistic schedules where most of the time is stuck in paperwork and consensus building. Moreover, Zuckerberg has been at Facebook more than 15 years and will probably be there 15 years later to keep the vision and founder mindset going. A DoD program would see at least five or six rounds of leadership turnover in that time.

It is probably the case that DoD needs a variety of different sub-cultures simultaneously in acquisition. Here’s Zuckerberg on one of Facebook’s values and how it changed:

And I think part of this is that good values, you need to be able to give something up in order to get them. So around Move Fast, we’ve always had this question, you can’t just tell people to move fast. The question is: what’s the deal? What are you willing to give up? And famously, it used to be Move Fast and Break Things. And the idea was that we tolerated some amount of bugs in the software in order to encourage people to move quickly. Because moving fast, I think, is the key to learning. You want to increase the iteration cycle so that way you can get feedback from the people you serve quickly, and then incorporate that into the product.

 

So we would literally get into situations where competitors of us would ship once a year, once every six months, and we’d ship code every day. Of course we’re going to learn faster, and we’re going to build something better if you’re shipping something every day. So the question is: what are you willing to give up?

That’s the kind of language folks in DoD have been trying to use, but the institution is not comfortable with moving fast, and it is especially uncomfortable with breaking things. That could lead to a multi-year review by oversight.

As Facebook matured, it changed its value statement. It still focused on speed, but it outlined a different way to get there:

And so it used to be we would tolerate some amount of defects in the product. It got to the point as the company grew that we were producing so many bugs that going back and fixing them was actually slowing us down more than we were speeding up. So I still thought, okay, moving fast, this is still a really important thing. We’ve got to change how we do it. So we kind of evolved to building a somewhat less sexy phrase: Move Fast with Stable Infrastructure. And basically the new bet was we were going to invest disproportionately in building up good infrastructure and abstractions inside our companies. So that way the average engineer who comes here is going to be much faster and more productive at getting things done than in other places.

That makes a ton of sense, and it certainly part of the DevSecOps initiatives being created around DoD. And just a little bit more on how Facebook (now Meta) finds every opportunity to get product user feedback, they regularly test prototype a VR product at meetings in their own company to get more data and feedback:

But we just have a rule that everyone who’s in leadership or management should be, basically, doing at least one standing meeting a week in Workrooms. We want to get the feedback loop going that that team now is overwhelmed with feedback on how to get it to be even better, but I think one of the outcomes of this is I think Workrooms is going to probably learn what they need to do to be a great product and a lot faster than a lot of others in the space. So I think that that’s one way to operationalize these, but you’ve got to operationalize them if you want them to be real. Otherwise, they’re just words that you put on a website somewhere.

Be the first to comment

Leave a Reply