Product ramps, launches and an 8 point checklist

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 – 

We’ve been on a 3 part journey exploring solving for feasibility and PM <> Eng collaboration. The final part of this journey is all about releases – i.e., ramps and launches. For the purposes of this post, I’ll use the word “ramp” for ongoing improvements and optimizations and “launch” to describe a new/revamped product experience. 

No alt text provided for this image

(a) Ramps – building a drumbeat

While it is natural to think of large product launches as important markers of the team’s success, I believe building a steady drumbeat of ramps is a better leading indicator of a high functioning team. This is because of our tendency to overestimate the impact of a large product launch on our users. Launches get a product in the hands of users. A steady of drumbeat of ramps ensures the product is successful.

I think there are 3 things an IC PM does every week that helps build this steady drumbeat.

No alt text provided for this image

(1) Role model behavior that encourages high velocity experimentation: This sounds like a trivial step. What else would you build a culture around?

Many product teams unconsciously build a culture around trying to ship products that will not receive any criticism from executives or cross-functional partners. In such cultures, team are often stuck in perennial iteration mode and are sensitive to every piece of feedback and criticism. 

Most things we ship as an IC PM will have some detractors. Nothing we ship will be perfect. And, we will regularly have to field questions from seemingly disgruntled executives. We move past this by:

  • Developing a clear bar for when a product is ready to be released to members/customers. For example, releasing a product with a known dead-end is a bad experience and should be unacceptable.
  • Aligning and communicating a clear set of metric guardrails that will help us measure success at a small ramp (e.g. 1% or 5%)
  • ALWAYS taking responsibility when something goes wrong – our team should know that we’ll support them 100% if things go sideways

Assuming we do this, we should be able to free the team to experiment and learn.

(2) Build in a regular cadence of reviewing ramps and the pipeline: The release cadence for the team will vary a lot depending on the product. Enterprise product ramp cadence is more spread out relative to consumer products. API/backend-only products will be able to release faster relative to products that require changes across mobile and desktop platforms.

But, regardless, it helps to build a regular cadence of reviewing ongoing ramps, the pipeline, and sharing notes with the team. If every member of the team begins to understand which metrics matter as time passes, things are going well. That context will help them design and execute better experiments. 

(3) Communicate ramps and lessons learnt with the organization: Many product organizations have systems for communicating ramps – e.g. a shared slack channel or email distribution lists or a weekly meeting. If you don’t have one where you are, create one. Shared context helps. And, if you have one, make sure you use the forum.

It takes time and effort to craft the right message every time you ramp something. But, it is always worth it. It helps us thank team members, spotlight their good work, and share what we’re learning and doing with the rest of the organization.  

(b) Launches – Driving a rigorous process with an 8 point checklist

(1) Run effective “leads” standups with a good “Plan spreadsheet.”

Important launches will often involve 2-3 product teams working tightly together. I recommend bringing team leads together – at minimum, the product + eng + design leads – as often as daily close to launch day. If you don’t have a lot to cover, you can always cancel it. Frequent communication goes a long way in preventing problems before they happen. 

To make these productive, it helps to have a central organizing document. And, the one I’d recommend is a “Plan spreadsheet.” This spreadsheet will have, at minimum, the following:

  • Timelines/key dates
  • Experimentation setup
  • All post-spec decisions on business logic
  • Key dependencies
  • Bugs

When we write our product spec, we don’t yet have a full picture of some of the usability and feasibility constraints. Some of these become evident as we build design prototypes and yet some others only show up as we build the product. There will be many small decision and business logic updates we make through the process. The spreadsheet keeps everyone on the same page.

Here is a sample plan spreadsheet.

(2) Document your Go-to-Market/GTM plan and ensure your GTM pod is meeting regularly.

While it is okay to use your plan spreadsheet for your GTM plan, my recommendation would be to keep this separate. That is partly because this part of the process will typically be driven by a Product Marketing counterpart who will help align the GTM pod – typically a mix of folks from Marketing, Communications, Product support/Operations, Customer Success, and Sales. 

The frequency of meeting with the GTM pod will depend on the product. If we are shipping a sales-driven enterprise product, we would need a GTM team sync at least once a week. This might go up as we get closer to launch. 

The GTM process for an enterprise product is often intense and it helps to carve out time to share input on all the materials created by the team. This will include internal and external comms (blog posts, press, influencer education), marketing and sales training materials and FAQs, as well as help center articles and videos for the product support/customer success teams. 

No alt text provided for this image

(3) Run through legal, security, and safety checks

While these are required before a major launch (most companies likely have an approval process), it helps to build good relationships with folks in these functions and understand what they’re solving for. 

For example –

  • It is helpful to consult legal as soon as we have designs and placeholder copy so they can give us heads up if there’s anything to be changed in our flows.
  • Similarly, it helps to loop in our security counterparts as soon as we have a tech design doc. That will help them give us heads up of any areas where they expect information security concerns.

Problem in these areas can often block a launch. So, it helps to get ahead of them early. This also doesn’t mean we’ll always agree with, say, the recommendation from the legal team. It will just ensure we have the discussion and debate well before launch day.

(4) Be proactive about global language requirements and accessibility

These two checks help us accomplish two things at once. First, they help us ensure our products work for all our users. And, second, it is the right thing to do.

Two notes on these checks –

  • Being proactive about global language requirements isn’t just about making sure content is translated. It also means being sensitive to how our translations show up globally. A phrase that works well in English may show up very poorly in a different language. An English-only name or video may result in global users not feeling included – both lessons learnt from painful experiences. :-)
  • Accessibility issues are ideally solved at the level of the design system the organization uses. Ideally, there are a series of standard design components that have been created with accessibility in mind. That ensures we keep our focus on issues with any custom components built for this launch.

(5) Tracking spec

I’ll start with an admission here. I do not like building tracking specs. Building a tracking spec gets my vote for the least favorite part of an IC PMs job.

But, good tracking does a lot of good all at once. It gives us insight into actual user behavior that helps us iterate on the product. It helps every engineer on the team understand what matters to the success of the product. And, good tracking also helps the engineering and dev ops/SRE (site reliability engineering) teams build the right ongoing monitoring that can help us catch issues when they happen. 

Here’s an example barebones tracking spec we might use if we just launched a new “Experiences” module on Airbnb. We would now be able to measure how often users click the “hearts” in the image using this tracking. We could also add tracking around hovers if we wanted to understand user behavior further.

No alt text provided for this image

(6) Experimentation and measurement plan 

Complex products almost always need a dedicated experimentation plan. The absence of this plan – one that has been aligned across the product, engineering, and data science – can often be existential for the product.

If we don’t setup the experiment well or if we don’t have the right metrics to measure performance, our product may be labeled as a failure. Product launches that fail because of a lack of rigor in experimentation and measurement are often the hardest to stomach. It may have worked well. But, sadly, we’ll never know. 

I have multiple horror stories to share here. One story is when suboptimal metric definition resulted in a series of improvements over two quarters being labeled as unimpressive by a key stakeholder. We realized later that defining the metric right would have changed the perception of this body of work. But, it was too late to shift the perception meaningfully.

In another example, we had a near miss. In the absence of the right metrics, it initially led to questions about whether it was a failure. It turned out to be a high impact launches once we’d gotten measurement sorted.

(7) Testing/bug bashing  

A rule of thumb for bug bashes/testing – divide the number of screens we are shipping by two. For every 10 screens shipped across 2 or 3 platforms (iOS, Android, etc.), we will probably need 5 bug bashes.

Every team develops its own bug bash best practices. Here are a few notes on what has worked for me:

  • Create a separate spreadsheet with all the flows and test criteria – this is best coordinated by a tech lead/engineering manager
  • Ensure every member of the team is assigned roles (e.g. someone takes Chrome/Edge on Windows and Android, another takes Safari on iOS and MacOS, etc.)
  • Report all bugs in the bug sheet on your “Plan” spreadsheet – this is especially important if there are multiple teams involved
  • Triage these bugs together to align on P0s (ramp blockers), P1s (100% ramp blockers), and P2s (follow items) – it helps to triage these together to ensure the team is aligned on the decisions as these will often impact launch dates 

But, and this is where things get interesting, large group bug bashes aren’t as important if we’ve built a quality conscious culture within the team. That can be done by facilitating and encouraging really close collaboration between our design counterparts and the engineering team. When this works well, our design counterpart has already seen and shared feedback on screens before they’re deployed. They are in lock-step with the engineering team on small decisions and are seen as the “go to” for any and all questions on the details.

When this happens, it is magic. 

Finally, when we deal with very large releases (10+ screens across multiple platforms), it helps to use a readiness scorecard to ensure the team is aligned. Below is an example of a readiness scorecard – this is also in the Plan spreadsheet.

No alt text provided for this image

 (8) Beta and ramp

 If we’ve worked through the product development process – starting from the problem statement – the launch is the smoothest and best part of the experience. But, if we have taken any shortcuts along the way, this is the time we pay our debts. 

There are three truths I’ve learnt repeatedly over time. First, every shortcut we take during the process is a debt we will have to repay – often before we ramp. Complex business logic shows up in the form of bugs. A weak experimentation plan hurts our ability to measure success. And, poorly crafted problem statements may even block an initial ramp of the product.

So, don’t take shortcuts. Sweat the details ahead of that beta/ramp. It will show up in the form of a smooth ramp. 

Second, a good product development process nearly always results in meaningful business outcomes. I added a “nearly always” caveat because there are times when things don’t go our way. We always need that dose of luck in the final analysis. But, we also increase the probability of good luck finding you when we run a rigorous progress. 

Finally, launches are just the beginning of the process. It is great to celebrate launches. But, it is helpful to focus on what lies ahead just as quickly. In the long run, no one will care about our excellent product launch if we lose sight of the importance of driving adoption and evolution. 

When we do pay attention to that, we are left with that most beautiful of things – an enduring, high quality, product. 

All this brings us back to the question that got us started on this mini-series – what is the best response to the “how can we move faster” question?

As I said when we started, resourcing is considered a magic bullet far too often. It is tempting to look outward and complain about resourcing. I’ve been there.

But, our highest point of leverage often tends to be running a rigorous product development process and enabling our existing team to be at our best. Doing so means collaborating well with our product development team by getting better at our 4 core skills – problem finding, problem solving, selling, and building an effective teams.

Somewhat ironically, doing so puts us in the best possible position to be trusted with more resources.  

Step changing PM-Engineering Collaboration

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 – 

There are many variants of IC product management roles. Some are heavily customer facing and involve spending a lot of time with marketing, business development, and sales. Many require heavy collaboration with design. Some others have a strong data component.

But, the one common feature across every IC PM role is collaborating with an engineering team. Not only is this is also one of the biggest levers we have in our attempts to solve for velocity, this relation is also central to our day-to-day happiness as PMs. As I shared in “Solving for Feasibilty,” improving our ability as product managers can solve velocity problems we have ~50% of the time. And, the way to do that is by building habits that step-change our collaboration with our engineering team.

As collaboration with engineering is so fundamental to an IC product management role, we’re going to go back to the basics. We will take the 4 core skills we’ve discussed at length – problem finding, problem solving, selling, and building effective teams – and break these down into a collection of habits.

(1) Problem finding: Engage engineering leads early

(2) Selling: Explain “why” – every IC should know why their work matters

(3) Building effective teams: Be a great partner

(4) Problem solving: As this is the most used skill in our collaboration with engineering teams, we’ll cover habits that are important as part of prioritization and development in today’s post. We’ll cover releases in the next post.

No alt text provided for this image

(1) Problem finding: Engage engineering leads early

 “Engage your cross-functional partners late” – said no cross functional partner ever. :-) This applies to engineering leads as well.

Over time, you’ll have experience partnering with various kinds of engineering leads. I’ve come to think of 3 leaps engineering leads make –

  • Good engineering leads understand the the details and are hyper focused on shipping quality product within agreed upon timelines
  • Strong engineering leads add the ability to communicate well and also manage to be flexible to changes in plans
  • Great engineering leads understand user problems, our strategy, and objectives so well that they shape product requirements in meaningful ways

While some leads make these leaps in previous roles, others can make these leaps when we partner with them and engage them in our thought process. That, in turn, results in them pushing us to become better product managers. They do this by ensuring we understand the impact of our decisions.

For example, when our engineering leads push us on whether we feel our problem statements are strong, they’re reminding us of the cost of getting these wrong. I’ve spoken with irate engineering managers who’ve spent months building a product only to realize the product wouldn’t see the light of day.

It doesn’t matter that the reason is executive misalignment or that customers hate the idea of the product. From their perspective, it is months of wasted effort and damaged morale. And rightly so. Product development is expensive. The more we can do to catch problems early, the less the cost of the process.

No alt text provided for this image

Engage your engineering leads early.

 (2) Selling: Explain “why” – every IC should know why their work matters

A traveler was once passing a man cutting a big rock. She asked him what he was up to. “I’m cutting this rock” – he said.

After walking a few yards, she saw a second man working on another big rock. When she asked him what he was doing, he said – “I am building a roof.”

A few yards further, she saw a third man working on a similarly large rock. As she was still curious what was going on, she asked him as well. “I’m helping build a Jedi temple*” – the third man responded. “It is going to be beautiful when we’re done.”

(*He wasn’t using a light saber – in case you’re wondering)

I think this story is a useful way to think about whether you’re doing a good job selling. If every IC engineer on your team can explain what you are working toward and why their work matters, you’re in good shape. 

Else, keep at it. Explain why till you are tired of explaining why. You’ll be surprised just how much of an impact it has. You’ll find team members giving an extra 10% that you never thought possible here and another extra 10% there. 

Inspired teams do inspired work. 

(3) Building effective teams: Be a great partner to IC engineers

We will be covering building effective teams in more detail in future posts. This section is focused on being a great partner to your IC engineers. And, you can do that by paying attention to the context, trust, and communication trifecta.

No alt text provided for this image

The context-trust-communication trifecta is a simple way to think about the health of your team. They are like three legs of a tripod. Understanding this helps us understand why the majority of teams are dysfunctional. Teams work only when all 3 of these are healthy.

(a) Provide Context: In addition to sharing why what you do matters, use team meetings to share context. This includes any change in priorities that you’ve heard from the leadership, any key changes in strategy in the broader organization, important pattern changes in business metrics, and/or updates about related initiatives that partner teams are working on. Encourage engineering leads and other cross-functional partners to do the same. Shared context helps everyone make more informed decisions.

(b) Invest in building Trust: Invest one team meeting every quarter/few months to do something different. Play a fun game or organize an ice-breaker. The most powerful exercise involve members of the team sharing their stories. Getting to know each others helps build understanding and trust.

No alt text provided for this image

(c) Prioritize communication and responsiveness: IC engineering time is the most valuable time in software companies. Internalizing that idea means ensuring IC engineers on your product team are never blocked. While good problem finding and product specs help us with this, we’ll also need to be available for our engineers as problem solving partners when they face inevitable blocking issues.

This is why co-location is powerful for product teams. No amount of structured communication can replace walking over to a partner’s desk and solving the problem on a whiteboard. But, as we’re all in a virtual world for the next months, committing to a reasonable response time on Slack/email is an important replacement. 

This doesn’t mean reacting to every ping and never making time for deep thought. It just means setting clear expectations on when you’re unavailable and responding to folks every few hours to ensure no one is blocked.

As I mentioned at the start of this section, all of the above constitute the basics of building a healthy partnership with our IC engineers. We’ll cover this in more detail in future posts. 

4) Problem solving:

a) Prioritization – Invest in foundations/problem prevention (a.k.a “Be a Lannister and pay off your tech debts” in a post on “5 habits that build a high velocity product team” )

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. The 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). They are often the 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. 

b) Development:

i) Aim for leverage

Efficiency is minimizing effort for a given impact. Leverage is maximizing impact for a given effort.

No alt text provided for this image

 Aiming for leverage means 2 things in the development phase –

  • You build leverageable products: You pay attention to pieces of the product that can be reused in other places. If you’re building an “upload photo” screen, can that be reused in other parts of the product? Or, if you are building an onboarding flow with a series of steps, can you build it as a platform? That would enable other use cases to easily modify the flow when they need to.
  • You use leverageable solutions: This means reusing what already exists where possible. This will mean being a bit flexible on your plans. You may not get everything you want in a common component. But, if you do commit to it, you will now have multiple teams committed to improving it. Doing this will save valuable engineering time and create leverage across multiple engineering teams. The effects of this leverage compounds with the size of your organization. 

When Jeff Bezos mandated that every Amazon team would expose their data and functionality via APIs in 2002, he explicitly prioritized leverage at Amazon.

Of course, Amazon’s example won’t be relevant to every company and team. You are not going to be able to prioritize leverage if you are barely managing to survive or struggling to find product market fit. Shortcuts are inevitable. 

But, every shortcut racks up tech debt. So, if you have the luxury to take a bit of extra time to build it right or are part of a large company where a leveraged solution can have massive cross-team impact, it is worth the wait. 

ii) Document everything 

You’ve probably done lot of documentation in the problem finding stage – with a strategy doc, roadmap, and a product spec. But, for large product releases, I’ve found it helpful to have an additional doc – a “plan” spreadsheet. 

Unless you’ve got superhuman attention to detail, you’ll inevitable find a need to incorporate more business logic as you discover various edge/stress cases. These edge/stress cases may just be lines on a document to a PM. But, to an engineer, it could be the start of years of pain when services breakdown, angry users flood the support channels, and when executives criticize the craftsmanship of the product. Stress cases are important and we need to be as thoughtful about our decision making in dealing with these as with our P0 product requirements.

Every time you make a decision or update the logic, document it in your plan spreadsheet along with other decisions you make as you move towards a major release. We’ll spend more time on this spreadsheet in the next post. 

The process will ensure you don’t make one-off decisions in a slack thread that is buried somewhere. It will also force you to simplify business logic and variants. That, in turn, will reduce long term maintenance costs and improve your team’s velocity. 

c) Ramp/Release: This area is large enough to warrant its own post. So, we’ll cover this next week.

I hope this was helpful.

Solving for Feasibility

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 – 

One of the most common questions posed to product teams – “How can we go faster?”

Default response – “We need more resources.” 

It is a perfectly logical response to that sometimes dreaded question. 

The only problem is that it is right only around 30% of the time at best (anecdotal estimation). Assuming your company has a good engineering hiring bar and decent processes, the reality is that more accurate answers probably are – a) “We need more executive/cross-org alignment” or b) “I need to become a better product manager.”

If the answer in your situation is b), that is a painful pill to swallow. It hurts. But, after acknowledging that, the next question is – how do we move forward?

Today’s note offers a path to just that. 

Solving for feasibility

A product manager brings together a cross-functional team to build products that are valuable, usable, and feasible.

Once we find a valuable problem to solve and figure out a usable solution, the final step is solving for feasibility. Feasibility means shipping a quality product as quickly as possible with the engineers on our team.

No alt text provided for this image

It is important to recognize here that feasibility is the minimum bar for a product team. Velocity is the goal. In the long run, velocity is an important source of the team and organization’s competitive advantage. (The previous post in this series is all about velocity in product teams – so, I won’t belabor this point)

So, how do we increase the velocity of the engineering team? I think there are 5 levers under 2 buckets: 

a) Adding new folks

(1) Increasing the hiring/performance bar

(2) Increasing resourcing

b) Enabling existing folks to move faster

(3) Simplifying engineering processes

(4) Reducing exec misalignment

(5) Improving our product management abilities

No alt text provided for this image

Two of these – (1) Increasing the hiring/performance bar and (3) Simplifying engineering processes – are in the domain of how to run a good engineering organization. We won’t discuss as much because our influence as IC PMs is limited. That said, there are ways we can contribute:

  • Increasing the hiring/performance bar: Help with engineering hiring where possible and ensure you’re participating in the performance management process. Take the time to write thoughtful feedback, celebrate top performers, and so on. Share in the responsibility of improving the performance of the IC engineers on the team and support your engineering partner.
  • Simplifying engineering processes: Keep an eye out for the impact of existing engineering processes – documentation, code reviews, deployment – on the velocity of the team. Listen for complaints from IC engineers and help ensure they’re getting surfaced appropriately. 

(2) Increasing resources

As I mentioned at the start of this post, this is the most common lever product teams focus on. This is probably the right lever 30% of the time. And, it is definitely the right lever if you are leading a high performing team working on important projects with complete executive alignment that need to be developed faster. 

If this is you, there are 3 things to keep in mind:

(1) Make your ask as soon as you realize the resource gap. Unless you’re in hyper growth, it typically takes a few attempts before resources come your way. And, it also takes a few extra months to hire the right folks. So, get ahead of the game.

(2) Tie your resource ask to concrete outcomes – typically improvements to y/y growth on metrics that matter. Using commonly used/true north metrics helps the executives involved prioritize your ask relative to others (and there always are others).

(3) The most helpful tool in your team’s arsenal is the reputation of punching above your weight. If you have proven your ability to do more with less in the past, it becomes easier for executives to trust you. If you aren’t there yet, don’t be surprised if you aren’t getting the resources you need. You will need to work on that first.

An important, if obvious, point to make here is that the culture of your team will change as the team grows. An engineering team I worked with grew from 6 to over 15 engineers in 12 months. Challenges with scaling the culture are real – we’ll cover this in next week’s post. This isn’t an argument against asking for resources – it is just a heads up that your role and responsibilities will change significantly. 

(4) Reducing exec misalignment

Executive misalignment stunts velocity and damages morale. Executive misalignment plays out in many ways – slow funding decisions, uncoordinated efforts across teams, unnecessary internal competition and politicking, and so on. 

I called out this lever as one you can influence. Your influence will vary depending on the culture of the company –

  • If the culture is toxic, your influence will be proportional to the political power of the executive you report into. This executive’s power can help you move mountains… or not.
  • If the culture is one that promotes transparent discussion, you can have a lot of influence by simply laying out areas of misalignment early. Many companies have variants of “clean escalation” processes that are designed to do just this. Similar to asking for funding, the most important thing in such situations is to learn to pay attention to areas where there is misalignment. Once you spot it, act quickly.

PM roles come with a reputation of having decision making power. This reputation leads a lot of PMs astray. That’s because some of the highest value work an IC PM does is to call out the importance of the decision, lay out the framework, options, and make a recommendation for product leaders to decide. IC PMs are thus decision enablers vs. decision makers on the decisions that matter. Embracing that role goes a long way in reducing executive misalignment and improving the quality of decisions in your organization.

(5) Improving our product management abilities

It is not possible to do justice to our most important lever in this post. So, we’ll cover this in two posts over the next two weeks. But, I’d like to leave you with a recent example that will explain why I believe this is the most important lever we have.

One of the flows in a project I’m working on involves a few permutations. While we did spend time on mapping these permutations when we were designing the flows, multiple permutations stirs that tingling sensation within. That sensation is a sign that we need to take the time to work out the possibilities. That, in turn, will help us build the product right. For example, if there’s a lot of business logic, we’ll make sure this logic is handled in the API layer instead of the clients. 

I have my excuses for ignoring that tingling sensation here. But, they are excuses. All that matters is that I didn’t invest the time to bring the team together to map it out and document our plan.

Luckily, we’ve been in the process of rigorous testing and identified an issue through that process. But, reworking this involves a lot of wasted work. If doing it right took us about 5 engineering weeks, the reworked flow is going to end up taking 2x the time.

No alt text provided for this image

It sucks. We could all look around wondering why we didn’t catch this. But, the buck stops with me. And, it hurts to know that I wasted 6 weeks of engineering time. 

This is how poor product management hurts a company. In every software company, engineering time is the most valuable time. And, poor problem finding and problem solving can result in a LOT of wasted engineering time. Some wasted time is unavoidable on a large project. But, wastage can go out of hand. It is the responsibility of senior PMs and product leadership to keep a close eye on this.

I am past the stage where such mistakes resulted in moments of debilitating imposter syndrome. That is useless – I have learnt that. When these things happen, I repeat this line to myself – “Do not fear mistakes. Fear only the absence of a creative, constructive, and corrective response to these mistakes.” I read this line over a decade ago in my favorite book (Stephen Covey’s 7 Habits) and I still find it comforting and useful.

I now focus on using the pain to improve in my abilities. In this case, the lesson learnt is to not ignore that tingling sensation – that is experience telling me to pay attention. It is also a reminder to not fall for the pretext that there isn’t enough time to get it right.

After all, if we don’t have the time now to do it right, how will we have the time to do it twice?

Solving for usability

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…

Overview of what we’ve covered on “Notes on Product Management” so far: 

OverallThe IC PM RoleThe 4 key skillsRemote + Pandemic PM5 Decision Making frameworks/heuristicsProblem finding/solving with executives5 habits – high velocity product teamsGetting in – IGetting in – II

Skill #1 – Problem findingMost important skillProblem statement and hypothesisBuilding StrategyValidating problem statements and hypotheses

Skill #2 – Selling: Sales and MarketingWriting for executive audiences

Skill #3 – Problem SolvingRoadmapProduct specs

Skill #4 – Building effective teamsKnowing thyselfYour managerProduct team culture

A product manager brings a team of cross functional stakeholders together to build a product that is valuable, usable, feasible.

Our focus in most previous editions was on solving for value. We spent significant time here because this is both the most important and difficult outcome we need to solve for as product managers. That said, the time has come to spend more time on the other outcomes – usability and feasibility. And, today, we’re going to focus on the next key outcome – usability.

When we talk about usability, our focus will be on the user experience (Ux). An equation I use to think about the user experience is:

User experience = (User Interface + Interaction Design + Information Architecture) x Value

No alt text provided for this image

Let’s examine the parts of the equation:

– User interface (UI) = Layouts, fonts, colors, and illustrations

– Interaction design (IxD) = Effects of clicks, taps, and gestures – if you are building a feature as part of a larger product, the interaction design will be dictated by the design system in the product

– Information architecture (IA) = How the entire app/website is organized – if you are building within a large app or website, your product/feature is just one part of the entire user experience. So, every other feature and product plays a part in the user’s experience.

– Value = Both real and perceived value – real value is tangible and perceived value is often a result of the story/narrative/marketing. Both matter.

When you think of user experience in this way, you realize quickly that usability is EVERYBODY’s responsibility. Your design pod may be designing the user interface. But, it lives in the context of the design system and architecture of the entire app or product your user’s experience.

And, finally, value is the multiplier. If a user doesn’t experience value, all other effort goes to naught. Conversely, if you have a high value product, the impact of your UI + IxD + IA increases many-fold.

Think of Zoom as an example. As someone nicely put it – “Zoom’s UI may be average. But, the Ux is top notch.” Put differently, you can complain about the position of buttons on Zoom all you want. But, it works and works beautifully. Zoom’s technology reliably delivers vast amounts of tangible user value. So, any feature Zoom delivers (e.g. virtual backgrounds) builds on top of that powerful foundation.

It is also important to realize that value can be both real and perceived. If you are building enterprise products, a big part of your product’s user experience will be the customer’s experience of your sales force, customer success, and customer support teams. In a consumer product, a user’s experience will include the story that your marketing and communications team tells.

Usability is everybody’s responsibility.

A key part of building usable products, however, is building a product team that cares deeply about usability. I think there are 4 things we can do to make that happen.

(1) Build a strong partnership with your design partner and team.

When you start off as a junior IC, your design pod may look something like this.

No alt text provided for this image

Central to this pod is the relationship between the PM and the Design partner. When this relationship works well, it works because of context, trust, and communication (fundamental to all strong partnerships). 3 questions that can help you gauge this are:

(i) Context: Can your design partner talk through the strategy/problem statement/hypothesis/success metrics? What about the timelines – do they feel bought into the level of urgency required?

(ii) Trust: If she were out of the office next week, would she trust you to make user experience decisions on her behalf? And, if yes, would she also trust you to make timeline commitments on her behalf?

(iii) Communication: When you walk out of conversations with each other, do you feel you are on the same page?

These questions point to what we can do to make this a strong partnership. Ideally, our design partners are with us at every step of the problem finding process. They’ve worked with us on defining the problem statement, understand the data, success metrics and business value, and are bought in on the hypotheses we are testing.

We then earn their trust by building in time for creative exploration. That enables our design counterpart to explore multiple possibilities before picking a solution. Taking the time to do this right saves a lot of time later as it ensures we don’t get overly attached to one possibility.

Context and trust make communication easy.

An absence of context and trust on the other hand lead to the two variants of the worst PM <> Design relationships. Misaligned teams find themselves in debates that go on forever without progress. They struggle to make decisions without help from their managers. 

And, in teams that lack trust, the designer and his managers see themselves as the guardians of the user experience and view the PM as the (evil) representative of the business. This is the worst variant as it guarantees dysfunction and toxicity.

Understanding how to build strong partnerships in your design pod matters a lot as you grow as an IC because the size of the design team grows as you take on larger projects. Larger projects mean larger surface areas that can involve opportunities to impact huge parts of the user experience. But, it also means dealing with a design team that is a combination of many design pods.

No alt text provided for this image

Given this size, it won’t be just you and your design counterpart. Instead, the core team iterating on designs can vary from be a team of 6-10 folks. As an example – until a week or so ago, a design team comprised of 8 met every day for at least one hour for nearly 8 weeks as we worked through designs on a large project.

As the design team scales, the importance of context, trust, and communication continues to increase exponentially. Ensuring everyone has shared context also involves obsessive documentation and planning so everyone understands their role on the team. (We’ll cover this in detail in an upcoming post.) 

(2) Make it unacceptable to ship a screen without making thoughtful choices about every aspect of it. 

If the designer on the team is the only person obsessing about the user experience and user interface, you have a dysfunctional team on your hands. Every member of the product team must care deeply – for every line of copy, every pixel, and every stress case.

Your design partner will of course be in-charge of decisions on the UI and key parts of the user experience. Your marketing partner will likely be making most of the decisions on the words you use. But, as an IC PM, it helps if you consider it unacceptable to ship a screen without having thought through and debated every aspect of the user experience.

The test for this is: if a user stops you today and asks you why you chose the words you shipped or why you chose to put a button where you put it, it is unacceptable to say – “we didn’t give it much thought” or “that was my design partner/marketer’s decision.”

 As a product manager who builds user-facing products, our track record and impact is entirely a product of the screens we ship. And, again, it helps to consider it unacceptable to ship a screen without making a thoughtful choice about every word, image, and, interaction in partnership with our partners on the team. 

(3) Pay off your Ux debts – make sure “P1” isn’t short for “will never get shipped”

 As you ship the first version of your product, you will have to make compromises. That is just the nature of the game. There is no way you are getting everything you want in your MVP/minimum viable product. Something you want will be too heavy a lift for the engineering team and won’t be worth building till you are sure the MVP is working well. (Conversely, if you are getting everything you want in your v1, it is likely you are not prioritizing well.)

What do you do then? Does that result in an uneasy stand-off between you and your design counterpart? As you mark critical features as P1, do you do it with grudging support? These dynamics make and break relationships within the the product team.

There are three things great teams do here. First, they focus on building MVPs right. Instead of attempting to get some basic version of the product out, they focus on the riskiest assumptions that need to be tested.

No alt text provided for this image

(Image credit: Applico)

Next, they align on the “P0” features to test the riskiest assumptions. They do this together. When they find themselves dealing with technical challenges, they go back to the drawing board and prioritize again. Together. The focus on the team is to figure out the best possible path to validating assumptions while still being shipping a product they’d be proud of.

Finally, once the MVP does work, they make the time to ship those P1 features and ensure they make time to pay off their user experience debts. This can be a particularly difficult choice to make in the short term as it is tempting to go shoot for your next metric win. But, craftsmanship matters greatly in the long run.

That’s because investing in craftsmanship means fewer bugs, fewer support tickets, and more user delight. And, it also helps build a high trust relationship between the PM and design counterpart. If “P1” becomes short for “it’ll never happen,” expect lots of disagreements and drawn out arguments when you need to move quickly.

Pay off your Ux debts.

(4) Every time you look at a screen, ask “how can this be simpler?”

You will go into rabbit holes and attempt to over engineer your product. That is guaranteed. When that happens, you will hopefully have surrounded yourself with a team that stops you from doing it. 

But, ideally, you stop yourself by asking yourself one question every time you look at designs – how can this be simpler for our users?

Generally, this means –

– Fewer choices for our users to make
– Faster loading time
– Less business logic and fewer variants that help ensure reliability
– Fewer screens
– Clear instructional/direct copy 

This isn’t meant to be dogma. There are situations where doing the opposite may be simpler. We once added two extra screens to a complex single screen flow to make it simpler. And, that lifted outcomes by 50%. But, as a guideline, fewer and simpler is better. 

We become power users of our product by virtue of the time we spend on it. That isn’t true for our users. They don’t have the context we have. They don’t invest the time we invest either. 

If we can just be an advocate for simplicity and build this muscle across our team, our team will win.

As you can tell, this post was intentionally not about choosing the right user interface pattern or testing 30 shades of blue. Of course, if you are working on a product that provides as much tangible user value as Google search from 2005 while maintaining an incredibly simple UI, testing 30 shades of blue may indeed be the best use of your time. :-) 

Instead, this post intended to do two things. First, it provided a mental modal to help us think about usability through the lens of user experience. As user experience is a combination of every aspect of the user’s experience of our product, it is everyone’s responsibility. And, as product managers, it is our responsibility to understand that and think holistically as we build features and products.

Second, it is all how we can contribute to the design process – by obsessing about the details as a team, paying off our Ux debts, pushing for simplicity, and building a strong partnership with our Design counterpart.

The PM <> Design relationship is a special relationship as our design counterpart is the creative wheel that brings words on a strategy doc or a whiteboard to life. Given its criticality, it can be incredibly frustrating when it doesn’t work. And, while some part of this relationship is result of chemistry, a significant part of it is a result of the process you follow as well.

Here’s to better process.

Getting into Product Management – II (Interview prep + 3 things that help)

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…

Overview of what we’ve covered on “Notes on Product Management” so far: 

– Overall: The PM RoleThe 4 key skillsRemote + Pandemic PM5 Decision Making frameworks/heuristicsProblem finding/solving with executives5 habits – high velocity product teamsGetting in – I

– Skill #1 – Problem finding: Most important skillProblem statement and hypothesisBuilding StrategyValidating problem statements and hypotheses

– Skill #2 – Selling: Sales and MarketingWriting for executive audiences

– Skill #3 – Problem Solving: RoadmapProduct specs

– Skill #4 – Building effective teams: Knowing thyselfYour managerProduct team culture

We covered the paths into product management in last week’s post. This week, we’re going to focus on improving our chances when we get the interview.

The 4 interviews

We’re going to focus on the 4 main interviews – (1) Product sense, (2) Product strategy / analytical ability, (3) Product execution, and (4) Behavioral

These aren’t the only interviews. Some companies and roles may have other variants and some may combine interviews – e.g. Product strategy + execution. But, these 4 elements tend to be tested.

These map in the following way to the 4 skills we’ve been covering in past editions.

No alt text provided for this image

(1) Product sense:

The product sense interview is the most important interview of them all. Nailing the product sense interview doesn’t get you the job – but, it gets you close. Messing this up, on the other hand, guarantees rejection.

How to prepare: I’ve written multiple posts about problem statements – so I won’t belabor the process. But, the short answer here is – develop a habit of working through the fundamentals every time you see a product.

No alt text provided for this image
  1. Problem statement: Who is this for, what is the need, and what is the business value of doing this?
  2. Hypothesis: What are the riskiest assumptions and how can we validate them (ideally cheaply)?
  3. Success metrics: What are the true north, signpost, and guardrail metrics?

Once you cover these, you can begin to approach the solution space –

The Test: How would you structure a lightweight test to see if our hypothesis lead us to the success metrics?

Risks: Are there any key risks you need to call out? (think: technical challenges, go-to-market investment, etc.)

In the heat of the moment, it is tempting to rush into finding a solution. But, doing this well consistently requires us to be rigorous about thinking problem-first. So, the best way to prepare is to keep practicing this with problem statement teardowns. Do this for all kinds of products

– Products you love
– Products you don’t like
– Physical products
– Products in companies you are interested in interviewing for

Work through this for at least 20 products and write or type your answers. Over time, it’ll become second nature.

Where candidates stumble:
Jumping into the solution space too quickly. This is the most common area where candidates stumble.
Business problem focused. Prioritizing business problems instead of user or customer problems never ends well.
Ignore large risks and technical challenges. E.g. If you have a problem that involves thinking about a live video solution, you better be thinking about challenges like technical infrastructure and content moderation.

(2) Product strategy / analytical ability

The product strategy test is more prevalent as the role gets senior while more junior candidates are tested on analytical ability. As is the case with problem finding focused interviews, these are important to get right. And, getting these right isn’t about getting to a “right answer.” It is a matter of pausing to understand the problem we’re solving and structuring our approach to the solution.

How to prepare: There are 2 common variants of questions:

(i) How should we grow? (e.g. should we acquire xyz, should we build abc, etc.?)

No alt text provided for this image

All tech companies grow via 3 ways – a) build, b) buy, and c) partner. It helps to start here and work through the costs and benefits of each of these options before focusing on the most promising option.

ii) How would you diagnose this problem? (e.g. engagement is down today/we need to grow revenues/our onboarding flow is not leading to retained users – what would you do?)

The key in any diagnosis problem is to construct the equation. There is always an equation. Here are 3 revenue focused example equations.

No alt text provided for this image

You can also map out similar equations for engagement or retention. Needless to say, make sure you map out the key equations for the company/role you are interviewing for.

It is also important to work through 10-15 estimates with real numbers – i.e., do some old fashioned multiplication and division. There is always a possibility you will meet an interviewer who’d like to test your ability to guesstimate – particularly in growth focused roles. 

 Where candidates stumble:

  1. No structure. No structure in solving the strategy problem. Again, this is a variant of jumping into the solution space too quickly.
  2. Poor math. Unable to think in terms of an equation for the diagnosis. And, in some cases, demonstrating an inability to work through the math.

(3) Product execution:

This tends to be a relatively easy interview for folks who have good past experiences. It is correspondingly hard when you’re trying to break in. The simplest way to do well here is to take on a product side project before you interview as it’ll help you have some stories to talk about (we’ll get to this below).

How to prepare: There are a sequence of steps involved with building a product that raise questions.

  1. Alignment and conflict: How would you deal with alignment with other functions and teams? The first step this typically involves writing a strategy doc and a spec to ensure you can bring multiple groups along. When alignment doesn’t happen, you need to discuss, influence, and escalate to executives if you’re still not able to find a way.
  2. Design and engineering problem solving: How do you approach reviewing a screen and improving the user experience? How would you approach a technical challenge you’ve run into?
  3. Go-to-market: How are you thinking about go-to-market and distribution? For B2B products, this is especially crucial and should mean you’re thinking about running a pilot. 
  4. Adoption: How will you drive adoption after launch?
  5. Prioritization: How will you continue to evolve the product and prioritize customer feedback?

(Note: We haven’t covered b), c), and d) as yet on this newsletter – more to follow in future editions)

Where candidates stumble:
Naïve about alignment and conflict. They either miss it or back themselves into a hole by refusing to think about aligning incentives and getting executives involved if it isn’t working.

Ignore go-to-market. “Build it and they will come” rarely works.

Ux miss. Complete absence of thinking about user experience details when designing a screen.

(4) Behavioral/leading teams + selling

This interview is standard. They tend to help make the yes/no decision on candidates assuming they’ve passed the above interviews. I think these interviews are a big opportunity if you’re looking to break into product management as they give you the opportunity to shape your narrative in the minds of the interviewers. You can move them from describing you as “that data scientist candidate” to the “candidate who loves building community products.”

How to prepare:

i) Meeting the bar:
Create a compelling self introduction: You know they are going to ask you to “tell me about yourself” – prepare a compelling self introduction in ~2.5 mins that beautifully brings together a) your why, b) your progression and what you’ve learnt, and c) why you’d be a great fit by showing you have the skills required.

No alt text provided for this image

Nail 5 key stories with the help of a behavioral matrix: Start by building a behavioral matrix where the rows are key stories/experiences and the columns are areas you believe you’ll be tested. These vary by company – but, they typically involve some combination of leadership, influence, communication, and the company’s values/principles. For example, if you’re interviewing at Amazon, you need to make sure your stories map with the key leadership principles. Once you make your list, write each story out in detail (use the STARL framework to structure your thoughts – situation, task, action, result, learning) and pick 5 key stories that you practice until they flow naturally.

No alt text provided for this image

Ask thoughtful questions: The Firstround blog had a recent post detailing ways to approach this. The key here is to be thoughtful about the questions you ask. I have, for example, always asked my interviewers for feedback on how I did and any advice they have for me. These are authentic to me as they flow from how much I value learning and I’ve been fortunate to receive candid responses on both of these nearly every time.

 ii) Exceeding expectations:
Go in with a clear strategy: When interviewers debrief, they’re going to be describing you with 1-3 words or phrases. Be intentional about what those should be and make sure it keeps coming across in your interview processes.

Don’t just tell them what you did – explain your thought process: The expectation in a behavioral interview is that you’ll answer the question. But, you can exceed expectations by explaining how you’d approach such situations. For example, “Tell me about a time when you dealt with conflict” could be answered with a situation. But, if you started with a line that went something like – “When I find myself dealing with conflict, I focus on doing 3 things – understanding the other person’s point-of-view, having a direct conversation, and then escalating to an executive so we make the right decision for the company. I did this recently when….” This clearly gets to the point of the behavioral interview – to understand how you’d deal with challenges on the job and highlights your structure and thought.

Where people stumble:
Ramble without a sense of time. This is the most common offense. I’ve occasionally stopped folks from continuing a self introduction that was approaching 10 minutes.

Vague about their role. A simple rule – tell your interviewers about what YOU did in a situation. Candidates who couch their answers in “we” don’t inspire confidence.

No structure. It helps to be structured and precise in your answers. This isn’t as much a red flag in junior roles as this is a learned skill. However, an absence of this becomes costly as the role becomes more senior.

Now that we’ve worked through the details of the interview process, I’d like to leave you with 3 things that help when you’re attempting to break into product management:

i) A product management side project: There are 3 variants of this stacked in priority order:

a) PM project in your company: These aren’t easy to come by and require finding existing PMs who are able to find a spot + are willing to take a bet on you. The best opportunities tend to be those that folks tend to avoid. Find the most unappetizing edges of the product or customer experience – bonus points if you can contribute to these with your existing skills. Your PM partners will be happy to have your help and you get an awesome opportunity to learn and potentially have an impact.

As an example, my first PM project was going through thousands of apps as we began beta testing our LinkedIn Audience Network, categorizing them, and surfacing them to our leadership to make decisions on our approach to quality. Totally unappetizing for most – perfect for me to get my foot in the door. :-)

b) Build an app or website: This is the next best option. Build an app yourself or find friends who are willing to go through the process of building something useful. The biggest benefit of this approach, if you don’t have a technical background, is that you’ll get an education in technical basics. Think through decisions like – What cloud vendor will you use and why?, what language will you build the app in?, are you going to set up a NoSQL database?, what should the database structure be?, what APIs will you use?, etc.

 c) Write: If none of these are possible, consider writing. Do problem statement and user experience teardowns on a blog. Your audience need not be anyone beyond your mom or spouse. Just attempt to teach someone – it will clarify your thinking.

ii) Think in 5 year horizons – don’t fall into “I want the dream role now” trap

Most fellow prospective PMs are trying to get their dream role in that dream consumer tech companies. Do the opposite. Start by getting in – find niche areas where you can add value, get into lesser known companies, or find roles in the product team in companies you care about. Then, find ways to keep moving toward that dream job.

This is especially true if you are limited by immigration system problems. You may have to prioritize immigration until you have stability and make suboptimal choices. That’s okay.

It is a marathon. And, the only person we compete with is ourselves.

iii) Prepare hard and remember there are 26 years letters in the alphabet

When you attempt to break in, you get very few shots. This is especially true if you are limited by your immigration situation. So, the best approach is to prepare hard and aim to leave little to chance. Here’s an approach to structuring your preparation that I recommend –

– Start with 10%-20% of prep focused on an overview of the different interviews and how you plan to approach them
– Do 2 mock interviews with the toughest interviewers you can find – this will help you calibrate and understand where you need to put in extra effort
– Next, go into preparation mode and get yourself to 80%-90%
– Do another 5-6 mock interviews and re-calibrate
– Then, work your way to 100% prep / confidence

Ask for plenty of help (you can pay it forward later) and ask around for folks who are tough interviewers. You’ll learn the most from these interviews. 

Finally, even if you leave nothing to chance, there’s going to be plenty of chance involved. But, this is when we need to remember that there are 26 letters in the alphabet. Keep at it.

The path isn’t linear.

No alt text provided for this image

And, you only need one to work out.

I hope this helps. All the best! 

Getting into Product Management – I

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 RoleThe 4 key skillsRemote + Pandemic PM5 Decision Making frameworks/heuristicsProblem finding/solving with executives5 habits – high velocity product teams

– Skill #1 – Problem finding: Most important skillProblem statement and hypothesisBuilding StrategyValidating problem statements and hypotheses

– Skill #2 – Selling: Sales and MarketingWriting for executive audiences

– Skill #3 – Problem Solving: RoadmapProduct specs

– Skill #4 – Building effective teams: Knowing thyselfYour managerProduct team culture

I started writing “Notes on Product Management” nearly 2 years ago. The most requested post topic that I’ve received since then has been – how do I get in? 

I’ve waited all this time because I wanted to paint the picture of what the job is actually like before talking about how to get in. As a result, the past 17 posts have all about the 4 key skills required as an IC product manager – problem finding, problem solving, selling, and building effective teams. 

While the series is not yet done, I hope you have enough of an overview of the skills required to decide if you think you will be a good fit. And, assuming that is the case, I thought now might be a good time to talk about getting in. We will cover this topic in 2 parts. Today’s note will focus on the worst about product management and the 4 paths in.

(1) The worst about product management

I like to begin any discussion about getting in by laying out the worst about product management. The 5 biggest complaints I hear from folks at larger product driven companies are: 

1. I spend too much time attempting to align and influence large groups of people who all seem to have different priorities. Once I do that, I need to to influence my leadership to give me resourcing. Everything seems to political – it is exhausting. 

2. My manager/leadership keeps asking me to move faster. But, they don’t help with any of the alignment and they seem to keep changing their mind about about strategy and goals – this creates a lot of churn that I need to manage.

3. Some proportion of my cross-functional partners are either difficult or unhappy with me because they don’t feel as included in the product development process. Or, they think I’m making the wrong decisions. It is wearing me out.

4. I am in meetings all day. When do I get work done?

5. Does the product I work on really matter? I seem to be stuck dealing with minutiae about it every day and I’m not sure if it is improving the world in any real way.

And, the biggest complaints from those who are not in product driven organizations is – “How do I show the key function (typically engineering) that I can add value and that they should trust me?”

While they don’t show up all at once in every product team, they’re meant to paint a picture of the challenges involved in the product development process.

No alt text provided for this image

At this point, I’ll digress for a moment to talk about segmentation. The key lesson in segmentation is – you need to find segments that love what’s good about you and don’t mind what’s bad about you. It is great marketing advice. It also happens to be great life advice – in picking a significant other, a co-founder, or even a career.

That, in turn, gets to why I like starting out conversations by outlining the worst about the job. Product management is a “hot” career in technology right now. There’s a lot written about the opportunity to drive impact, make key decisions, and lead. While some of that is true, it is easy to buy into an incredibly rosy picture.

Like all careers, it has its positives and corresponding negatives. And, like all choices, just because it is “hot” may not mean it is the right choice for you. We spend all our waking time doing our jobs. And, spending those hours doing things we don’t enjoy or don’t want to get good at is a sure-shot way to be miserable. 

So, the question that follows is – what is your reaction when you see the list of complaints?

There tend to be (variants of) 3 responses:

a) I don’t like the sound of it. But, I’m still interested to get in because I want to make decisions/think it will be good for my career.

b) I get that this stuff is hard. I think I will find portions of it hard too – but, I think I will also make it through because the upsides – i.e. being able to facilitate the product development process – are worth it.

c) I love obsessing about bringing groups of people together and obsessing about things to build. So, I think this will be great.

a) is a red flag. b) can work – especially in organizations and teams with cultures that fit you. c) is a sign that you’ll thrive.

(2) Getting an interview – the 4 paths in

The way into product management is a pain for most people. This tends to be the case with any “hot” career simply because the list of people trying to get in is much longer than the list of people actually being hired. This is especially the case at successful companies/companies with strong talent brands. 

This results in companies adopting some bizarre methods to filter people out. One such method that was in vogue for a long time was the Computer Science degree requirement. Another was the coding interview. And, some programs insist that you must start at an entry level position regardless of past experience – this makes it harder to switch if you aren’t early in your career. 

If you’re facing some of these hurdles, I feel your pain. The only consolation is that it isn’t personal. After watching folks go through this process for the past 5 years, I’ve learnt that there is one certainty. People who have both the drive and skills find a way in and have good outcomes. It may take longer than they expect but it tends to work out. 

And, it happens in one of these 4 ways. They are ranked from most probable to least probable with rough percentage estimates.

No alt text provided for this image

i) Internal transfers (50%): This is the most common path into product management.

Why it works:

– You can build a reputation internally that helps you find a sponsor within the product management organization who will give you a shot.

– You can work on an internal product before becoming a product manager. This already proves you can do the job and helps in the internal interview process.

– It is agnostic of company size. In start-ups, you get a combination of fewer available roles and more flexibility/lack of any internal mobility bureaucracy. In larger companies, you have to deal with more rigid transfer processes but also will have more opportunities come by.

Who it works best for:

– Folks who work in functions with strong proximity to product managers. Function that are closely involved in the product development team – e.g., Engineering, Design, Biz Ops, Data Science, Product Marketing – tend to be the biggest beneficiaries of internal transfers.

– It tends to work best for folks who find opportunities in areas that are adjacent to their skillset. For example, a marketer can be great for a product that is trying to find product market fit with customers, a data scientist can do great in a data-heavy AI product, and so on.

Why it doesn’t work: Internal processes can make switching painful. And, cultures that are less open to internal transfers can exacerbate the pain.

ii) University hiring and APM/RPM programs (20%): This is most applicable to folks interested in larger companies (Amazon, Google, Facebook, LinkedIn, etc.) with established programs.

Why it works:

– Such programs typically give you a clean slate/fresh start and typically offer a lot of mentorship along the way

– You are typically competing against people like you – so, you don’t have to deal with that company insider who has already been working on the product over the past 6 months

 Who it works best for:
– For folks in undergraduate or graduate school programs who either have companies come to them (campus recruiting) or proactively reach out to campus recruiters and potential hiring managers.

There are obvious exceptions to this. Amazon, for example, hires hundreds of MBA students every year but is famous for not being influenced by proactive reach outs to recruiters.

Similarly, Facebook’s RPM program is open to folks with experience in other functions (vs. just students). But, as a general rule, being proactive helps unless you’re sure your experience will stick out amongst a pool of hundreds of applications.

Why it doesn’t work: Lot of competition.

iii) Companies or hiring managers who are desperate enough to take a bet on you despite your lack of experience (20%):

Why it works: It is born out of need and it often sets folks who’re hired up for success because you’re hired to get a specific job done and can use the experience to build up PM skills.

Who it works best for:

– Companies with weak talent brands who are desperate to hire strong talent who would not break into PM roles directly elsewhere. (It is important to note here that having a “weak” talent brand isn’t necessarily a bad thing. Most startups, by definition, have weaker talent brands compared to a Google.)

– People with deep expertise in specific areas that a company needs – e.g. growth marketing, SEO, enterprise security, etc.

Why it doesn’t work:

– These tend to be more common in smaller companies vs. bigger companies. As a result, they are often more custom and built on existing relationships.

– As these roles are more common in smaller companies, they often come with limited mentorship/coaching that can cause problems down the line.

iv) Starting a company (10%):

Why it works: While the product manager is the “CEO of the product” trope gets old very quickly, there are many aspects of the PM role that are similar to building a company – especially one that is trying to find product market fit or scale beyond a niche set of users.

Who it works for: Startup founders/CEOs who either get acquired, acqui-hired, or look for jobs after winding down their startups.

Why it doesn’t work: As you can imagine, this definitely not a recommended path into product management as this shouldn’t be a reason to start a company. But, it is a path in nevertheless.

The purpose of today’s post was to provide a lay of the land as you consider product management as a possible career while also providing an overview of the common paths in.

Next week, we’ll look at the process of preparing for that first set of interviews as well as examine 5 practices that I’ve found to be helpful in breaking into that first PM job.

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.

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.

The Culture of the Product team

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 –

A valued member of our product team recently shared they’re leaving. The logic was sound – an interesting career pivot opportunity came up and the timing felt right.

While I was happy for this teammate, I was sad for me.

When you work at a large organization, goodbyes are a natural part of life. For the most part, you smile, wish the person good luck, and go your respective ways. On occasion, the goodbye is accompanied by relief (often for both folks involved :-)). And, every once a while, you find yourself experiencing a jolt of sadness when you hear the news.

Those jolts of sadness are important moments as they signal how special that relationship/person was to you. And, as I was reflecting on what made this relationship special, I realized it came down to how I think about the culture of a product team.

The culture of a product team

Culture is the set of shared attitudes, values, and behavior of a team. It shows up in the decisions a team makes on behalf of the user/customer and the organization. It also shows up in daily conversation in refrains that implicitly say – “This is how we do things here.”

Every team has a culture. This culture, by definition, is different from the culture of the company because the culture of a team is most driven by the people and processes on the team. While companies with strong cultures can have a high degree of uniformity in decision making process and the kinds of people they hire, the influence is, at best, loose at the level of an individual team. The people in the team and the leaders on it determine the culture.

No alt text provided for this image

If culture determines how decisions are made, the team’s culture becomes the team’s strategy in the long run. So, thinking intentionally about the product team’s culture is among the most powerful levers we have as an individual contributor PM or IC PM.

How can an IC PM impact the culture of the team?

Let’s start with the obvious – there is no way an IC PM can walk into a team and make a proclamation on the team’s culture. :-) This is less about talking and more about doing. And, there are 3 things we can do to help influence the culture of our product team:

(1) Figure out the top 3-4 behaviors we desire in our product team – bonus points for articulating them in a way that sticks (e.g. “It is still day 0 at Amazon”)

(2) Set the right example by embodying these behaviors – bonus points for adopting a few quirks that draw attention to these behaviors

(3) Hire and celebrate members of the team who embody these behaviors and thus become ambassadors of the culture – bonus points for telling stories about these behaviors that are retold.

No alt text provided for this image

As ideas like this are easier to digest with examples, I thought I’d share how I attempt to implement these in my day-to-day.

One IC PM’s culture-shaping process

The 3 behaviors I’ve come to desire on a product team are:

(a) High velocity data-informed experimentation: 

A product team’s velocity is its super power. 3 quirks/obsessions that drive home this behavior –

(i) Problem statements: Velocity is different from speed because velocity also includes direction. We set the direction on the team with the problem statements we articulate. No project starts without every member of the team understanding what problem we’re attempting to solve.

(ii) A focus on experiments/ramps: We spend a lot of time discussing experiments, holding ourselves accountable around ETAs, analyzing results, and celebrating iterations. Very few of these experiments actually hit gold – but, with some thoughtfulness and a focus on rapid iterations, we drastically improve our odds

(iii) Team diligence on operational metrics (email/dashboards): We do our best to create daily email reports and/or dashboards that are sent to the team. And, we use these daily email reports and/or dashboards to ask questions and understand what is going on. A simple rule – whenever there is variance (week-on-week or year-on-year), it is always worth understanding what happened.

(b) Deep cross-functional collaboration:

The two biggest drivers of deep cross-functional collaboration are psychological safety and shared/aligned context – this section focuses on the latter. 3 quirks/obsessions that drive home the point:

(i) Making peace with/welcoming large meetings: Most meaningful projects involve large cross-functional product teams.

No alt text provided for this image

I’ve learnt that there is no chance of accomplishing deep cross functional collaboration if members of the team don’t feel they’re part of the journey. And, ensuring that happens means making peace with (and even getting good at managing) large meetings.

A key lesson around meeting size is that the decision is binary. Either choose a small and efficient meeting where you prevent the meeting invite from being forwarded (and possibly annoy a few people). Or, set the topic and agenda and don’t worry about the size. It may feel less efficient at first – but, the shared context generally leads to higher long term effectiveness.

(ii) Responsiveness on email/Slack/Teams to avoid communication bottlenecks: In organizations where the Product Manager has the privilege to be the hub of the product team, responsiveness goes a long way in ensuring others have the context they need to operate effectively.

I don’t recommend taking this to extremes as it means you’ll never find the time to focus. But, if team members know to expect they’ll hear back on questions and also know how to reach you when they need to get unblocked, it helps.

(iii) Emphasis on planning and documentation: This is another behavior that is key to everyone having shared context. The better the documentation, the more independently everyone operates.

Second, as we work on a larger and more ambiguous product areas, it is likely we’ll have to deal with plenty of conflict and disagreement in the product development process. There’s no getting away from it – especially in organizations with teams with different incentives.

In such situations, habitually starting with a document helps us quickly get to the source of the disagreement (e.g. do we disagree on the problem statement, hypothesis, or success metrics?) and move the discussion to productive conflict and alignment faster.

No alt text provided for this image

(c) Small things done with extraordinary care:

I first heard this idea a few years ago – “You can’t always do big things. But, you can do small things with extraordinary love.” It was love at first sight.

This “extraordinary care” idea isn’t easy to embody but here are 3 quirks/obsessions that attempt to do so:

(1) Invest in getting to know every member of the team: I do my best to start every collaboration with a 1×1 conversation where the only agenda is getting to know the other person. As part of this, I ask 3 questions – (i) Would love to know your story starting from where you were born to now (typically gets a laugh), (ii) What do you do when you have free time?, (iii) What is the dream?

It is amazing how much we learn about people from just one such conversation. More often than not, we just realize that we work with fascinating humans – and that we’d never have known if we hadn’t dug deeper.

(2) Collecting and responding to feedback: We aim to have at least one feedback conversation every few weeks. This is done casually – e.g. just a question in a stand-up about how everyone is feeling. Every one of these conversations tends to result in some pointed feedback that I/we aim to respond to immediately. The more folks understand they’re being heard, the more feedback I/we get, and the better we learn to operate.

(3) Appreciation: The lesson I’ve learnt around appreciation is that it is far more effective when it happens naturally. I’ve seen and attempted versions of “kudos” during regular meetings – but, somehow, forced appreciation doesn’t work anywhere as nicely as when we just learn to notice when folks do something good and ensure they’re celebrated for what they did. Frequently.

The quirks and notes above are all manifestations of my personality and what I care about. However, the core principle underneath it all is that it is important to be intentional about the cultural norms and behaviors we inspire. Culture is always being created – so, it is on us to consciously create one that we desire.

Now, of course, the above notes are all about actions we can take to shape culture. However, the far more effective method of shaping the culture of a group is by finding ambassadors who consistently demonstrate the behaviors we desire. If we find members in the group who exhibit some or all the behavior, we can both celebrate them and tell their stories. Doing so helps the rest of the group take inspiration from “how things are done here.”

Every once a while, we might even find ourselves fortunate to work with a “bar raiser.” Such a person doesn’t just exhibit the behaviors we desire, they do it in a way that raises the bar for everyone else – including us.

This was why the goodbye I mentioned at the start of this note was particularly painful. When I started working on a new set of products 9 months ago, I was blown away by this team member’s velocity, desire to collaborate and learn, and depth of care for all the small details. My time on this team promised to inspire me to set the bar higher for the culture of the team and also learn plenty along the way.

It lived up to its promise.

That, in turn, is the most amazing thing about being a student of culture. As it is a set of aspirational behaviors, we keep meeting people over the years whose behavior helps us better articulate what we desire and show us how we can set the bar higher. No matter their current title, these folks are the true leaders of any team. They lead by setting high standards and expect everyone else to follow – often by believing more in them than they do in themselves.

Working with someone who relentlessly raises the bar is often painful at first – especially if we’re one of those who needs to shape up. It might even seem as if it isn’t paying off for the longest time.

Until it does… big time.

Five frameworks/heuristics for higher quality decision making

A note for new subscribers: This post is part of a monthly 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 –

A product manager brings a team of cross functional stakeholders together to build products that are valuable, usable, and feasible.

In past notes, we’ve spent time on the 4 core skills that help us achieve these outcomes – problem finding (the most important), sellingproblem solving, and building effective teams.

Our abilities in each of these 4 skills shows up in the quality of decision making we enable in our teams and organizations. And, that decision making quality is at the heart of the value we bring.

Typically, high quality decision making shows up in two important ways –

1) A track record of products that users/customers find valuable (and maybe even love)

2) A consistent ability to build high performing product teams that are happy and motivated (and maybe even inspired)

In sum, a simple way to think about our value as a product manager to our organization is to ask – what is the quality of the decision making I help facilitate?

The word “facilitate” is an important one because it isn’t just about the decisions we make. A big part of the job is facilitating high quality decision making within our cross-functional teams and in our organizations more broadly. That can only happen if we’re able to consistently bring clarity to the problems we attempt to solve. And, today’s post is going to be about decision making clarity.

Decisions – Existential and Reversible.

Jeff Bezos once shared that he approaches decisions based on how they show up across 2 axes –

    1. How existential/important is it?
    2. How reversible is it?

Using this framework, here’s how IC PMs typically fit in..

No alt text provided for this image

It is rare (maybe even disfunctional) for an IC PM in any organization to make decisions that threaten the existence of the company. That is what the C-Suite were hired to do. In the rare cases where we’re involved in reversible but existential bets, our role typically lies in helping craft the strategy and the reason for the bet.

Existential decisions aside, we do often make decisions that are hard to reverse – typically as a result of the effect our decisions have on product or technical architecture. Aside from ensuring we’re giving difficult-to-reverse decisions due consideration, our role is often to identify them and provide clarity on the trade-offs to the relevant executives who can then make the right decision with appropriate context.

That leaves us with decisions that are neither existential nor irreversible. While that sounds innocuous, the truth is that these decisions make or break the product. Even if each of these decisions may be small in impact, these are large in volume and have compound effects on the quality of the product.

Here, I’d argue that the single most important ingredient to getting to high quality decisions is a combination of high speed decision making combined with reflection.

And, a key enabler of high speed decision making is a set of frameworks/heuristics that help us both clarify our thought process and help us communicate/facilitate appropriate action. Here are five decision making heuristics I have found most useful.

(1) Start every meeting and every discussion about building product with the Fundamentals (Problem Statement -> Success Metrics)

That I am starting here should come as a surprise to no one who has been reading these notes. Everything begins with the problem statement. Clarifying the problem statement, hypotheses, and success metrics at the start of every meeting, strategy doc, and spec alone will step change the quality of our products and discussions.

No alt text provided for this image

I was reminded of this recently when I nearly derailed a meeting by making assumptions about what we were solving and took us down the wrong path. Luckily, a couple of others reminded me to go back to the problem we were solving. And, before we knew it, we were moving quickly toward a far better solution.

The power of the fundamentals is that they help us cut through the noise to focus on solving problems and driving outcomes for our users/customers.

(2) When faced with a strategy question, map the trade-offs into a 2×2 chart

A 2×2 chart is a simple chart with two important decision criteria in the X and Y axes. Just as we looked the existential vs. reversible decisions in a 2×2 above, there are many classic 2x2s – e.g. urgency vs. impact, breadth vs. depth, metrics vs. mission, scale vs. type of problem, etc.

2x2s can also be extra versatile by enabling you to capture up to 4 criteria when you add in the size and color of the bubbles (example below). You can also extend this optionally to 3x2s depending on the nature of the problem being discussed.

No alt text provided for this image

We often need to make facilitate discussions on key strategic decisions that involve trade-offs. Every time we attempt to have a conversation about trade-offs, we’ll likely be able to have a higher quality conversation if we mapped the trade-offs into a 2×2.

(3) Let every discussion on roadmap priorities be grounded by the funnel/equation

No matter what product you work on, there likely is a funnel or equation that maps what you drive to outcomes that matters. Here are 2 simple examples:

No alt text provided for this image

Mapping this funnel/equation or its equivalent helps us have 2 kinds of conversations –

    1. Where is the bottleneck?: There’s always one bottleneck that can help deliver a 10x improvement versus others where the potential may just be incremental. Understanding this helps us focus.
    2. Where can we simplify?/what can we clarify?: For consumer products, simplicity and clarity result in better outcomes. Internalizing our funnels helps us create products with intuitive defaults, fewer steps/unhelpful choices, and clearer copy.

(4) Become more effective at collaborating by accelerating the process “Know -> Understand -> Trust or mistrust”

In most organizations, trust is the single biggest determinant of a team’s speed. The trust between the executives involved determine how quickly organization level misalignments are resolved. Then, the trust between and within the working teams determine how quickly all the small/daily issues are resolved.

While there’s little we might be able to control in terms of executive relationships, we have plenty of daily influence on the relationship between and within the working teams.

So, what is trust and how do we get more of it?: The best definition I’ve come across for trust is – “trust is choosing to make something important to you vulnerable to the actions of someone else.”

We are trusted by others when they choose to make themselves vulnerable to our actions. In teams we are part of, this happens when our teammates share sensitive information, express thoughts and emotions that matter to them, and/or leave decisions in our hands. And, we earn or lose this trust by virtue of how carefully or carelessly we deal with what they’ve placed in our care.

While there’s no replacement to being worthy of this trust in the long term, there is one way to speed up the process of building trust. Invest in getting to know the folks you work with closely.

Once we know someone, it becomes easier to understand them based on their actions. As we have some context as to what makes them tick, it becomes easier to understand why they do what they do and how they make decisions.

And, assuming their approach is aligned with how we approach key decisions, we arrive at trust… or, if not, mistrust (let’s face it – it doesn’t always work out). Either way, the faster we get to understanding the nature of the relationship, the better we can operate.

No alt text provided for this image

And, we can get there by spending 30′ at the start of a project to do an introduction with everyone we will work with. Here are 3 questions I ask (as an example) –

    • I’d love to get to know your story. Where were you born and what happened between then and this conversation? :-)
    • What do you like to do in your free time?
    • What is the dream?

As simple as this introduction process sounds, I can’t begin to explain the number of times I’ve run into trouble because I’ve skipped it – consciously or unconsciously – in the interest of moving quickly.

(5) Visualize the Peer NPS question and ask the two leading indicator questions to become a collaborator who is worthy of trust

As we work on building products, we often work with peers – fellow Product Managers on other teams and cross-functional partners. One of the questions I visualize asking these peers at the end of the project is the NPS questions – “How likely is it that you would recommend working with me to your peers?”

It becomes evident at the end of a project if we’ve left it with folks who are detractors, neutral, or promoters. The more the promoters, the better our reputation. The better our reputation, the easier it is for us to be effective in future projects because other collaborators start by assuming trust and good intent.

But, while asking the question at the end of the quarter is useful, it is more useful to look for leading indicators while we’re in the midst of execution. Outside of making good decisions as a product manager, there are 2 questions that tend to be good leading indicators of our ability to be good collaborators –

    1. Am I persuading my peers based on the merits of the argument? (vs. “I have decision making authority here” or “Executive X wants it done this way”)
    2. Am I going up my peer’s chain of command in my attempts to make progress and doing so without her/his knowledge or presence?

Checking in often on these two questions help us do two things at once. First, they help prevent honest mistakes. And, second, they help us operate in a way that makes us worthy of trust… and respect.