Measure twice, cut once
What you remove is as important as what you add
When Blogger turned ten years old in 2009, only seven websites in the world received more traffic. Its combination of free hosting, rock-solid uptime, and simple interface made it a popular choice for bloggers around the world.
Yet of the tens of millions of blogs published with Blogger at that point, a tiny handful relied on Blogger’s very first feature: FTP publishing. Indeed, when I’d launched my own blog in 2001, it was on Blogger, publishing to my own domain via FTP.
By that 10th birthday, fewer than .5% of Blogger blogs were published via FTP. Yet as the product manager, at each team meeting I’d hear from our engineers about the growing burden FTP represented. If we stopped supporting FTP, we’d free up valuable engineers and iterate much more quickly. We knew we’d be causing considerable pain to some of Blogger’s most loyal users, something we didn’t take lightly. Though FTP was the right feature for Blogger in 1999, it had become a niche feature whose time had come.
In the end, we shut down FTP. It wasn’t an easy decision, as you’ll see. Predictably, we angered a number of people. At the team meeting following the announcement, we even watched the Hitler video an irked user made lampooning our incompetence.
In my current role at Google Ventures, I’m fortunate to talk with a number of entrepreneurs in our portfolio about product strategy. Inevitably, PMs want to know how to prioritize which new features to build. They ask how to build a product roadmap, and how to respond to customer demands for additional options. However, when I talk with founders and product leads about their own products, I make sure we spend as much time talking about what should be removed from the product as what should be added.
It’s easy to say yes when a customer (or prospect) asks for a new feature: after all, if it’s just a day or two of engineering time, why not? But you quickly lose sight of the product you’re building: your product no longer has a coherent vision, and each new feature brings with it uncertain support costs that will last as long as the feature remains. Much harder — but much more important — is the discipline to question whether the feature is a required piece of what you’re building. New or old, easy or hard — if the feature does not support the overall product goals, it has to go. Customers and team-members alike respond to that discipline — particularly if it results in better support, more predictable development, and a clearer understanding of what it is you’re trying to build.
Shutting down FTP was the most important product decision I made in my time as Blogger’s PM.
Back to FTP. With Blogger’s engineering leads, we relied on two things to reach the conclusion that FTP had to go:
- Clear metrics. For more than a year, we’d had a core set of metrics that we watched closely. Everyone on the team — product, engineering, design, support — agreed that those numbers reflected how we were doing. Those metrics helped us realistically evaluate the engineering cost of continued FTP support, and also measured the drag on product development that FTP represented. Once we knew what the cost was relative to the total number of users who relied on FTP, it became much a clearer decision within the team.
- Defined objectives. We had big goals in 2010 for Blogger: a completely revamped design editor, a real-time stats service, and instant search integration, among others. These goals were part of a broader ambition for Blogger: redefining what it meant to publish on the web. (The irony of writing this post on Medium is not lost on me!) The entire team was committed to shipping the most significant enhancements to Blogger in years, yet two things were clear: continued investment in FTP would significantly detract from our ability to move the product forward, and none of those new features would even work on the legacy FTP blogs. The longer we supported FTP users, the fewer new features we’d ship and the longer we’d have a forked user-base.
With the decision made, it was time to let our users know and shut FTP down for good. Here’s what we did and what we learned:
- Communicate, communicate, communicate. We spent years earning our users’ trust. Decisions as drastic as this required that we explain exactly what was happening (and why), and what their options were. We set up a dedicated blog and answered as many questions as we could in the comments to each post.
Lesson: Tell users what you’re doing and why: they may not agree with the decision but they’ll almost always respect it if they understand it.
- Data liberation. We were fortunate that Google’s Data Liberation Front had long ago liberated Blogger’s data, and had also built open-sourced tools to convert Blogger exports into import files for competing products. We made sure to point users to these services to simplify their transition to other platforms, and tweaked a few things as needed on the Blogger back-end to support some of the trickier exports (some blogs were 10+ years old, and had exceptionally large archives).
Lesson: Point users to alternatives if they exist, even when they’re competitive.
- Time. The original deadline for shutting down FTP was a change in Google architecture that would have required we entirely re-write the FTP service for it to continue to work. We set the shutdown to coincide with that service’s shutdown; after hearing feedback from users who needed more time, we were able to negotiate an extension of a few months. In all, nearly five months transpired between the original announcement and FTP’s shutdown.
Lesson: Announce the shutdown as far in advance as you can.
- Transition. Part of earning back our users’ respect was showing them that we did want them to continue using Blogger. Rather than tell them to simply figure out how to transition from FTP to Blogger hosting, we invested significant engineering time in building a migration tool that would eliminate nearly all of the hassle involved in making the switch. We recorded a screencast that walked users through the process, demonstrating how straightforward the migration was.
Lesson: Anticipate the pain the shutdown will cause, mitigate it where feasible.
- Support. We knew we’d find edge cases that the migration tool couldn’t handle; we set up a dedicated issue tracker to give our support, engineering and product teams an ability to easily triage problems as they came in.
Lesson: give users a place to route their issues, scalably (and publicly, if possible) resolve them.
As a PM, the commitment to shutting down a costly engineering drain earned trust and respect from the engineering team. It freed the team up to think bigger about what they wanted to do, and gave them the ability to deliver on those ambitions.
It’s worth noting that the Blogger team launched every one of the features mentioned above, and several more. The velocity of the team’s launches picked up quite a bit, and the clarity of the team’s mission helped attract users who’d been unsure of where the product was headed.