Month: January 2022

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 – 

• Overall: The IC PM Role, The 4 key skills, Remote + Pandemic PM, 5 Decision Making frameworks/heuristics, Problem finding/solving with executives, Managing psychology
• Skill #1 – Problem finding: Most important skill, Problem statement and hypothesis, Building Strategy, Validating problem statements and hypotheses
• Skill #2 – Selling: Sales and Marketing, Writing for executive audiences, Product executive relationships, Learning to sell
• Skill #3 – Problem Solving: Roadmap, Product specs, Solving for Usability, Solving for Feasibility, PM<>Eng collaboration, Ramps and launch checklist
• Skill #4 – Building effective teams: Knowing thyself, Your manager, Product team culture, 5 habits – high velocity product teams, Effective 1:1s,
• Managing your career: Getting in – I, Getting in – II

---

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 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 – 

• Overall: The IC PM Role, The 4 key skills, Remote + Pandemic PM, 5 Decision Making frameworks/heuristics, Problem finding/solving with executives, 
• Skill #1 – Problem finding: Most important skill, Problem statement and hypothesis, Building Strategy, Validating problem statements and hypotheses
• Skill #2 – Selling: Sales and Marketing, Writing for executive audiences, Product executive relationships, Learning to sell
• Skill #3 – Problem Solving: Roadmap, Product specs, Solving for Usability, Solving for Feasibility, PM<>Eng collaboration, Ramps and launch checklist
• Skill #4 – Building effective teams: Knowing thyself, Your manager, Product team culture, 5 habits – high velocity product teams, Effective 1:1s,
• Managing your career: Getting in – I, Getting in – II

---

A product manager’s role is to bring the cross-functional team together to build products that are valuable, usable, and feasible. 

A big part of the job – unsurprisingly – is about building product that is valuable, usable, and feasible. But, that tends to be the easy part. The challenge typically lies in dealing with the feedback from all the people involved in the process.

As we attempt to build the right products, we get a ton of feedback. This feedback is split between feedback on the product and feedback on our process. Therein lies our challenge –

(1) We need to synthesize the feedback on the product to facilitate building a better product

(2) We need to synthesize the feedback on our process, decide what applies, discard what doesn’t, and manage not to take it personally.

The common theme is synthesis – we’ll cover that in a separate post. Today’s post will focus on how to do (2).

In the absence of our ability to process all the feedback and synthesize it effectively, our emotional state feels like a yo-yo or, for the more geeky folks, a nicely scripted sine wave. Yesterday might have marked a high because our CPO mentioned our product in the All Hands. Today marked a low because our Eng partner told us our spec sucked.

Combined with our desire to hold it together, we then end up feeling like Louisa in Encanto (The “Surface pressure” song is genius).

I don’t ask how hard the work is

Got a rough indestructible surface

Diamonds and platinum, I find ’em, I flatten ’em

I take what I’m handed, I break what’s demanding

But

Under the surface

I feel berserk as a tightrope walker in a three-ring circus

Under the surface

Was Hercules ever like “Yo, I don’t wanna fight Cerberus”?

Under the surface

I’m pretty sure I’m worthless if I can’t be of service

This yo-yo/sine wave emotional state sucks. We lose all sense of self in the process and let ourselves being driven by our wounds and insecurities instead of optimism, conviction, and wholeness. We need to avoid it at all costs.

Here are 3 habits that help us with that.

Habit 1: Screwing up and the feedback that follows that is inevitable. So, once or twice a week (or some regular cadence), make sure you get the therapy you need.

By default, humans are better at complaining when things go wrong vs. appreciating when things go well. It is why gratitude is powerful. So, by default, you will likely get more feedback when you screw up vs. when you do things well. To compound this, negative feedback sticks in our memory longer and more effectively than positive feedback.

As screwing up is inevitable, you need a regular outlet to process your feedback. The first phase of this process is best done with a human (or humans). This may some combination of an actual therapist, your partner at home, a close friend, a trusted cross-functional partner, or your manager. A common miss here is to neglect your manager. Therapy is a key part of a good manager’s skill set. 

This friendly therapist will help you get through stage I – going from raw feedback to processed feedback by:

• Removing emotions and any harshness: The act of sharing and discussing will help you separate the emotions from the facts by removing any feeling of harshness of the feedback. Typically, the harshness of the feedback reflects the harshness in the giver’s self-talk. It isn’t about you.
• Getting to the 3 variants of content: Once you get down to the content, you’ll see three variants of content. The first is a reflection of the person giving it – e.g., their continuous discomfort with the stage of the product. There is typically little you can do here. The second is a factual improvement you could make to the process going forward. And, the third will be something about your style that could be easy or hard to change – depending on how connected it is to your core strengths. 

Getting here will help us get to stage II – the “gift” stage. Feedback isn’t always a gift we look forward to. But, once we get to this stage, the end result is a gift we can decide to keep or discard. This decision is best made solo – either on a walk, by writing, or when we’re occupied by something else.

In sum, make sure you have consistent access to the therapy you need when you need it. 

You will need it. 

Habit 2: Make peace with paranoia by consistently asking 2 questions – “why could this be great?” and “why could this suck?”

Every time you try to do something new or markedly different (e.g., pivot an established product), you will have both fans and cynics/critics. That’s just life.

After a point, you’ll realize that relying on feedback from fans or critics isn’t all that helpful. Nobody really knows. It is your responsibility to develop good judgment. Over time, few things will count more in the early phases of a project than the strength of your conviction. This will then be followed by your ability to execute to generate evidence to back up your conviction.

Given this, people can go 2 ways:

(1) The kool aid route. Pretend everything is awesome. Look at every datapoint or feedback as a way to just strengthen their conviction – typically by creating an underdog/seige mentality within the team.

(2) The “it is a disaster” route. Give in to the hundred obstacles that inevitably exist and flip-flop their way to doing nothing.

The middle path – as is often the case – is the hard path. On the one hand, it helps to both be constructive and surround ourselves with people who are constructive. That means we get rid of any time spent presenting problems and, instead, spend time asking – what would it take for this to have meaningful positive impact on our users? Then figure out how to make that happen. 

On the other hand, it is equally important to make peace with paranoia. Listen to the cynics and understand what the biggest reasons for failure might be. That dose of fear and uncertainty is healthy in reasonable quantities and will help us build better product. The example I think of is “Richard Parker” – the tiger in Life of Pi.

In the story, Pi Patel faces what feels like insurmountable odds when he realizes he has to survive on a boat in the middle of the ocean with a hungry and scary tiger. 

However, as he narrates his story, he says something powerful – “Without Richard Parker, I would have died by now. My fear of him keeps me alert. Tending to his needs gives my life purpose.”

That’s an example of the positive role fear and paranoia can play. It isn’t healthy to be driven by it. But, it is useful to embrace it along with optimism and conviction. 

And, one way to do that is to habitually ask 2 questions as we think about our work – “why could this be great?” and “why could this suck?”

They help us find the middle path and keep us grounded.

Habit 3: Invest in life and learning outside work to give you the perspective you need

This tends to be the hardest of them all – especially for all the type A over achievers out there. It is easy to give work our all, slump into what remains of the weekend with some Netflix, and then back to work. 

But, investing in a life outside work tends to pay massive dividends in the long run. When we invest in our health holistically – i.e., across physical, mental, emotional, and spiritual dimensions – we build character and resilience. 

But, I think most relevant to our psychology is that our life outside work gives us the space to gain perspective. This could be the work we do on our non-profit, learning a sport, deep conversations with loved ones, hiking, reading philosophy, strengthening our faith, building a side-project, playing with our kids or loved ones, or something else. Investing in 1-2 areas at any given time remind us that there is so much more to life beyond work. They remind us of our own mortality and thus remind us of a larger purpose and world of which we are a part of. 

This perspective helps us put our daily ups and downs in context. They reduce the amplitude of the swings. A good friend once told me that the graph of our emotional swings should look like an ECG’s reading. You want to avoid it being flat. You also want to avoid it being too high. Everything in between is normal.

 A story that I frequently think about and share on perspective is around a lesson someone shared with me when I was interviewing them – “You never know if a good day is a good day.” 

 In his first startup, a healthcare startup, they brought in a very experienced management team. It felt like a great day. 

A decade later, he worked for two years to acquire a company in Ohio. It fell through in the final stages. It felt like a bad day. 

But, looking back from when we spoke, the story was very different. The experienced management team made some decisions that led to the demise of the company. In retrospect, that was a bad day. 

And, when the deal fell through, he got recruiter to a start-up, saw them through a major exit, and went onto use the proceeds to become a successful angel investor and then venture capitalist. In retrospect, a great day. 

The takeaway – “One of the things I have come to learn is that you shouldn’t get too depressed on the downside, or too excited on the upside – just keep plugging away. Eventually, good things happen. You just never know if a good day is a good day.”

I’ve found this to be an enduring lesson. It is easy to get caught up in what feel like finite games with wins and losses. In truth, we are all playing infinite games where wins and losses are fleeting. In the final analysis, all that matters is being intentional about what game we choose to play and who we choose to play it with. There are few things worse than playing games we didn’t want to win. With people we never wanted to play with. 

Assuming we’re intentional about that, we just need to take care of our psychology and find strength every day to… just keep playing.