When shutting down a product is the right thing to do
When shutting down a product is the right thing to do
Also a new book on the product design process.
In Google has a company strategy, not a product strategy
argues that instead of product strategies, Google has… this:Google’s company strategy is “Hire all the smart people.” Hire all the smart people and let them build. Hire all the smart people so they can’t work at a competitor. Hire all the smart people even if we don’t have something important for them to work on.
She goes on to argue that this is the main reason so many of Google’s products get shut down:
I think the lack of a product strategy is behind many of Google’s short-lived products. Projects like Google Wave, Google Inbox, or Stadia get the go-ahead without a deep, structured, well-reviewed plan for how they’re going to succeed and why they’re important. Some smart, ambitious person at the company spear-heads the project and pushes it through to launch. When the product isn’t a runaway success, Google cuts its losses and moves on to the next thing.
If Google didn’t start with a conviction that they needed the product, it makes sense that they wouldn’t have the stamina to keep iterating and investing. Most other companies don’t have the money to build and launch products with such little conviction and oversight. Other companies need their products to succeed, so they try harder & smarter to make the products successful.
It’s a good post (that she accurately calls “spicy”!). I found it particularly interesting because how Jackie describes Google reminds me of one of the key principles we had at Wildbit:
Businesses are product agnostic. Products are an output of a team’s skills, strengths, beliefs, and values. Companies that define themselves by what they make automatically impose limits around what they can do.
We wanted to keep working together as a team, which meant we had to create products that people love and are willing to pay for, and that is what drove us. We were always worried about being defined only by our biggest product, so we kept experimenting with different things. Sometimes it worked—DMARC Digests is still going strong. And sometimes it didn’t—the team shut down Conveyor after the final pivot just didn’t work as well as we had hoped. But in the midst of it all, our #1 principle remained intact:
Businesses exist to serve people. As a tool, businesses exist to support human constituents: the Founders, the Team, the Customers, and the Community.
When we shut down Conveyor that team didn’t leave—they moved back into the larger team to work on our other products. So as I reflect on why the decision was made to shut down (or find a new home for) some of our products over the years, I’d like to believe that we didn’t do it because we didn’t have a product strategy—we understood our audience and the problems we were solving for them very well. We did it because when it comes down to it, all products are experiments until they’re not. And when we couldn’t get experiments to a place where they supported our founders, the team, the customers, and the community well—when the situation essentially violated our company principles—we had to face that reality and act on it.
I think that’s ok, by the way. When a team has the safety to know that they won’t lose their jobs if the product they’re working on isn’t ultimately succesful, they are able to more clearly see the world for how it is. They can acknowledge when a product isn’t on a path to success, and when it’s time to move on.
I miss Google Reader and Google Inbox too. But after working in a “product-agnostic” company for 6 years I have more empathy for teams who decide to shut down products that seem to have a big following. The issue is not necessarily that those teams don’t have clear product strategies. It’s that sometimes the gap between product strategy and product reality becomes too large, and keeping the product going would end up doing a disservice to the business, the team, and customers. Strong product leadership is seeing reality, acknowledging it, and keeping the team safe during the process of shifting to a new experiment or existing product.
What I’m reading
My friend Francisco Inchauste co-wrote a book called The Product Design Process Handbook, and it looks fantastic:
We’ll give you an overview of the best practice product design processes and some guidance on how to try them out in your work. Even if you work for a company or client that doesn’t give you enough time you can still use these processes and adjust the duration to the scope you have available. We’ll run through the options, dispel the myth that there is only one right way to run a design process, and give you a bit more depth in your understanding of them.
I got myself a copy and can’t wait to dig in. I’ll follow up with a full review once I’ve read it!
🚨 Elezea readers get 20% off with the coupon code elezea20.
If you look at the customer acquisition tactics we’ve talked about, it’s a wave that we’ve been building for a long time. But a lot of our tactics are based on demand capture rather than demand generation. Over time you start exhausting that demand, you rank on every good keyword, and you’re getting all of that SEO traffic. That’s all happening while the base of your revenue is much higher and you need more and more fuel to grow it.
We’re shifting our marketing strategy towards a demand generation point of view where we invest more around brand marketing, PR, and channels that enable us to reach a wider audience that might be problem unaware and solution unaware, but lives in our addressable market.
→ This is a good companion piece on product-led growth: The New User Journey: Follow Your Users to Understand how to Excel at Go-to-Market.
→ This one too: On becoming a product-led SaaS business.
→ And of course, read and bookmark
’s excellent Product-led growth guide.→ Oh wait, one more! Speaking of
… has an interview with Kyle about product-led growth for his newsletter. Lots of addition resources to explore in that one as well.I like Adam Thomas’s idea of identifying “survival metrics” at the start of a project. It’s a way to help teams stay grounded throughout the project and ask themselves whether they should stop the work, pivot into a different direction, or continue to invest in completing the project. From What Are Survival Metrics & How Do They Work?:
Survival metrics help a product team determine if an initiative is worth investing in more, pivoting or stopping completely. They are a forcing function to prevent product teams from suffering due to the sunk cost fallacy. Survival metrics put resource allocation and company incentives, both implied (think politics) and direct (think data), in front of the team before a project begins and again at regular intervals, giving permission to act quickly.
Adam goes on to discuss three questions that help teams identify those survival metrics.
Some stray links
♠️ I love this and I want it. “Wyldcards are small plastic cards with e-ink screens (like a Kindle). When placed onto a plinth, the image on the card can be changed by a hidden computer.” /via Clive Thompson’s linkfest.
🧒 Grace is a “free, powerful, privacy-first parental control app for iPhone.”
🟣 Why Faulty Streetlights Are Turning Cities Purple — and Why It’s Worrisome. “The purple streetlights are a result of the phosphor coating delaminating from the LEDs.”
🧓 This week’s “for my fellow olds” link: Growing Old Online. “Millennials, the first generation to be online as kids, are starting to feel like we’ve aged out. Is there a way to age gracefully on the internet?”
📈 Last week’s most clicked link: An Engineering Manager's Bill of Rights (and Responsibilities).
Thank you so much for the shoutout!
👍👍