While everyone in my LinkedIn feed obsesses over identifying new opportunities and building new solutions, there is something that holds back most of the product managers: stuff that failed.

Here is 5 types of failed stuff that you may need to deal with as a PM:

1. [Obsolete] Feature/product that became irrelevant, because the problem became irrelevant

2. [Non-Viable] Feature/product that never was relevant, because the problem it solves never existed

3. [Just Bad] Feature/product that never was relevant, because it didn’t solve the problem

4. [Looser] Feature/product unused because of a better alternative or competitive solution

5. [Castaway] Feature/product that don’t fit your company strategy anymore

These product/market misfits are the zombies that haunt PM who inherited them.

Why should you even care?

You might not even realize yet, but if you own any kind of zombie product, they drain your and your team's resources. In the best case there is no active users left, and your only expense if the cost of infrastructure. In the worst case, there is a bunch of active and angry users, who either have no alternative or for some reason are loyal to your little zombie despite all the negligence from the product team. They want more features and bug fixes, but you have no budget for that. You'll have to manage escalations, triage bugs, and maintain the infrastructure. It will exhaust and slow down the whole team.

What should you do?

Sell it

In the real world, Looser and Castaway zombie products can be sold, if there is an existing active user base, or unique tech. For internal PMs, things are more complicated. Finding an organization with overlapping interests is possible, but teams often operate on tight budgets. Unless the product has unique technology, data, or solves the exact same problem that the other org wants to solve, it will be hard to convince anyone to acquire it.

Furthermore, consider developer morale. Most engineers I worked with want to build new, meaningful things and aren't interested in taking over old products. If the leadership tells them to take over a tech product from another team, but they might end up rewriting it from scratch. This kind of organizational behavior isn’t uncommon, because usually speed matters and rewarded more, so the Not invented here syndrome kicks in.

Revive it

You can try to build another business case and try to revive a zombie. Unless you happen to have the right data and anecdotes to convince the leadership to invest in the revival, you first need to invest a ton of valuable PM hours to conduct a discovery for an opportunity that is forgotten and/or abandoned by your leadership. Usually though, internal PMs have a lot of other things on the radar, which ARE important for the leadership, that can’t be screwed up.

Kill it

Killing zombie products is often the best solution, it’s also romantisized with a term product “sunsetting”. Sunsetting Obsolete, Non-viable and Bad products is likely a matter of shutting down the infrastructure and deprecating the code.

Looser and Castaway products might have thousands of users with critical jobs to be done depending on them.

Close signups

If you haven’t done so yet, remove the option to signup.

For internal products, creating a self-service or manager approval permission group requiring a business justification to continue using the product. This way, you have more control over the user base and a better understanding of the processes that depend on your tool. This strategy is pretty brutal but effective.

Give the users bad news well in advance

Remember that they still wait for you to fix the bugs, so this news will not be perceived well. You need to rip off the band aid. Give them long enough notice period to allow to go through all the stages of loss, and to prepare. Increase the cadence of communication proportionally to the remaining product lifetime.

Invest in offboarding

Make sure you create solid means to offboard, such as data export or possibly a migration to an alternative solution if it exists. This comes with the engineering cost, so make sure you align it with the leadership, your development partner and consider in the plan.

To recap:

1. Zombie products are active products that the company no longer wishes to invest in.

2. These products drain the product team's energy and bandwidth.

3. There are three ways to deal with them: 1) transfer ownership; 2) revive; 3) kill.

4. Although killing the product is often the best option, it should be done carefully. Over-communicate and provide a clear way out for the users.

🙋‍♂️Pssst I need your help!

I’m doing a little research on correlation between creating content on professional topics with on the job performance.

Please take this 2 minute survey and immediately improve your karma. I will share my findings in one of the future Product Math posts.

Why?

I got this question A LOT when I decided to move from SDM (Software Development Manager) to PMT (Product Manager - Tech). SDM at Amazon even at mid levels, is a senior and well respected role regardless of which org you’re in. So people were dazzled when I told them about my transition.

It turned out, that I love product management. There was no sudden realization; rather, it took some introspection to figure out where I wanted to go professionally. Looking back, there were several clues pointing me towards the product space that I ignored at the time. While these clues are personal and anecdotal, I hope they inspire others to be intentional about their career and pay attention to their own unique set of clues.

The Clues

Clue №1: Web design hustler

While studying applied maths and computer science, I continued to provide freelance webdesign services, that I started while I was in high school. What was interesting, is that even when taking up a full stack website gig, I would rarely be interested in the “engineering” aspects (in quotes because the extent of engineering was limited to customizing WordPress themes). While I enjoyed communicating with my customers, focusing on their needs, and genuinely enjoying the UX and webdesign craft, I always outsourced the tech to someone else.

Clue №2: Amazon Hiring Exersize

During the recruitment process for the SDM role at Amazon, I was given a written exercise where I had to describe the most innovative thing I had done. I shared a story about a product problem that I solved in my previous job as an engineering manager, which didn't necessarily showcase my leadership abilities. You may ask why did I solve product problems as an engineering manager — the role was quite fluid and autonomous.

Despite this, the hiring manager continued with the interview process. Interestingly enough, the same person later mentored me and suggested that I move into a product space. But I was pretty stubborn on my mission to become an awesome engineering leader.

Clue №3: Self Discovery before Product Discovery

Once around Christmas time, when I was already an SDM, I created a summary of my professional results and activities for the past year in a document, as we have a document for everything at Amazon. One of my reflection points was to identify the type of work I enjoy doing the most. I discovered that 75% of my statements were related to solving customer problems, creating wireframes for solutions, and strategic product thinking. One of the leaders in my org said that I was trying to force a square into a circle, but I continued my journey as an SDM.

Clue №4: Product Glow Up

A year prior to switching roles, I confided in my manager about my doubts and desire to transition to the product side. He understood my perspective and assured me that there are various styles of SDMs, some technical and others product-oriented, and that both are acceptable. Although he convinced me to remain in my current role, I realized that using it as an outlet for my personal interests without being held responsible was not a sustainable model.

Key Contrasting Points

The two roles have significant differences. Previously, I had 10 engineers who directly reported to me. Now, I have an equal number of customers and stakeholders who are obviously not under my direct supervision. Additionally, there are 2,000 internal Amazon users of the product I oversee.

💁‍♂️ Influencing with new authority

As a Software Development Manager (SDM), I occasionally used my authority when necessary. After transitioning to an individual contributor (IC) Product Manager - Tech (PM) role, I realized that I had unconsciously relied on my authority as a people manager. This power is granted to you by default with people management responsibilities, and it's an invisible superpower.

As a PM, you'll need to influence and build trust with customers, stakeholders, leadership, and engineers, even if they don't report directly to you. I believe it's impossible to influence without authority, but instead of relying on hierarchical power, you can gradually demonstrate your traditional and charismatic authority (see Weber's types) and establish yourself as an expert in the business area, customer issues, and technology.

⏱️ Managing your time and saying No.

Transitioning from a manager to an individual contributor required me to manage my time differently. As a people manager, I developed a set of controls, such as "trust but verify," to prevent mistakes and stay on top of deliverables and commitments. In contrast, as an individual contributor, I must manage my own time and deliverables, and delegation works differently.

Often, PM serves as the interface between other teams and organizations and the product team. As a PM, I receive numerous questions, inquiries, ideas, and problems daily. To maintain my sanity and focus on the most important tasks, I need a structure and relentless prioritization. If my top priority for the week is a long-term vision document for my product, I must decline many calendar invites and emails. Being able to say no politely, provide justification, and suggest the next steps is essential in this role.

❤️‍🔥 Empathy is still your main tool.

According to James Hunter's book, "The World's Most Powerful Leadership Principle," as a people manager and servant leader, it is important to love your direct reports, but not necessarily like them. The same principle applies to customers and stakeholders as a PM.

A good PM is dedicated to solving customer problems, which often involves dealing with customer frustration and complaints, even if some of them don't make sense. If you have developed a strong emotional attachment to a product, it can be threatening to hear negative feedback, but it's important to put your ego aside and build an emotional connection with your customers.

Listen to their complaints, ask questions, and don't let your current agenda get in the way. When someone wants to complain about your product, it's an opportunity to build trust with your customers and increase your authority.

🤡 Criticizing without accountability is easy.

This may be a more personal reflection compared to others, but as an SDM, I have been an asshole to my PM. I often felt that we lacked a solid product strategy, didn't ask the right questions, and didn't delve deep enough into the problems before defining solutions. That's why I decided to switch to the PM role myself.

If you're currently an SDM and have a strong opinion about what the team should be building, remember that you may be heavily biased with the technical aspect of the product. Even if you believe that you understand the business and the customers, it's possible that you don't. Therefore, provide feedback to your PM and trust them to do their job well.

🤑 Lower compensation range.

Based on levels.fyi, PMs in FAANG companies are paid less than SDMs at all levels. While your salary may not decrease immediately when you switch job roles, you may see smaller compensation increases as you progress to the next levels. However, at a certain point, most tech workers are generally comfortable with their quality of life.

Although it may not be an easy choice mentally, if you are consciously switching from SDM to PM, you will likely enjoy the role more. When you love your job, you can achieve levels of professional success that may not have been possible in your previous roles. Therefore, in the long run, it will pay off.

Role transitions are fun, adventurous and hard. If you see the clues to move into Product, and feel the calling - then go for it. I did, and I love it!

As I move into this new role, I wanted to share with you my 6-week plan for becoming an autonomous and successful PM for the new Product.

A Product is a complex and messy ecosystem of technology, people, and business. So how to use the on-boarding time and resources effectively?

How not to get lost in opinions, biases, but to create a holistic and balanced understanding of the product, necessary to become autonomous and successful PM?

My focus is on reducing uncertainty by incrementally absorbing all the resources available to me.

The resources include existing artifacts such as:

• vision and strategy documents

• business and product requirement document

• training and documentation

• demos

• post- and pre-mortems

• status updates

• roadmaps

• design documents

I will also work closely with key people such as:

• Previous PM

• The engineering lead and development team

• Stakeholders

• Customers

• Potentially new leadership

My plan combines perception, reflection, play, and creation. It’s a spiral plan, meaning that every week I am going deeper in understanding of different aspects of the Product. This approach is based on spiral curriculum theory, which emphasizes the importance of revisiting previously taught ideas and building upon them.

I want to highlight the necessity to begin writing early and often. Good place to start is your version of the Product vision. It will feel like it turns out naive and dirty, but as you continually learn, you’ll refine it and get feedback from the stakeholders. In addition to your version of the vision, get into the “boy-scout” mode by improving the existing critical documents, or creating them if they don’t exist.

Week 1

🗣 Meet

📚 Read/Watch

• Strategic documents (Product vision, strategy and goals).

• High-level trainings, introductory documentation.

🕹️ Play

• Spend at least 2 hr exploring the Product. Get an overall sense of the user journey.

📝 Write

• Summarize your learnings of the week

Week 2

🗣 Meet

📚 Read/Watch

• Product discovery documents (opportunity-solution tree, roadmap)

• Stakeholder documents

🕹️ Play

• Spend at least 4 hr exploring the Product.

• Go deeper in the workflows, try to replicate the journey that you learned from the user interviews.

📝 Write

• User interview and stakeholder 1:1 notes.

• Write 1 page with your current understanding of the vision and goals of the Product.

Week 3

🗣 Meet

📚 Read/Watch

• Tactical documents (Recent and current business requirements).

• Product Technical Design

• Postmortems

🕹️ Play

• Spend at least 4 hr exploring the Product.

• Test the new features or bug fixes that are code complete.

📝 Write

• Notes on tech design.

• Notes from the user interview.

• Update opportunity-solution tree with your ideas.

• Refine the vision doc.

Week 4

🗣 Meet

📚 Read/Watch

• Metrics dashboards and definitions

🕹️ Play

• Spend at least 4 hr exploring the Product.

• Replicate recent customer issues in the Product.

📝 Write

• Notes on the metrics

• Notes from the user interview

• A most common user journey that you heard from the users, and how it can be measured with existing metrics.

• Refine the vision doc.

Week 5

🗣 Meet

📚 Read/Watch

• Market, User and Competitor research analysis

• Tactical documents (Business requirements) — yes, again

🕹️ Play

• Spend at least 4 hr exploring the Product.

📝 Write

• Refine the vision doc.

• Fill the gaps in the existing business requirements

Week 6

🗣 Meet

📚 Read/Watch

• Roadmap (now it might make more sense)

• Latest user feedback.

🕹️ Play

• Spend at least 4 hr exploring the Product.

📝 Write

• Combine your version of the Product vision, and opportunity-solution tree to validate the roadmap.

• Propose an alternative roadmap, if you see a better path forward.

It can be easy to get too deep into one aspect of the product, or to get lost in the breadth of materials without a clear focus. In my plan I tried to ensure consistent and intentional learning tapping into variety of sources and backed up by reflection and writing.

If you have other tips, please drop a comment.

Let’s go!🚀

How do you launch a new digital product or service? When the countdown hits 0, you push the red button while your team mates popping champagne? That’s how start-up TV shows portray it.

I mean, what exactly the product team needs to do to launch a new built an tested product to be used by real customers, who will pay real money for it?

Boom, you gotta plan it.

In this article, I will share some tips and insights from my experience launching products at Amazon and SLB.

I will talk about:

• 📝 Launch plans

• 👑 Ownership & accountability

• 💬 Communication mechanisms

• 📐 Product & service metrics

• ✅ Success criteria

• 🚀 Go/no-go decisions

• 💥 Mitigation plans

📝 Launch Plan

Plans are worthless, but planning is everything. For many folks, especially those with a startup background, a launch plan may seem like a bureaucratic requirement for large companies. However, it is not. You need a plan, and it should be the most painfully detailed and meticulous spreadsheet ever created by a human being. This plan is going to be your pillar of support over the entire course of the launch.

The launch plan is a main tool to systematically identify and mitigate risks associated with a product launch. It involves the coordination of multiple engineering, design and science teams, while managing multiple tech and business dependencies. This plan requires careful consideration and coordination of resources, timelines and budgets.

It can look similar to this, but is usually bigger and scarier (grab this Notion template here):

Essentially, this includes all of the final engineering tasks, such as the last testing and feedback sessions, the preparation of training and marketing materials, the completion of all necessary sign-offs and certifications, and the actual steps to launch the app to production, redirect traffic, and monitor its performance. In other words, it encompasses everything that needs to be done to ensure the app is ready for a successful rollout.

👑 Ownership & Accountability

The last time I launched a product on my own was way back when I was just 16 years old. It was a website for my schoolmate's father's construction business.

When working with a team on a product launch, it's crucial to have a clear understanding of everyone's roles and responsibilities. In your launch plan, make sure to list all stakeholders and assign specific tasks and decisions to each one. It can also be helpful to designate a single point of contact (POC) to facilitate communication when working with larger teams.

Before moving forward with the plan, it's important to review it with all stakeholders and POCs to make sure it aligns with their expectations and roles.

But sometimes, even this isn't enough in a group setting. Some stakeholders may seem fully onboard and present at meetings, signing off on everything as requested, until the very last moment.

I once had a stakeholder call out a missing feature just before the go/no-go decision for a major launch. This feature had never been discussed before (a major red flag for our discovery process). It turned out that this feature was a deal breaker for them to adopt our product. Although this stakeholder was secondary, our primary stakeholder had a critical business dependency on them, so it became a showstopper. Make sure to follow up with each stakeholder personally, especially those you don't interact with as frequently, to avoid any surprise roadblocks.

💬 Communication Mechanisms

It is important for the extended product team, stakeholders, and leadership to know how and when to access the latest updates on the launch, regardless of the format, medium, and frequency chosen.

I also recommend holding face-to-face meetings a couple of times a week and increasing the frequency to daily in the final week or two before the launch. These meetings provide an opportunity to check in with team members and identify any potential risks that may have been overlooked. Ask "What's on your mind?".

Even if you are using the best project management tool available, I still recommend sending a daily, old-fashioned status update email with a snapshot of the launch plan. This helps to reduce the number of "What's going on with the launch?" inquiries, although you will likely still receive some.

📐 Product and Service Metrics

Status updates from stakeholders and the product team provide valuable insights, while metrics serve as a way to track progress and performance.

Before the launch, it is important to monitor a set of metrics that ensure the product is functioning as intended. This may involve tracking dozens or even hundreds of metrics and monitors at the service, database, and infrastructure level. These metrics should also include the results of automated user tests, and it is helpful to have a way to easily interpret them and view them in a simple, easy-to-understand format such as a health check.

Immediately following the launch, focus on monitoring metrics that answer the following questions:

• Is the product being used?

• Is the new feature being used?

• Who is using the product (location, demographics)?

• Where are users coming from and where are they going in the user journey?

• Does the product address customer needs?

• Do customers love the product?

• What is the impact of the product on the business?"

✅ Success Criteria

Defining a clear set of metrics beforehand will make it easier to establish success criteria for the launch. Consider what success looks like for the launch, whether it is simply deploying the app to production or waiting for the first customers to complete the journey successfully.

To establish success criteria, consider setting targets for service and product metrics, as well as business outcomes. If a metric cannot be measured, it will be difficult to determine whether the launch was successful or not. Make sure that stakeholders are aligned with these criteria as well.

🚀 Go/No-Go Decisions

The go/no-go decision is a crucial moment in a product launch, as it is the point at which the team determines whether to proceed with the launch or not. Complex launches with technical and business dependencies may have multiple go/no-go decisions.

So, how do you decide when to hold a go/no-go decision? Keep in mind that the go/no-go decision is a one-way door decision, meaning that everything that happens before it is reversible, while anything that goes wrong after the decision can have serious consequences, such as reputational damage, financial losses, or even health risks.

🍾 Celebrating Success (or Failure)

Congratulations on all of your hard work and preparation! It's time to celebrate the launch of your new product with your team. If you followed my tips, I have high hopes for a successful launch.

But even if things don't go exactly as planned, remember that every launch is an opportunity to reflect and learn. Take the time to celebrate the accomplishments and efforts of your team, and use the insights gained to drive future growth and success.

Cheers to a successful product launch!

As we get ready to welcome in the New Year, it's week 52 and I've been reflecting on the past year and how I can become a better person in 2023. Aside from family gatherings and indulging in some over-eating, I'm also setting some goals for the upcoming year.

Setting goals has been proven to have positive effects on motivation, self-esteem, confidence, and autonomy. Studies in neuroscience have shown that goal-setting rewires the brain and creates new behaviors that help increase the likelihood of achieving the goal.

This time, rather than just typing up a list of goals, I decided to try to round-up my year summary in a short narrative (step 1). It helped me to identify the opportunities I have in this upcoming year, as well as what I call "sources of guilt". These are things that I've always wanted to do, but never got around to, and now I'm feeling guilty for wanting to start new ventures before I address them first.

I also used the narrative form set the intention and themes for 2023 (step 2), then broke them down into individual goals and sub-goals (step 3 and 4). I avoided output goals like "read X books" or "go to the gym Y times a week" and instead focused on the outcomes I wanted to achieve.

Of course, it's essential to stay consistent when it comes to goal setting. I'd recommend setting up a regular review and adjustment mechanism (step 5) that can help you stay in control of your destiny.

My reflections and goals turned out quite personal, so I will not share it. However, I saved the structure in a Notion template, so you can copy it and use it to set your own ambitious 2023 goals. I hope you'll find it useful and have some fun with it.

Here it is - Personal Goals Notion Template.

Here are some useful resources if you want to learn more about goal setting, why it could be effective, and what it does to your brain:

• The Science of Setting and Achieving the Goals, by Andrew Huberman

• Goal Setting: A Scientific Guide to Setting and Achieving Goals, by James Clear (the author of Atomic Habits book)

• What Goal-Setting Does to Your Brain and Why It's Spectacularly Effective, by Geoffrey James

Subscribe now