The Overlap is a newsletter somewhere between product development and organizational development. It comes out every other Wednesday.
If you want a more consistent and authentic source from which to draw a sense of self-worth and personal power, you will eventually need to reject external factors such as comparison and achievement. You must look inside and embrace learning.
— Arno Ilgner, The Rock Warrior’s Way
In Share Unfinished Work, I wrote about how product managers should create value rather than prove value:
Several times, I’d work four to sixteen hours on an essay, presentation, or diagram. I’d rarely ask for feedback early on. I’d ask for feedback only when I thought my work was 95% done. Almost every time I do this, I learned that I was working on the wrong problem. If I worked towards a different direction, my deliverable would be 1000% more valuable.
Here’s what I learned: When I do this, I want the deliverable to reflect how impressive I am. How you should see me as valuable. How you should take me seriously. As a result, the deliverable isn’t valuable to my client, team, or organization.
My longing to be seen as valuable makes my work less valuable. Therapy-level stuff, I know.
So, I remind myself to share unfinished work.
Product managers can overly focus on justifying the existence of our role. We get in our head when we hear people ask “what is it that you do all day?” Our effort to prove our value reduces our value.
Matt Lemay puts this well in Product Management in Practice:
…the urge to defensively demonstrate value can lead to some epic acts of unintentional self-sabotage. Insecure product managers might start making big, awkward public displays of their contributions (the product martyr). They might start speaking in gibberish to prove that product management is a real thing that is really complicated and important (the jargon jockey). They might even start devaluing their own work for the sake of showing that they could be doing higher-status work if they wanted to (the nostalgic engineer).
I mean, we’ve all made fun of the product martyr, the jargon jacket, and the nostalgic engineer. But when do we actually notice that we ourselves do the very thing we make fun of?
Teams shouldn’t prove their value, too
Matt reached out to me recently. He let me know that he’s been coaching his clients on not proving value but creating it. And that teams often try to prove their value too.
I thought this was fascinating. I hadn’t thought about how “Don’t prove value, create value” applies to teams, too.
Here’s a made-up example: say Superhuman hires a growth team. This team is in charge of increasing retention. If you’ve ever used Superhuman, you know that to get access to it, you have to schedule a demo with a sales development rep. This growth team suggests to Rahul, their CEO, that Superhuman can retain more users if they let folks try out the product without having to schedule a meeting with a sales rep. Rahul agrees that this is a worthwhile experiment. So the growth team frames an experiment:
“By letting users try Superhuman for free without interacting with a sales rep for one month, we’ll see 5% more retention in six months.”
This upsets the sales team. Superhuman is known for new users having to interact with a sales rep to get access to the product. This is what makes their onboarding experience unique. The growth team’s strategy goes against the sales team’s social-driven acquisition strategy.
The growth team doesn’t care about the sales team’s gripes. They want to prove their hypothesis right. They need a small win under their belt to gain trust in the org. After all, if they’re not increasing retention, what is their value as a team?
At this moment, the growth team must observe that their trying to be right gets in the way of true experimentation. They need to be okay with risking being wrong. Letting users use the product for free works for some SaaS products, but it may not work for Superhuman. Growth should collaborate with sales to understand what the sales team has learned about their previous strategy, and where they see opportunities to increase retention.
Experiments create value, rather than prove it
Experiments are not a place for teams to prove that they’re right. They are a place to gain new understanding as quickly as possible. To gain new understanding quickly, we minimize the risk and shorten the feedback loop. We see our hypotheses as ideas to disprove, rather than prove.
To help your organization use experiments as a way to create value, I recommend using this template for every experiment:
By [doing this change]
We will [achieve this outcome]
As measured by [these metrics]
We’ll stop this experiment if we see [this happen]
We’ll continue this experiment if we see [this happen]
We’ll decide to stop or continue this experiment on [this date]
The “we’ll stop this experiment if we see [this happen]” part normalizes the fact that experiments fail. It permits us to cut our losses on failed experiments. Permitting teams to cut their losses is a forcing function to learn from failure, something many orgs struggle with.
You’ve already proved yourself
I’ll never forget the words Kathryn Maloney told my old team once in a meeting:
No one here needs to prove anything. By being here, you’ve already proved yourself.
I think this applies to teams, too. If your team is new and struggling to gain trust, don’t try to prove your value. You’ve already proved it by being hired there.
Instead, create it. You’ll create it by being okay with being wrong.
What I’m Reading
Decentralized Agency’s Why Paper. Very cool. Pay attention to this space.
The Integrator Burden. “What is the wolf behind your tree? Why are you drawn to put yourself in the messy middle of the org?”
See you in two weeks,