Impatience and the vacuum sealed container

A good friend shared an anecdote from her attempts at opening up a vacuum sealed container recently.

The process involves inverting the container into water being heated on a stove. After about 2 minutes, the heat expands the seal enough for the container to be opened.

Except, this time, she was in a hurry.

So, she tried taking it out quicker than usual.

No go.

So, she put it back in for a bit and took it out.

Again, no go.

After a few more attempts, she finally got it out.

She then reflected on how her unusual impatience had lengthened the process – the opposite of the intended outcome.

I found myself chuckling when I heard this. Unlike her, I’m guilty of impatience far more often and I’ve been guilty of doing this sort of thing more often than I like to admit.

I like to think the frequency of such incidents is far lower than it used to be.

Anecdotes like this remind me to make sure that is the case in reality.

PS: In case you’re curious, the container she was eager to open was of this pretty awesome Honey Citron Ginger tea. :-)

5 habits that help build high velocity product teams

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 –

I’ll start this post with two assertions.

i) Moving with velocity should be an explicit goal for every product team. Velocity is different from speed in that velocity is a vector. Velocity combines speed with direction.

No alt text provided for this image

Making velocity as an explicit goal does two things at once. First, it puts the onus on the leads in the product team to provide the team direction and ensure the path is as obstacle free as possible. For example, executives who commit to velocity do their best to clear out any alignment issues with fellow executives well ahead of the first line of code being committed.

Second, it focuses every member of the team on shipping/iterating quickly. This focus on shipping/iterating quickly turns out to be the best thing we can do to ensure the long term survival of our product.

If our product team works at a start-up, velocity can be the difference between life and death. And, if we work at a large organization, velocity can save us from having a smaller, more effective company, eat our lunch.

ii) Velocity doesn’t scale linearly with resourcing. The bottleneck to higher velocity isn’t always resourcing – it may be so 50% of the time. But, pointing to resourcing when there’s a lack of velocity happens close to 95% of the time. :-)

So, spending all available energy to grow the size of the engineering team working on a product is an amateur’s game. That’s because lean, aligned, and focused product teams operating with high velocity can blow better funded teams away.

As a PM, this might require a bit of reorientation as it is easy to fall into the trap of optimizing for the size of the team. I’d instead wager that it is always better to be part of a team that is known to punch well above your weight.

This, then, leads to the obvious question – if velocity doesn’t scale linearly with resourcing, what helps?

I think there are 5 habits that can step change the velocity of the product team.

(1) Replace hub-and-spoke leadership and communication with tight knit circles:

Many product teams operate via hub-and-spoke models. The PM may be the hub for some members of the cross-functional teams, the Eng manager for the IC engineers, and so on. Information flows from the hub to these spokes. You’re “in the know” when you have 1:1 meetings with the hub.

While this can make folks at the center of the hub temporarily indispensable, it happens to be terrible for the productivity of the team. Trust and psychological safety are the keys to effectiveness on a team. And, hub-and-spoke models aren’t optimal because they create silos that aren’t conducive to building either.

The good news is that there is a better way.

No alt text provided for this image

There are 3 things we can do as PMs to help a product team move away from this model:

    1. Replace 1:1 meetings with team syncs: Remove recurring 1:1s with various members of the product team and replace them with team syncs and stand ups
    2. Document EVERYTHING: Enable every team member to understand the context in which we operate by obsessively documenting everything – from strategy to roadmap to individual specs.
    3. Ensure shared context in meetings: Make team syncs and stand-ups productive by focusing on shared context. Every member of the team should understand what outcomes matter and how their work ladders up.

I think of this this mode of operation as a tight knit circle. Every dot on the circle is key to the shape. And, the space in the middle symbolizes the space we create for the kind of conversations that build trust and psychological safety within the group.

(2) Replace small meetings with large meetings that are used to create alignment.

Imagine you are close to launching a feature you are really excited about. Just as you get close, you realize there is a dependent team who wasn’t on the same page. Now, your team is faced with many weeks of rework before this feature sees the light of day.

This needn’t just be a dependent team. It may be an infrastructure team that didn’t get the memo about your change. Or it could be that your marketing team didn’t have enough time to prepare customers. Or an executive who is opposed to it. And so on.

Whenever a team is forced to do a lot of rework close to or after the launch date, you can be sure the culprit is poor product management. “Selling” is a core product skill for a simple reason – it is key to ensuring folks around you understand what problems you are solving, what they should be doing to help you, and why it matters.

No alt text provided for this image

And, a habit that helps with selling and bringing people along for the ride is embracing large meetings. Here’s why – in the formative stage of every product, it helps to bring the entire cross functional team along. And, if you are partnering with other product teams, that means bringing every member of that product team along too.

Sure, you can shortcut this and aim to only sync with a few of the decision makers. But, I can guarantee this strategy will cause pain down the line. It prioritizes short term efficiency over long term effectiveness.

Being comfortable with running large meetings and using them to create alignment lets us become liberal with the flow of information and context. That, in turn, helps us move significantly faster in the long run. How?

    • We get more eyes and perspectives on our problem statements and hypotheses. The dissent and rigor this creates helps us get crisper and clarify our thinking.
    • When we bring partners along, we avoid duplicative efforts and ensure there is no wasted work.
    • When other teams with similar goals and complementary assets buy into what we’re doing, such partnerships result can result in the evolution of existing platforms and systems – thus creating massive amounts of organizational leverage. It is magic when this happens.

That, in turn, speaks to the power of broad information flow and more perspectives in the room. It moves teams away from a focus on efficiency to a focus on leverage.

No alt text provided for this image

If you want to go fast, go alone. If you want to go far, go together.

(3) Be a Lannister and pay off your tech debts.

When was the last time your team had an urgent bug? I assume you celebrated the folks who burned the midnight oil to solve it?

Acknowledging and appreciating such efforts is good. But, we provide more leverage to our teams when we use such issues to prioritize upstream/preventative bets. Attempting to squeeze every inch of engineering capacity in the quarter to move metrics is a short-term efficiency focused game. And, again, if it isn’t evident, our goal isn’t efficiency – it is leverage.

To enable high velocity product development, we need to free engineering time from constantly dealing with urgent issues. And, we can do do that by marking off a proportion of our engineering capacity for foundational efforts.

No alt text provided for this image

This investment turns out to be one of the easiest things we can do to help create happy engineering teams. Such efforts don’t just reduce painful on-call shifts (they do that). In addition, they are often source of intellectually stimulating work that can often provide leverage to other engineering teams as well.

Finally, while we can run with a ~25% allocation as a rule-of-thumb, this can go up in some quarters depending on the nature of the team. Typically, the more backend work involved, the more it is likely we’ll need to make large investments and ensure the engineering team has the space and autonomy to build scalable systems.

Be a Lannister and pay off those tech debts.

(4) De-risk big bets with many small bets – remember the pottery class A/B test. Every once in a rare while, we’ll work on a project that will require us to take one big not-testable-till-we-launch bet. But, in the majority of cases, we can de-risk big bets by taking plenty of small bets.

It should come as no surprise that the way to do this is with the help of crisp problem statements, hypotheses, and success metircs. The clearer the assumptions in our hypothesis, the easier it is for us to validate them.

No alt text provided for this image

However, the bigger benefit of taking plenty of small bets is that it builds the team’s muscle to become comfortable moving quickly. This is where the story of the pottery class A/B test comes in.

Two artists, Ted Orland and David Waylon, once shared the story of a ceramics teacher who found herself teaching a class on two separate days, neatly divided in half. She decided to try an A/B experiment.  

To the first half of the class she said what she’d been saying for years – “You’ll be graded based on the quality of your work. At the end of the semester, turn in the single best piece of pottery you created.”  

To the other half of the class, she said something very different. She explained to them that they would be graded purely on quantity – “Crank out as many pots as you can this semester.” 

At the end of the term, she noticed that the best pots – both technically and artistically – didn’t come from the quality group, they came from the quantity group. By making pot after pot after pot, they were learning, and adapting. They didn’t set out to make the best pots, yet they did. Meanwhile, the other half spent the semester aiming for perfection and falling short.

(5) Live rug free – prioritize discussing the biggest challenges and be willing to change your mind.

The final habit that helps with velocity is living “rug free.” This is the most abstract note on the list – so, let me explain further.

When there are no rugs in the team room, it is impossible to sweep things under them. And, if we can’t sweep things under them, we have to be willing to encourage discussion around challenging questions and encourage thoughtful dissent.

It is easy to prioritize such discussions on our best days. But, on days when we feel our insecurities gnawing at us, it feels easier to just avoid these discussions and talk about the weather or argue about something meaningless.

But, it is precisely on such days when we should:

    • Ask – “is this the most important thing we need to discuss” – in a meeting that is going nowhere
    • Push for a discussion about a broken working model
    • Ask an executive if we’re aligned on the problem statement before getting attached to a solution

The fascinating thing about pushing for these often uncomfortable questions is that they are generally on the minds of others too. So, as long as it is accompanied by a willingness to listen to the response and change our mind based on that response, asking these questions ALWAYS helps move things forward. They help us resolve disagreements, remove discomfort, and get to alignment without letting any unpleasantness fester.

The courage required to live rug free every day isn’t talked about much. But, it has the potential to step-change the velocity of any team we’re on by changing the culture of the team. Focusing on the most challenging questions creates helps us understand how we make decisions as a group and creates an environment with high trust more often than not.

No alt text provided for this image

It is the sort of thing that never gets easy or comfortable – no matter how often we do it. We just learn to recognize when it is more important to push beyond our fears.

And, it always is.

When feedback works

I’ve noticed that feedback works in 3 situations:

1. “I am asking for feedback and am ready for it. Please give it to me straight.”

2. “You have feedback for me? I feel psychologically safe with you and trust your intentions – so, yes, please give it to me.”

3. “I report to you/believe you have power over my career/life. I will attempt to act on it even if I don’t agree.”

In all other situations, attempts at giving feedback end up achieving nothing.

The 2 hour story

I was texting with a friend who is working on an immigration related project.

He was sharing how overwhelmed he’s been by the support he’s received from folks he barely knew. He noted that it reminded him how life-changing it is to respond to people who reach out asking for help.

That, then, reminded me of a story I’d written about six years back.

A friend at Linkedin shared a story yesterday that Deep Nishar, soon-to-be former SVP of Products and User Experience, shared at his farewell.

Deep came from humble beginnings in India. When Deep was in secondary school, he learnt that a graduate from the school had been admitted at the Indian Institute of Technology. He understood it was rare and prestigious but didn’t know much beyond that. So, he asked this student if he could spend time telling him more about this. The student obliged and spent 2 hours with Deep explaining what the institutes were and how he might prepare to make it in. Deep took his advice seriously and secured admission when he graduated.

He went on to explain that that changed his life. It put him on a trajectory that saw him go to the University of Illinois Urbana Champagne, to Harvard Business School, lead Google’s efforts in the Asia Pacific and then play a key role in Linkedin’s growth over the past few years. All it took was 2 hours from a person who probably knew he would get nothing in return.

Deep’s advice to the Linkedin community was – if someone asks for a small amount of your time that could end up making a big difference to them, just do it. Don’t over think it. It might not mean much to you but it could mean a lot to the other person. And, who knows, it might even change the trajectory of their lives.

I loved this story. While we do occasionally get the opportunity to do big things, we get lots of opportunities to do the little things. We always have the choice to do the little things meaningfully.

It is stories like this that remind us how special this life is and how lucky we are to be here. Here’s to the little things… and here’s to giving small bits of our time to those who might benefit from it…

A heartwarming story I was happy to be reminded about.

Wishing you all a nice and restful weekend.

Randomness and stoicism

I listened to a fascinating description of stoicism in Nassim Taleb’s Fooled by Randomness.

“Having control over randomness can be expressed in the manner in which one acts in the small and the large. Recall that epic heroes were judged by their actions, not by the results.

No matter how sophisticated our choices, how good we are at dominating the odds, randomness will have the last word. There is nothing wrong and undignified with emotions—we are cut to have them. What is wrong is not following the heroic or, at least, the dignified path.

That is what stoicism truly means. It is the attempt by man to get even with probability. Stoicism has rather little to do with the stiff-upper-lip notion that we believe it means. The stoic is a person who combines the qualities of wisdom, upright dealing, and courage. The stoic will thus be immune from life’s gyrations as he will be superior to the wounds from some of life’s dirty tricks.”

It reminded me of the power of dedicating ourselves to the process and embracing equanimity with regards to the outcome.

It resonated.

Just keep swimming

During a time I was feeling stuck a few years back, a friend shared this video of Dory in Finding Nemo.

In it, Dory shares some sage advice with Nemo’s father about what to do when life gets you down. “Just keep swimming, just keep swimming, just keep swimming.”

It is a thought I’ve shared with folks over the years. Sometimes, the only way is through.

And, in the long run, it helps if we manage to show up regardless of the noise around us (and let’s face it – there’s always noise)… and keep swimming.

Not breaking the chain

I first learned about Jerry Seinfeld’s love for the “Don’t break the chain” approach to building habits years ago.

The approach is simple. Once you make a commitment, take a physical calendar and scratch out the date with a big red “X.” Then, refuse to break the chain.

While it didn’t resonate when I first heard it, I began using it (on an imaginary calendar) in the past weeks. It began with squeezing in a mini workout every day and it now translates to a mini workout + closing the 3 activity rings on my watch.

Thanks to this newfound refusal to break the chain, I’ve been able to keep these activities going more consistently than before. And, I feel its power every time I break the chain (e.g. for a recent day off). It feels temporarily acceptable to slip the next day.

But, once the chain is up and running, the momentum is back again.

Don’t break the chain. An idea that is as powerful as it is simple.

Validating our Problem Statement and Hypothesis

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 –

If there’s a recurring theme in most notes on “Notes on Product Management,” it is about the importance of starting from the problem statement and getting it right. That’s because failed experiments are a very expensive way to learn and we save a lot of cost when we front load the risk in the product development process.

No alt text provided for this image

Thus, we save a lot of wasted team + organizational time when we get our problem statement right. And, we create winning products when we get the hypothesis right.

Given how important these are, the question that should follow is – how do we ensure our problem statements and hypotheses are the right ones?

The first part of the answer to this question is straightforward – we will never have 100% certainty. All our product initiatives are experiments. Experiments, by definition, can succeed and fail.

But, as with probabilistic outcomes in life, there are things we can do to greatly improve the probability of success. In this case, we can do that by running a good validation process.

I. Validating the problem space

When we first looked at problem statements, we broke a problem statement down into 3 parts:

  1. User: Who is it for?
  2. Need: Is the need real?
  3. Business value: Why should we prioritize doing it right now?

Asking these 3 questions alone helps us weed out poor problem statements. In some cases, the target user is poorly defined. In others, the business value is really not clear. And, then there are others where we may see clear business value but only find a vague user need. Working through these questions ensures we avoid creating problem statements out of some anecdotal comment from a user in an interview or because of email feedback from an executive/founder.

That said, asking the 3 questions alone doesn’t suffice. The most challenging part of this is evaluating the question – “Is the need real?”

Over time, I’ve come to believe that there are only 2 categories of needs worth solving for.

(1) Are your target group of users getting visibly frustrated with the status quo? (bonus points if this frustration is causing abandonment)

(2) Are your users hacking existing solutions to get their need fulfilled? (bonus points for the most creative hacks)

No alt text provided for this image

These become easier to grasp with examples:

(1) The original Amazon Prime problem statement is a great example of frustration leading to abandonment. Shipping costs frustrated users and resulted in abandoned shopping cards. Ergo “free shipping.”

(2) For an example on creative workarounds, I thought I’d share one from my recent experience. Our team recently built a product after we observed widespread “hacking” of existing features on LinkedIn. As the COVID-19 lockdowns began in March, multiple companies shared news of layoffs. We then began seeing posts on the feed from members sharing news of the fact that they’d been laid off and asking for support.

Many of these posts were heartfelt as these layoffs impacted financial security, immigration, and/or insurance. And these members were using their Profile headlines and feed posts to say they were “urgently looking” and needed support.

This behavior was definitely against the grain of conventional wisdom on job seeking (don’t let hirers know you’re urgently looking). But, we were seeing tens of thousands of members share this urgency with all of Linkedin. And, most importantly, we were seeing hundreds of thousands of members support these members in the comments.

So, we debated how we might be able to help these members easily amplify this request for help and get support from the community. That debate led to the creation of “OpenToWork photoframes” which have been adopted by 3M+ members in the 3 months since launch – speaking to the intensity of the need.

No alt text provided for this image

In sum, take the time to lay out the a) user, b) need, and c) business value to validate your problem statement. The “need” is the hardest to validate. Visible frustration or creative workarounds/”hacks” from your target group of users are strong indicators that it is a problem worth solving. Powerful problems often have elements of both.

Beware solving problems where both of those are absent.

II. Solution space

Relative to validating the problem space, validating the solution space involves considerably more art than science. That’s because the source of inspiration for your solution can come from 4 areas (the first two will sound familiar):

(1) User complaints/frustration: We hear from our users via support calls/emails and when we conduct user interviews or research. The general rule with user feedback is to listen for the problem and ignore suggestions for the solution.

While that is often true with consumer products, it is bad advice if we are working on B2B products. Great B2B products are shaped by customer requests because B2B products have to solve for requirements beyond usability – legal, compliance, etc.

Thus, B2B product teams often have a long list of great problems + solution ideas from their customers on their backlog. The onus is on the product team to listen for these ideas, prioritize, and build them in the best way possible.

(2) Existing user behavior: We get to understand existing user behavior via analysis or experiments. The story of the hashtag is a great example of the power of following emergent user behavior.

Early Twitter user Chris Messina proposed using “#” followed by the name of the group to help users find related messages in 2007. Over the next 2 years, Twitter users increasingly began using these “hashtags” to enable others to search for tweets related to a particular topic. Twitter finally built in 2009 and the rest, as they say, is history.

(3) Competitor solutions: We learn about competitor solutions from various sources: i) our users/customers, ii) the news, iii) testing competitor products ourselves, and iv) via intelligence from internal teams (sales, business development, corporate development).

Few good competitor ideas go unnoticed. Great ones typically get copied. On occasion, we see exception ideas – those that can’t be copied by competitors despite their best efforts because they build on what is unique to the company.

(4) The team’s gut/insight, or specialized knowledge: These typically come from two places: i) pattern recognition from having solved similar problems before, and ii) knowledge of technology that enables a better solution.

Many many great companies – think of the likes of Intel, Zoom, Salesforce – have been formed by former employees who went on to solve customer’s problems better. Great products are built everyday thanks to an insight from a team member or an executive about a better way to solve a customer or user problem.

No alt text provided for this image

I’ve observed that it is a good sign if you’re arriving at a solution from more than one source. So, it helps to not get overly attached to one source for solutions and, instead, make sure we’re constantly collecting information, triangulating input, and synthesizing them.

Beyond that, the best we can do is to make our experiments as lightweight as possible so we can consistently learn from them and iterate.

A friend of ours is a poker enthusiast who loves teaching beginners how to play poker. The key tenet of his beginner’s poker lesson is to learn to separate the decision making process from the outcomes.

Sometimes, even the best decisions within a hand can lead to poor outcomes. That’s just a fact of life in a probabilistic game. But, in the long run, the probabilistic edge we gain from good decisions stands us in good stead.

Validation of problem statements and hypotheses works the same way. The reason to approach this phase of product development with an emphasis on a rigorous process isn’t because every product that emerges will be a hit. It is because the process helps us maximize the probability of hits in the long run.

And, besides, the core ability in the validation process is learning from every input – existing experiments, user and customer data/feedback, competitive data, insights from members of the team, and so on. That ability to learn stands us in good stead even when there are poor outcomes.

After all, it sometimes takes a Fire phone-esque failure to inspire the creation of an Alexa/Echo.