I recently made a purchase in our corporate rewards store powered by Workhuman. Within a minute of making the purchase, I realized I made a mistake. I should have used my points for something else.
I searched for a cancel order button for the next 3 minutes and found a help center post recommending I call them. So, 4 minutes in, I did that.
Credit to them, they picked up within minutes. But, I was told they had no way to cancel it at the moment. It was Saturday and they’d have to call the supplier on Monday morning.
I checked in on Monday afternoon. Unfortunately, however, the supplier had shipped it before I reminded them. So, the package was on my way. I could, however, call Fedex if I wanted it canceled.
When I called Fedex, I learnt that only the sender could cancel it. So, I called Workhuman back and asked them to request the supplier to cancel it.
They told me via email that this didn’t work. I have no idea why. So, I’d now have to wait for the Fedex delivery and refuse the package.
You guessed it. The Fedex delivery person just left the package at the door. So, I couldn’t do that. Can I get some return labels?
After a couple of email requests and calls, I finally received a quick questionnaire that I needed to fill out – including sending photos of the unopened box. Then, I finally received said return labels and, eventually, my refund.
The entire process took about 4 weeks.
To think of all of this could have been avoided by a cancel button.
If that breaks the order relay system, we could imagine a solution that delays sending orders by 15 minutes to external suppliers and thus enable users to cancel within 15 minutes (I assume that’s a reasonable window to catch a mistake).
Another great reminder that it’s got to be easy to remove a charge.
We use a catchy Hindi refrain regularly at home – “Use your akal, not your shakal.”
It loosely translates to – “Use your brain (akal), not your face (shakal).”
We use it nearly every time our kids throw a tantrum as we demonstrate how they could have gotten what they wanted without the drama. It brings levity and a reminder that there’s always a way out with common sense.
But, as is often the case, I find myself reflecting on my own behavior every time I use this phrase. There is always a recent instance that comes to mind where I did the same – whined or complained instead of just using my brains/common sense.
Costco usually stations an attendant or two at the entrance and exit of their stores.
The person at the entrance checks for a Costco membership card. As you need a membership card to checkout, I’m not sure what this accomplishes.
The person at the exit, however, has a more straightforward role. She/he skims the receipt and then uses a black marker to draw a line across the receipt. That line indicates you’re done.
I typically chuckle at the seeming futility of this little exercise. As there’s always a queue to get out, they have to skim the list so quickly that there is no way for them to really know if you have an extra item. Besides, if you were enterprising enough, you could just grab a black marker, draw the line yourself, wave it at the door, and walk out.
But I’m sure they ran a test at some point and realized that theft goes down when they station folks at the end of the experience. Ergo – this practice acts as the deterrent.
While I’d love to see the cost/benefit numbers that led to this decision, it got me thinking about the importance of such deterrents. As an example, strong passwords and two-factor authentication are a good parallel to this.
A determined and enterprising hacker will likely find a way through your defenses. But strong passwords and two-factor authentication are powerful deterrents against everyone else.
Deterrents matter. It helps to be thoughtful about them.
Writer Elizabeth Gilbert once shared an exchange she had with someone who was trying to help her with her struggles as a writer.
This wise older woman asked – “What are you willing to give up, in order to have the life you keep saying you want?”
She said – “You’re right – I need to start saying no to things I don’t want to do.”
She corrected her – “No, it’s much harder than that. You need to learn to start saying no to things you DO want to do, with the recognition that you have only one life, and you don’t have time and energy for everything.”
Such a powerful illustration of what focus really is – saying no to things we’d like to do to say yes to things we need to prioritize.
Left unchecked, our expectations have a way of ratcheting up. They keep doing so irrespective of the reality of the situation.
The natural result is one or both of disappointment and frustration.
So, it helps to pay attention when we experience these emotions and to use them to diagnose if they were caused by the ratcheting up of our expectations.
If they were, it may simply be time to reset and recalibrate to re-enable constructiveness and progress.
A note for new subscribers: This post is part of a series on my notes on technology product management (this is what I do for a living). You might notice that these posts often link to older posts in the series on LinkedIn even though they are all available on this blog. That is intended for folks who only want to follow future product management related posts. Finally, for all those of you who don’t build tech products for a living, I believe many of these notes have broader applicability. And, I hope you find that to be the case as well…
A quick overview of what we’ve covered on “Notes on Product Management” so far –
In many product teams, there are very noticeable repeating periods of stress.
That period of stress is driven by “planning.”
Most organizations beyond a certain scale have planning cycles that are either quarterly or half-yearly. Planning exists to ensure everyone is making the best use of the most valuable time in a software company – IC/individual contributor engineering time. The output of the planning process is typically some metric target for the team that is a by-product of the team shipping good products. In many organizations, this is done in the form of “OKRs” or “Objective” and “Key Results.”
The stress is driven by everyone waking up from execution mode to realize that we need specs and designs to make accurate estimates of the scope of work. While some organizations/teams do a great job fostering a culture of thinking ahead, most others find themselves in a stressful quarterly scramble.
The good news is that there is an alternative. Regardless of the culture of your team, a simple habit that can save you from this – and they are Exploration OKRs.
What are exploration OKRs? How are they different from “normal” OKRs?
When product teams set their OKRs, their OKRs are created based on how they’ll use IC/individual contributor engineering time. As an example, an OKR might be –
Objective: Create a frictionless checkout experience for our logged-in customers (pillar 3 of our 2022 strategy)
Key Results for Q4
Improve checkout completion rate by 10% (from 50% to 55%) by shipping Ux improvements xx and yy
Reduce checkout abandonment rate by 10% (from 50% to 45%) by launching checkout reminder emails
These are examples of “Execution OKRs.” Each Execution OKR involves us shipping one or many products and it comes with the expectation that we’ll stay close to progress via stand-ups with our engineering team, go-to-market team, etc.
Exploration OKRs – on the other hand – are OKRs that do not involve IC engineering time (exceptions involve partnering with experienced tech leads). Exploration OKRs are created in collaboration with the rest of the cross-functional team to validate problem statements and hypotheses.
There are 4 kinds of Exploration OKRs:
(1) User/customer/partner research: This could be a mix of qualitative research (interviews) or quantitative research (surveys) that help us better under our user/customer/partner needs. This is typically done in partnership with user research, product marketing, business development/partnerships, or sales teams
(2) Data analysis: This typically involves correlational or causal analyses of existing user date and/or available 3rd party/macro data. This is typically done in partnership with our data science or strategy/operations teams.
(3) Strategy: This involves writing up a strategy document. This is typically in partnership with the entire team. If done well, this typically only needs to happen once every ~4 quarters.
(4) Design: This involves getting to high fidelity mocks/prototypes. This is done in partnership with our design teams
Done well, exploration OKRs create a pipeline pre-planning that look something like a research pipeline for a pharmaceutical company. We start by building conviction around a problem/opportunity space, begin validating it by talking to users/customers or studying their behavior via data. Then, we spend time sharing our path forward in words – by creating or updating our strategy doc – and then in visuals.
This isn’t necessarily an illustration of the amount of time required. If we’re talking about a small feature, this process can be done in a matter of a couple of weeks. But it can take significantly longer for larger features.
All investments here are governed by the Law of Shitty Planning – Any sacrifice in rigor before the planning process will result in 10x the heartburn after the planning process.
This makes sense. Why is it hard to do?
It is hard to do because there is the classic urgency vs. importance trade-off. Execution is always urgent and takes priority in our calendars. But, exploration OKRs help us get ahead and smoothen the planning stress. And the good news is that there are 3 things we can do to make this work:
(1) Align on and share exploration OKRs as part of our planning document. This means explicitly aligning with our cross-functional partners on our commitments as team across the buckets – Research, Analysis, Strategy, and Design.
(2) Schedule time for exploration OKRs just as we do for execution OKRs. For every engineering stand-up on your calendar, we should have a stand-up with our design partners for that design vision or with our team for iterating on our strategy doc.
(3) If we’re new, resist the temptation to “just ship something.” It is tempting to fall prey to the temptation to just put a spec hastily together to keep the IC engineers busy.
The unsaid problem with executing on poorly scoped ideas is that they will inevitably either not ship or will need to be rolled back. Every idea we decide to build brings tremendous cost with it – for us, the team, and the organization. Morale wins in the short-term will result in morale-loss in the long term.
The better approach is to buy time.
Three superior alternatives that we have at hand are:
(a) Invest in product craftsmanship: Read user support tickets, audit the existing experience, prioritize and fix all those “fast follows” that never got built. These often deliver more long-term business impact than we realize.
(b) Invest in data and technical foundations: Work through the tech leads’ wish list and set the team up for faster iterations moving forward.
(c) Help other teams who are hustling to meet a deadline. Pay it forward.
These will always be better decisions for the organization instead of engaging in low conviction busywork.
Again, it is challenging. Very challenging. When we’re new, it is the opposite of “hitting the ground running.” And it always hurts in the short run.
But, taking the time to build conviction that we’re working on the right thing is what separates the amateurs from the pros. It is the difference between velocity and speed.
And, optimizations for speed are typically a result of prioritizing business and political considerations over user needs. When we optimize for velocity over speed, we recognize there are times when we need to slow down all activity to ensure we’re getting the direction right and investing in the highest leverage problems and solutions.
That, then, gets to the power of exploration OKRs. By helping us build conviction in the direction we’re headed, they help us create execution OKRs that create meaningful impact for our users that stand the test of time.
And, most importantly, they help us stay on the right side of the “Law of Shitty Planning” – Any sacrifice in rigor before the planning process will result in 10x the heartburn after the planning process.
A story I’ve shared a few times over the years is the one about the trouble tree. It goes like this.
David’s plumber had just had a rough day. He had a flat tyre on his way to work, his drill quit and his truck refused to start. David drove the distraught man home.
Just before they entered home, the plumber paused briefly at a tree, touching its tips. He then opened the door and underwent an amazing transformation. He hugged his kids, kissed his wife and was all smiles!
Afterwards, when David was walking out, he asked his plumber about his behavior. The plumber he said – ‘Every day, I leave all my work troubles at the tree before walking in. The funny thing is when I come in the morning to pick them up, there aren’t as many as I left.’
I shared this story a year ago as I was reflecting on a period where this routine completely broke down.
I realized that my version of the routine was my drive home from work pre-pandemic. When that routine fell apart, so did any sense of separation.
I’ve been working to re-create this separation over the past weeks. And I’ve come to realize that a combination of writing a quick reflection for the day before shutting down my laptop, keeping my gadgets away, and taking a shower works well. All three are ideal – but any two do a good job creating separation.
A Learning a Day 