3 December 2022

When shutting down a product is the right thing to do

In Google has a company strategy, not a product strategy Jackie Bavaro 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.

2 December 2022

Use “survival metrics” to determine the right project status

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 project, pivot in 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.

2 December 2022

So where should we post now?

I’m sure I am not the only one who is currently re-evaluating where I spend my time online. Two tangentially related articles gave me lots of food for thought on this topic over the past couple of weeks. First, Dave Rupert makes this point in It takes one person to knock down a silo:

Wherever you end up I want to offer an idea; you are the value. Your ideas, your insights, your compassion, your ability to help someone in need, your dumb puns and dank memes; that’s what’s valuable. This situation has me thinking hard about where I’m distributing my contributions, where I’m adding value (modest as it may be), and who is benefitting.

Second, Jamie Zawinski asks that we Do Not Use Services That Hate The Internet (please read the whole thing, it’s great):

If posts in a social media app do not have URLs that can be linked to and viewed in an unauthenticated browser, or if there is no way to make a new post from a browser, then that program is not a part of the World Wide Web in any meaningful way.

I like how these posts urge us to consider how, before Facebook and modern social media, the “social web” was pretty much just labors of hypertext love, loosely held together by the online equivalent of duct tape—RSS, trackback links, blogrolls, IRC, etc. I’m not saying we should go back to those old tools specifically (although ooh.directory—”A collection of 951 blogs about every topic”—is pretty sweet). But maybe it’s worth going back to why we invented those awkward solutions in the first place. We saw an opportunity to connect with like-minded people online, to form communities around niche interests, and to make our worlds bigger. Those are worthy outcomes, even if the solutions we had at the time might not be ideal any more.

So where should we post now? I’m going back-and-forth on that a lot. Depending on the day/time/mood, I either want to go all-in on this blog again, or revive Tumblr, or give Mastadon a solid try, or just double down on the newsletter… In short: I have no idea at the moment, but I know I want to keep writing, so I’m trying a bunch of things and hoping at some point I find something that works and that doesn’t make me feel gross. Wherever I end up, I hope that it’s a place like the one Dave describes in the post above:

I hope you’re somewhere that values your value. Somewhere where the stars, hearts, and thumbs up feel like authentic relationships. Give your contributions to someone or some place that appreciates them. In Biblical agrarian parlance, “Cast not your pearls before swine.”

14 September 2022

A framework to identify issues to unblock growth

Here’s a good analogy from Josephine Conneely to help figure out why growth might be stalling:

Imagine each of the 3 criteria pillars, Product, GTM and Org, as legs of a stool. Ideally each leg is of even height. This allows it to sturdily hold whatever is needed (in this case it’s increasing user volumes). Each leg can continue to grow (perhaps this is some sort of stool tree), and as long as the legs grow in tandem the success metrics of choice are safe. However, there may at times be an imbalance. Imagine an organisation with a great sales and marketing team who have created such demand that the product is struggling with performance issues as it scales to meet increased usage volumes. This leads to a lopsided stool, which while functioning, is not operating in manner which enables the org to capitalise on growth potential. If the product issues are not rectified, this could result in churn, reputational damage and a negative growth trajectory. Imbalance leads to lost opportunities.

Read the whole article for an illustration of the concept, and also how to use the framework in practice.

11 September 2022

Return To Office: the wrong solution for remote work challenges

In Official myths Mandy Brown talks about how we are trying to solve the legitimate challenges of remote work by blindly (and incorrectly) assuming that the solution is going back to the office:

In many a remote-critical piece I’ve read, there’s a kind of mythical office that remote culture is being compared to, a place where everyone is welcomed, where collaboration and support is easy-going and automatic, where everyone is always whiteboarding or talking in the hallways. It’s kind of astonishing to see how much this presumed office utopia has become implicit, given we have literal decades of satire about offices as locales of poorly lit, soul-sucking, isolated work, where you are more likely to be abused by your boss than sponsored by them.

She goes on to explain the importance of supporting junior staff, and how office environments are often not ideal environments for that.

21 August 2022

The nature of product

You can scale with process, or you can scale with leaders. The only way that leads to good outcomes is scaling with leaders.

— Marty Cagan, The nature of product on Lenny’s Podcast

19 August 2022

Create awareness of reality through bottom-up strategy

Tim Casasola’s post Create awareness of reality through bottom-up strategy points to an issue that we often see in teams—the work that they are doing is disconnected from the company’s core strategy:

There is often a difference between what an organization says its strategy is and what customer/project teams do on a day-to-day. When this dissonance is present, customer/project teams share with the org that their reality isn’t aligned with the organization’s vision. “It’s great that we want to pursue this new customer segment, but most of our engineers are focused on improving the experience of our current customer segment… and we’re far from where we want to be there.”

And yet, the org still says they have a “strategy.” The org turns a blind eye when customer/project teams describe their reality and relies on its existing narrative when feeling challenged.

The organization needs to be aware of when this dissonance takes place. So that they can learn from it, and come up with an actionable strategy.

Tim points to John Cutler’s “Bet Up” activity as a useful exercise to make this disconnect clear:

This seems like a really useful exercise for teams to undertake. It might also be really interesting to ask the executive team to fill out row 4 of the above, and see how their answers differ from what the teams come up with. Exposing a big strategy mismatch in such a clear way could be a really powerful tool to move the organization in a direction where a team’s day-to-day work is reflected in the overall product strategy.

18 August 2022

Leadership and product strategy lessons from Reid Hoffman

Ben Casnocha has a long, excellent piece entitled 10,000 Hours with Reid Hoffman: What I Learned, in which he shares a bunch of lessons he learned from then LinkedIn founder:

A lot of strategists (and CEOs) think that their job is to conceive a strategy and then hand it off to the underlings to execute. They might concede that delegation matters, but usually as a matter of execution more than strategy.

Reid disagrees. He once told me, “Whoever is actually immersed in the actual execution of a strategy should always think of ways to tweak the strategy for the better.” It’s a litmus test for talent: How do you know if you have A-players on your project team? You know it if they don’t just accept the strategy you hand them. They should suggest modifications to the plan based on their closeness to the details. And as they execute, they should continue to tweak the strategy, and you (the owner) should not feel a need to micromanage or second guess—if you do, you’ve got the wrong person.

The whole piece is full of wonderful gems like that. Highly recommended read.

More