Month: September 2020

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 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
  • Skill #3 – Problem Solving: Roadmap, Product specs
  • Skill #4 – Building effective teams: Knowing thyself, Your manager, Product team culture

---

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.

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.

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

1. 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.

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.

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.

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.

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.

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.

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 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
  • Skill #2 – Selling: Sales and Marketing, Writing for executive audiences
  • Skill #3 – Problem Solving: Roadmap, Product specs
  • Skill #4 – Building effective teams: Knowing thyself, Your manager, Product team culture

---

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.

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)

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.

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.

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.