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.

Is that the most important thing?

Seth shared a powerful post yesterday.


If you want to have an argument, to raise tempers or to distract, the easiest thing to do is start bringing up things that are easy to argue about.

Not the things that are important.

Because the important things require nuance, patience and understanding. They require an understanding of goals, of the way the world works and our mutual respect.

If someone keeps coming back to an irrelevant, urgent or provocative point instead, they’re signaling that they’d rather not talk about the important thing.

Which is precisely what we need to talk about.


It hit me hard as it reminded me of a derailed meeting I was part of recently. It derailed precisely because we fell into the trap of arguing about something that didn’t matter.

I didn’t prod enough to unearth the question behind the question. I just took the bait and fell hook, line, and sinker.

“Is this the most important thing we should be discussing to make progress?” is a powerful question to ask. It keeps us moving forward.

We need more of that.

I certainly need to do a better job asking this more often.

RBG

Supreme Court Justice Ruth Bader Ginsburg passed away yesterday.

Despite being a star in law school, she wouldn’t be hired into a top law firm or be interviewed for a supreme court clerkship because she was a woman and, worse, a mother. She even had to hide her second pregnancy to seal an extension to her contract at Rutgers University.

Over the course of her ensuing career, she did her best to make sure doors weren’t unfairly closed for women that followed her.

And she did it with aplomb.

She will be missed.

Charles and Helga Feeney – giving while living

I loved Forbes’ piece on Charles “Chuck” Feeney. He became a billionaire by co-founding Duty Free Shoppers, decided to give it all away, and completed the project over four decades.

Aside from 2 million dollars he’s saved for their retirement, Chuck and Helga Feeney gave away eight billion dollars. They targeted wrapping up this project in 2020 and shuttered Atlantic Philanthropies on September 14th.

In his words – “We learned a lot. We would do some things differently, but I am very satisfied. I feel very good about completing this on my watch,”

I was reminded of the saying – “We make a living by what we get. We make a life by what we give.”

Make a life they did.

Success and the rear view mirror

Much of success – the kind that sticks around anyway – is being able to look through the rear view mirror knowing we did our best with the cards we were dealt.

It follows, then, that the best thing we can do today is to be thoughtful and intentional about the choices we make today about where we’re headed. The arbitrary outcome goals, disappointments of yesterday, random ego battles, and miscellaneous worries will fade in time.

All that will remain and matter is that we did the best we could with what we have.

And, that we did better when we knew better.

Ford’s Weekly Business Plan Reviews

When Alan Mullaly took over as CEO of Ford in 2006, the company was in serious trouble. So, one of his first moves was to institute weekly business plan reviews for the various businesses. The executives in-charge had to present their latest initiatives with a red/yellow/green status.

However, in his first few weeks, every status in every meeting was green.

This continued until he threw up his hands in frustration wondering aloud – “We are going to lose billions of dollars this year. Is there anything that’s not going well here?”

Finally, after weeks of prodding, one executive – Mark Fields, the Head of Operations – turned one slide red. This was a decision that would have lost his job under previous leadership.

When Mullaly saw the slide, he clapped, thanked him for the visibility, and asked everyone in the room if someone could help bring the initiative back on track. A valuable discussion followed (for a change).

Over time, other executives followed Marks’ lead and brought more colorful slides to these review. More valuable discussions followed. These discussions contributed to Ford’s turnaround in the subsequent years.

To change outcomes, we need to change behavior. And, to change behavior, we need to change the culture.

(H/T: Simon Sinek’s “The Infinite Game”)

Problem Finding + Solving with Executives

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 –


Every once a while, we’re going to find ourselves involved in a project that is under senior executive scrutiny. These begin with an exchange that might look something like this.

Executive: Initiative X is a key priority. I’d like to start meeting with the team regularly to understand progress.

Product team: Yayy! What we’re doing is important. This’ll be a chance to show awesome we are.

Executive: When is the initiative scheduled to go live?

Product team: 12 weeks from now.

Executive: I’d like us to find a way to ship this in 6 weeks. Let’s start meeting weekly starting next week.

Product team: Oh crap.

:-)

The exchange above was meant to illustrate the key difference in any project involving executives – URGENCY. If that isn’t evident the moment an executive wants to get involved, I hope it will be going forward.

That doesn’t mean we shortcut the product development process. The steps in the process remain.

No alt text provided for this image

We just have to learn to get it all done at 2-3x the speed.

Why projects with executive involvement are both a blessing and a curse

I think it’s important to start here because executive projects look all sunshine and roses from the outside for the uninitiated. They come with two obvious benefits – high visibility and an ability to accelerate impact from our work by cutting through any bureaucracy.

That said, they have an equal and opposite flip side. It can and does go horribly wrong from time to time. And, the best way to understand why is to imagine the product team as a custom-built car on a busy road.

Executives typically want that car to navigate the road safely at 2x the speed the car may be used to. Now, if all the parts of the car work together as a well oiled machine, the car will withstand the test just fine. But, for cars with malfunctioning parts, this pressure test can have disastrous consequences.

High visibility projects can thus shine light on both the good and bad aspects of a team very quickly.

There’s another hidden cost – as preparing for meetings with executives takes effort, it isn’t always worth the trouble for the team. Such meetings only become worth the trouble in 2 cases –

a) The team needs help with making decisions that are existential and/or irreversible and/or critical to the future of the company

b) The team needs help with aligning various teams in the organization

No alt text provided for this image

All this gets to a counter intuitive idea – regular meetings with executives to review your project should never be the goal for a product teamInstead, it should be to embody the desired amount of rigor and urgency to win their trust to operate independently.

So, once you get to a point where you feel the trade-offs aren’t worth it, it is just as important to ask for these meetings to end. Good teams show up well and even emerge stronger with executive scrutiny. Great teams don’t need it.

With that said, let’s move onto dealing with the situation we’re in – regular check in meetings with one or more executives.

3 tips to making the best use of executive interest in your product/project

(1) Start with the problem statement – the fundamentals matter more than ever.

The number one derailer in an executive review is a lack of clarity on the problem statement. In the majority of instances, the culprit is the product team that ends up sacrificing rigor in the interest of speed. That is an example of a false choice – speed can never be an excuse for less rigor.

In some instances, however, it can also be the executive who unwittingly pushes the team toward the solution before validating the problem. This can be a tricky situation for the team. But, I think the onus is still on the team to go back to the problem statement and call out the assumptions being made in jumping to the solutions.

Again, speed and urgency cannot come at the expense of rigor. Sacrificing rigor always comes back to hurt the product and the team.

(2) Take the time to understand both the product outcomes and culture outcomes.

The product outcomes/success metrics are often obvious – this project may be critical to driving revenue or engagement. But, other times it isn’t. Don’t be afraid to clarify the expected outcomes.

I recognize I am cheating a bit here as this is just another way to be aligned on the problem statement -> hypothesis -> success metrics (i.e. the fundamentals mentioned above). This just underscores how critical it is.

No alt text provided for this image

However, once you make 100% sure you’re aligned on the product outcomes, it is also helpful to understand what the culture outcomes are. When executives lean in on projects, they’re often attempting to use these projects as an example of the culture change they seek to make. For example, the executive might want to try out a new approach to product reviews or may want your team to be an example of how a team can collaborate/operate with urgency.

Culture outcomes aren’t always explicit. So, the onus is on the team to read the signs and deliver.

(3) Use the room to surface the hardest problems you are dealing with

There’s a fork here –

(i) For projects in early stages, use the time to ask all the toughest questions pertaining to the problem statement, hypothesis, assumptions, and the most challenging flows/design trade-offs. Of course, you don’t just ask the executives for answers here. You go in with your point of view and see if the executive is aligned with your perspective.

(ii) For projects in execution, create simple docs/slides that share progress toward ETAs and bring forth all the hairiest disagreements and decisions the working team is facing. Getting unblocked is what makes these meetings worth it. Creating picture perfect slides is a waste of time.

In short – don’t try to look good. Just focus on doing your best to make progress.

An important note here on collaborating with partner teams: If your project involves multiple teams, it is important to surface problems without throwing peers/partner teams under the bus. This sounds counter intuitive as it is tempting to think about such projects as a “blank check” to bulldoze other teams into getting what you want.

But, if it isn’t evident already – the “blank check” is a myth. While that can work in the short term, that is a sure-fire way to destroy your credibility with your peers. The goal is to persuade peers and partner teams on the merits of the argument, not because some executive said so.

So, the way to use executive interest in projects is to a) persuade peers/partner teams about the importance of the problem you’re solving and b) share the limelight with them by bringing them along into your executive reviews and making progress as one team.

No alt text provided for this image

Now that we’ve gone through tips on how to do these well, I wanted to make sure we cover 3 common mistakes.

3 ways to mess things up

(1) Not demonstrating urgency.

Here are three common ways teams show a lack of urgency:

(i) Wasting time in meetings by bringing poorly synthesized materials – if you need more than 2 pages or 10 slides to make your point, there’s room to be crisper. Meetings with multiple senior executives in the room are expensive – it is on the team to make them count.

(ii) Asking questions and entertaining doubt without making forward progress – As I’ve said multiple times, it is critical to ask questions. But, it is also vital to do this while continuing to make as much forward progress as possible. At the end of the day, if your Head of Product believes something is important and wants you to deliver, get it done already.

(iii) Padding ETAs to get to high confidence and/or to attempt to under promise and over deliver – This is a bad idea. I’d go as far as saying you want to be as aggressive as possible with your ETAs. Better to showcase urgency early and be a bit late. Executives understand things going wrong – but it is hard to excuse a lack of desire to move quickly on something important.

(2) Covering up misalignment within the working team.

Sometimes, teams worry about how executives might perceive misalignment. I remember a situation where we worked very hard to conceal misalignment. It resulted in a completely disjointed discussion and a failed meeting.

The purpose of such meetings is to have the hard conversations and emerge with clarity. Again, don’t worry about looking good. Just focus on doing your best to make progress.

(3) Expecting kudos and pats on the back.

Any team that goes in attempting to engineer kudos and pats on the back generally fails. Go to these meetings to get hard feedback and work through challenging problems. Any celebration of progress happens best when it ensues vs. when it is being pursued.

Additionally, beware celebrating “good meetings,” executive praise, and/or some arbitrary internal milestone. Product teams win when our users win. Everything else is gravy.