Decoding Mark Zuckerberg's Product Strategy: "Ship Frequently". Part-A: Powered by E2E (UI) Test Automation
"Release Early; Release Often" is so Important, but why few can achieve it?
(Update 2025-02-07): Part-B: How to Implement Real "Ship Daily"?
First, let’s hear Mark Zuckerberg describe his successful “formula” for Product Strategy (source: LinkedIn post).
“I view the product strategy less as any one specific thing and more as how do we iterate and learn as quickly as possible how to make each thing better for for the people we’re trying to serve right. so if like I Define our strategies we can learn faster than every other company we’re going to win. We’re going to build a better product than everyone else because we’re going to get it out first or early; We’re going to have a good feedback loop; we’re going to get get a bunch of feed back we’re going to learn what people like better than other people, and then over time by the time, you get to you know whether it’s version three or four or five I mean they’re not even discreet versions because we you ship so frequently it’s just you learn faster so I think that’s basically the formula.” — Mark Zuckerberg (2024–09–10)
Some readers might think, “Mark did not mention E2E test automation”. This article aims to decode that for you. For impatient readers:
“Facebook is released twice a day, and keeping up this pace is at the heart of our culture. With this release pace, automated testing with Selenium is crucial to making sure everything works before being released.” — DAMIEN SERENI, Engineering Director at Facebook, at Selenium 2013 conference.
Velocity is “Ship Frequently”, to production, daily
Many software teams are now confused by the term "velocity," which was introduced by so-called "fake Agile coaches." It often refers to perceived progress measured against arbitrary, made-up user story points—a concept whose creator has since apologized for.
Real Velocity means shipping daily, something I've been doing for over a decade with all my web apps. (clarification: "Daily" means whenever changes are made that day). Whether you are a small software start-up (like mine) or a tech giant (like Facebook), this No.1 software strategy is feasible.
"Release early; release often" refers specifically to releasing to production. "Early" and "often" should adhere to defined time frames, typically measured in days. Without those specific, “release early; release often” are just meaningless slogans, as in most software companies now.
Continuous Delivery also means delivering to production and must align with specific time constraints. For any code change—whether a new feature or a bug fix—the CI/CD process should ensure a high-quality build is pushed to production within a defined timeframe, ideally one to two hours.
How to achieve “ship daily”?
Some might ask, “Sure, shipping frequently would be ideal. But how can we manage that? We don’t like the 6-month release cycle either. However, one round of regression testing takes about three weeks, at least.”
Relying on a “super-productive” framework, “agile” management processes/tools, or “genius” software engineers is NOT the solution. The answer: greatly improve your regression testing, End-to-End (UI) regression testing (good unit/integration testing helps, but won’t achieve daily production releases).
Why are so few software companies unable to achieve what Facebook and I accomplished over a decade ago, despite CIOs passionately advocating "Release early; release often" on stage? The root cause lies in the company's lack of expertise in end-to-end (UI) test automation and the executives' unwillingness or inability to make the necessary decisions to drive progress forward.
LinkedIn accomplished this, and Wired magazine wrote an article, titled “The Software Revolution Behind LinkedIn’s Gushing Profits”.
At least two senior project managers have independently described my approach to software development as a "Software Revolution" after seeing it in action: ~70% of the SDLC effort is focused on end-to-end (UI) test automation, leading to a massive productivity boost and daily production releases.
Because it is a revolution, it is hardly seen in software companies.
LinkedIn top executives lured one real E2E Test Automation engineer from Google.
Completely changes software development based on Continuous Testing
99+% professional executives don’t make courageous decisions.
You might try persuading your manager, director, CIO, or CEO to take E2E test automation seriously, but I wouldn’t recommend it—I've done so many times without much success. Even when some CIOs reached out to me for advice, only a small percentage actually took meaningful action. However, in today's age of solopreneurship, you can take matters into your own hands and make it happen yourself.
The majority of this newsletter's audience are motivated software testing engineers and ambitious software engineers who are either pursuing or already diving into solopreneurship. My advice: adopt Mark Zuckerberg's product strategy, it is certainly applicable to small software start-ups, if not more so.
In this article, I break down how Mark Zuckerberg's product strategy of "shipping daily" is supported by E2E (UI) test automation for regression testing—a skill that most software companies lack. In Part B, I'll explore the specific technologies and mindset that enabled Facebook to accomplish this, based on publicly available information.
Relate reading
My eBooks:
- Practical Web Test Automation with Selenium WebDriver
- Practical Continuous Testing: make Agile/DevOps realWhat is my Agile Way? Production Deployment within the first week, then every working day
Facebook and I Shared a Similar Approach to E2E Test Automation and Continuous Testing
Correct a Common Misconception: “Using the Coding Language for End-to-End Test Automation”