Learning to sell as a product manager

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 – 

Before starting this series, I spent a bit of time thinking about how I should articulate the core skills required to be a strong IC/individual contributor product manager. I had 3 criteria –

  1. Clear/mutually exclusive: I wanted skills that would stand on their own and, for the sake of this series, wanted to avoid umbrella words that spoke to multiple sub-skills (e.g. empathy)
  2. Memorable: This implied committing to no more than 3 or 4 skills to ensure they’re easy to remember
  3. Actionable: This meant choosing “problem finding” vs. “product sense” because of the action it implies.

Soon, problem findingproblem solvingbuilding effective teams felt right and were locked in. But, I debated whether to call the final skill influencing or selling.

I chose selling because it felt a bit uncomfortable. I wanted to reach into that discomfort and spend time there. In the first post on selling, we framed the persuasion process as a combination of Direct Marketing (content led) and Sales (human touch led) – surrounded by Brand marketing (the friction in the process is inversely proportional to our brand/reputation).

No alt text provided for this image

The next post focused on our biggest direct marketing lever – writing. Many subsequent posts have either focused or touched on writing – e.g. the ones on product specs and product strategy.  

Today’s post will be focused on the other side – sales.

Why does the word “selling” make us uncomfortable?

I think there are many reasons. When we think of sales, many of us visualize pushy sales people who try to get us to buy something we don’t want. For some of us, it may even bring back memories of Alec Baldwin in Glengarry Glen Ross unleashing a torrent of verbal abuse on 4 salesmen while emphasizing the ABC of Sales – “Always Be Closing.”

No alt text provided for this image

No wonder sales feel uncomfortable.

To Sell is Human and the new ABCs of Selling

I felt similarly until I read Dan Pink’s book – “To Sell is Human.” Dan’s book transformed my perspective. He reframed selling by pointing to a simple idea – if you need to influence people as part of your job, you are in sales. 

He also reframed the ABCs of selling. Two decades ago, the internet didn’t exist. This meant there was large information asymmetry between buyers and sellers. And, as online ratings/reviews didn’t exist, selling felt like a series of one-time transactions. Both of those aren’t true today. We walk into a car dealership with as much information as our dealer. And, the dealer cares about that Yelp review we leave. 

That then brings us to the new ABC’s of selling – AttunementBuoyancy, and Clarity. For the rest of the post, I’m going to translate how I think we can use the new ABC’s to reflect on and improve our sales skills in our role as Product Managers. 

If you haven’t read the book, I’d recommend it. Here’s a quick visual summary in case that helps – hat tip – Jenny Trautman.

No alt text provided for this image

(1) Attunement:

Key question: Are we building trust in our relationships by seeking to understand?

No alt text provided for this image

Attunement is all about empathizing with others. Our ability to be attuned to a person follows from our willingness to get to know and understand them. The biggest implication is the importance of taking the time to get to know our partners. My approach to this has been to aim to start every relationship with an introductory 1:1 before jumping into ask/work.

Knowing the story of that cross-functional partner helps us understand them as we begin working with them. That understanding leads to trust in most cases (in other cases, it leads to mistrust – either way, it is important to know where we stand. :-)). That trust, in turn, helps us prioritize uncomfortable conversations and to be comfortable when we disagree. Uncomfortable conversations and disagreements are pre-requisites to progress.

Outside of cross-functional partners, the previous post on building relationships with Product Executives attempts to provide more structure on building empathy with our product leaders.

(2) Buoyancy

Key question: Do people walk away with more positive energy after spending time with us? 

Implications for us: In every interaction, we exude one of 4 behaviors. We are either –

  • Condescending – expressing superiority
  • Critical – showcasing disapproval or criticism
  • Constructive – building off existing ideas to make them better
  • Proactive – moving things forward and making them happen

Each of these impact everyone’s energy differently depending on where they are in the process. In general though, the impact looks like this.

No alt text provided for this image

The ability to show up with positive energy regardless of the way the winds are blowing is critical to our ability to influence the people we work with. So, learning to be consistently constructive or proactive makes a huge difference to our ability to influence others. 

It is important to call out that these are behaviors and not character traits. They become traits only when we consistently show up in one way. So, it is in our interest to choose and reflect periodically on whether we’re showing up as we intend. It won’t always work. Despite our best intentions, our intentions will occasionally be misinterpreted – especially when we meet with people who don’t know us. The goal is to keep increasing our ratio of hits to misses.

 The interesting thing about these emotions is that they’re as applicable to others as they are to us. For example –

  • How do we feel when we spend time with ourselves?
  • Are we critical every time we think of a new idea or are we constructive and solution focused?
  • How does this change when we’re going through a difficult time?

That, then, is the true test of our buoyancy – how we feel after we spend time about ourselves. The more we walk away feeling positive after spending time with ourselves, the more likely others will feel the same. 

(3) Clarity

Key question: Do we transform situations from ambiguity and chaos to clarity?

Attunement is about empathizing with our audience. This audience may be internal (our organization) or external (our users/customers). Buoyancy ensures we show up positively. Clarity, however, is the clincher – the key pre-requisite to closing the sale.

Everyone is dealing with more information and ambiguity than they know what to do with. So, the ability to consistently step into ambiguity and transform it into clarity is a core skill.

Transforming ambiguity to clarity is a 2 step process –

No alt text provided for this image
  1. Frame: A complex set of information needs an organizing structure or framework. The best ways to learn how to frame is to spend time with people who are structured and read books or articles by people who are good at what they do. The ability to simplify complex information is a sign of skill. This post, for example, is an ode to Dan Pink’s ability to reframe sales as attunement, buoyancy, and clarity. The other way to teach ourselves to frame is to constantly ask – if I had to boil this topic down into no more than 3 things, what would I say?
  2. Decide to simplify: Once you structure information, the next step is to decide what matters. The word decide comes from the Latin word “decidere” which means “to cut off.” The purpose of making a decision is to cut off options. So, when we decide what matters, we automatically simplify.

Attunement, buoyancy, and clarity, are each powerful in their own right. Attunement or empathy, for instance, is just as important in our ability to be good problem finders or problem solvers or even team builders as it is in our ability to sell. Buoyancy and clarity matter across the board too. 

But, when we’re able to bring these three together consistently, we step-change our ability to sell. While sales is important to our jobs as individual contributor PMs, it becomes more important as we evolve our role from individual contributors to leading teams of product managers.  

The good news is that selling is a skill. It is a muscle we all can get better at if we work on attunement, buoyancy, and clarity. 

And, the good news – channeling Dan Pink – is that to sell is human.

Two levels

Great Pixar/Disney movies operate at two levels. The story, characters, and visuals works for the kids. The humor in the dialogues works for the parents.

They need to do the job on both levels because young kids need their parents around to watch these movies and enthusiastically accompany them to the amusement parks.

Great products work the same way. They are simple enough for the newbie user but have layers of complexity that get the job done for the more advanced user.

It is easy for a product to work on one of the two levels. But, the challenge is to work on both levels while preserving the simplicity.

It is why building simple products is anything but simple.

Building relationships with Product Executives

A note for new subscribers: This post is part of a series on my notes on technology product management (this is what I do for a living). You might notice that these posts often link to older posts in the series on LinkedIn even though they are all available on this blog. That is intended for folks who only want to follow future product management related posts. Finally, for all those of you who don’t build tech products for a living, I believe many of these notes have broader applicability. And, I hope you find that to be the case as well…

A quick overview of what we’ve covered on “Notes on Product Management” so far – 

“How can I better influence my product executives to fund my projects?”

“How can I better communicate the impact I drive to <insert product executive>?”

“How do I build a strong relationship with <insert product executive>?”

Variants of these questions are common in conversations among product managers. If you were an alien listening in on some of these questions or conversations, you might be forgiven if you thought product executives are creatures from a different planet – full of mystery and intrigue. After all, you’re likely to hear some story about said person’s super human abilities in this or that.

The good news is that we’re not dealing with extra-terrestrial creatures. Every executive – product or not – is human. Just like us, they have goals, areas of strength, growth opportunities, insecurities, and fears. Most are good at keeping calm above the surface. But, like the proverbial duck, they’re all paddling hard underneath.

No alt text provided for this image

(H/T: Leslie Gail for this image) 

PM careers and scope

The PM career journey involves some dramatic jumps in scope as folks get more senior. 

You start with a narrow focus on features and products as an IC. This grows to product areas for senior ICs/people managers. While this jump is significant, it doesn’t compare with the jump from senior people manager (typically a Director or Senior Director) to an Executive. PM Executives typically lead entire marketplaces or ecosystems as product executives. And, in many companies, they may even go from leading a group of PMs to being a “General Manager” of a business with multiple functions reporting into them.

No alt text provided for this image

No matter their title, they’ll continue to be responsible for the pixels you ship. So, it still matters that you have their buy in on your vision. It is important that they’re excited about the work you’re doing. And, they will continue to play a critical role in your ongoing career progress.

But, given their scope, building relationships with PM executives isn’t easy. Their broad responsibilities mean time is at a premium. And, asking them for frequent 1:1s or throwing out the “will you be my mentor” question isn’t the answer.

Strong relationships and contribution

Building strong relationships with product executives is no different than other relationships. They’re built on understanding and trust, and are sustained by contribution to each other’s growth.

The difference in these relationships is that we don’t generally have the time to spend hours working with each other to build the relationship. And, without that understanding, it is often hard to know how best to contribute. In the absence of us doing so, these relationships become one-way – we get (hopefully useful) feedback that helps us and our products get better. But, as with any one-way relationship, it ends up feeling more like a series of transactions than an actual relationship.

While every product executive is unique, there are some certainties (thank heavens). And, these certainties come in the shape of what matters to them – and thus areas we can contribute. I think of these in 4 categories:

  1. Impact (this is foundational)
  2. How you achieve this impact – in a way that is aligned with their product vision/principles/culture
  3. Team/org growth and happiness
  4. Their growth
No alt text provided for this image

These categories are stack ranked in default order of priority. But, their relative importance will vary based on the executive. Let’s dig into these.

(1) Impact

Most product executives are judged on outcomes. The primary outcome they’re measured on is typically revenue. In rare cases, it is a key driver to revenue – e.g. some user/customer value metric or engagement that contributes to Revenue.

Depending on how the team is structured, various PM managers and their IC/individual contributor PM reports will be accountable for outcomes that contribute to the executive’s outcome. Understanding our executive’s outcome, how our work contributes, and actually contributing to it is the minimum bar. 

We move past the minimum bar when we’re able to earn trust in our capabilities. That happens when we add being competent with being responsive to their questions/concerns and staying on top of the details/trade-offs. Trade-offs matter a lot as a product executive because their ultimate responsibility isn’t the success of their business unit – it is the success of the company. 

So, the more we’re able to do our job with their lens on the objective that matter, the more trust we’ll be able to earn.

(2) How we achieve that impact – the culture of the product organization

Product executives have very different styles. The 4 common areas they tend to index on (roughly mapped to our 4 core skills is):

No alt text provided for this image

(a) System/strategy/metrics (problem finding): Some product executives are strong system thinkers. They care about how the various pieces connect to the whole and how each team’s strategy and incentives are set up.

Practically, these executives check if – (a) you are measuring the right things, (b) you understand the levers to achieve your metrics, and (c) you are focused on the right problems to move those levers.

(b) Product experience (problem solving): This brand of product executive is all about the end user experience. They will go very deep on your understanding of the specific user problem, your hypotheses and validation for those hypotheses, and how it all shows up on the screens you ship. They will want to understand the thought process behind every pixel on the screen. No detail or line of copy is small enough to not warrant discussion.

(c) Communication (selling): This variant of product executive pays a lot of attention to how PMs communicate. While most folks associate communication with verbal communication, the typical form of communication they pay attention to is written. They care about a regular cadence of weekly updates in an agreed upon format, crisp documents that bring trade-offs and decisions to light, and strong email communication.

(d) People/stakeholder management (team): This final variant indexes deeply on alignment. They care that every stakeholder is rowing in the same direction and will check for that whenever they meet you or the other cross-functional leads on the product team.

Typically, product executives will index deeply in 2 out of these 4 areas. A rare executive may index on 3. I think meeting folks who index highly on all 4 is rare/unlikely. That said, the one thing that is common – regardless of style – is their desire for urgency.

What does this mean for an IC PM? Get to know your product executive. Learn their story and speak to folks who’ve worked with them in the past. They are typically not shy about sharing what they care about. You will also see it in the systems/processes they set up and the questions they ask. Once you understand their desired culture, be the change they want to see. 

(3) Team growth and happiness

Product executives are responsible for the well-being of the team. With their focus on the health of the business, this tends to be an area that they’ll have to carve out time that doesn’t exist on their calendars. This tends to be an easy area for IC PMs to have disproportionate impact – both on the executive but also, more importantly, on the organization. 

Broadly, you can think of the following areas to contribute toward the growth and well-being of the team.

  • Hiring – especially hiring diverse talent
  • Onboarding – or setting new PMs up for success
  • Learning – includes sharing know-how insights/regularly or contributing to training
  • Belonging – team socials and offsites
  • Norms – documenting/setting culture and values (these don’t happen often but can be very high impact)
No alt text provided for this image

Every one of these is an area PMs can contribute toward. I have learnt 3 lessons about these contributions: 

(i) You will never have spare time to execute on one of these areas. It is important to start here. You will have to carve out the time or find time beyond your normal hours to do it well.

(ii) Don’t try to be “strategic” – pick an area you are passionate about. Given you’ll never have spare time, it is thus important to not try to be “strategic” – i.e. picking an area that your Chief Product Officer or your VP works on.

You may make an exception to this from time to time depending on he need. But, you are better off focusing on what you care about – an area where making an contribution to the people in the organization energizes you. It will show in how you execute because it will feel like fun. You’ll run out of steam faster on things you don’t care about.

Besides, product executives change. They move on to different focus areas or teams/businesses. So, doing these with the sole objective of building a strong executive relationship typically backfires. 

(iii) Doing a good job on these “side projects” can have a disproportionate impact on your organization. Each of these areas can have a large impact on the culture, growth, and well-being of PMs in the organization. So, if you’re doing it right, you’re having a lot of fun while also having a tangible impact on the work lives of your coworkers.

(4) Their growth. Product executives don’t get to where they are by sitting on their achievements. Folks who do well will be focused on their growth. While they’ll rightfully look to their managers/other executives in the company to give them feedback, don’t underestimate the importance of providing useful feedback.

Useful feedback is thoughtful, constructive, and direct. 

Great relationships are built on a two-way flow of feedback. Ask them for feedback proactively. And, give them feedback too.

It isn’t easy to provide feedback to product leaders. Our interactions with them have disproportionate impact on our career growth. So, it is easy to not do this. But, it helps to remember that product executives rarely meet people who have the courage to tell them things they don’t want to hear. So, if you can be the person who speaks the truth and offers solution – without whining! – it can go a long way.

We started this note attempting to tackle building relationships with product executives. As with all relationships, chemistry matters. It is possible that you’ll just “click” with your product executive. Relationships can work like that. We’re all bags of emotion and irrationality after all. 

But, the goal of this is go beyond the chemistry and work through areas where we can have a positive impact on the organization and, by extension, our leaders.

While we’re at it, it is important to also share a disclaimer. If you do succeed in building a strong relationship with a product leader, use it carefully. Every once a while, you’ll meet PMs who do a phenomenal job building great relationships with product executives but struggle with earning the respect of their peers.

That happens because of one or both of these –

(1) “Name dropping” executives from time to time.

(2) Using product executive names/directives to influence peers – instead of the merits of the argument.

Both of these can happen in conversation or by forwarding emails to others that show off their relationships.

So, by all means, go ahead and build great relationships with your product executives. I hope it works out for you. And, in addition, as in Albus Dumbledore’s note to Harry Potter when he handed him his invisibility cloak, I’ll just say – “Use it well.” 

Product problems and business goals

The most common derailer I’ve observed in product management interviews is when candidates start discussing a product problem by dissecting business goals. This derails the conversation 80% of the time.

Business goals matter – but only after we have conviction that there is a real user problem to be solved. Starting with business goals distracts from the process of problem finding.

This is just as relevant on the job.

Good specs start with problem statements. And, good problem statements start with user needs and validation that the need is real – typically either user frustration or creative hacks/workarounds – before they get to business value projections/guesses.

We’re better served when we think of the “P” in PM as “problem” vs. “product.”

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.