15 posts tagged with "Product Management"

Introduction: The Shift in My PM Role​

As a Product manager, I am building proofs-of-concept (POC) and constantly hunting for context.

That's what my role is about now. I am reluctant to create roadmaps, write any required documents, and manage the backlog in Jira.

Previously, writing those requirements docs, sitting on mockups to ensure they matched the requirements, writing user stories, and many other related tasks were part of the creative process.

I enjoyed that. That was a reason I kept going in my craft for now more than a decade: from an L1 support engineer to a Senior product manager.

Now I am looking and constructing something that a "team can build in the near future." Everything else stepped aside. I don't enjoy it anymore.

This article is a summary of my PM experience on designing an artificial intelligence (AI)-based capability for an existing product from the proof-of-concept (POC) stage to a minimal viable product (MVP).

When you are adding an AI feature to an existing product, you can either:

• introduce an entirely new functionality
• extend existing functionality with AI possibilities.

In my case, the latter is true: we aim to introduce AI search to enhance user experience. It sounds pretty trivial, I acknowledge that. The challenge is that search is the critical functionality for that product.

Therefore, we need to introduce a new search method to provide users with more value than the existing one. If AI search works "just good enough," then a traditional one could be considered a failure.

The improvement must be substantial, because of …

The higher you climb the product manager ladder, the more noise gathers around you.

You hear multiple ideas and suggestions for improvements from various people. And that doesn't make much sense in the current picture. It would be nice to do in an ideal world, but we are too far from that.

There is a tendency for companies to lay off people but don't cut down their expectations, trying to operate as if nothing had happened and the business goes as usual.

They likely hope for AI to resolve that inconsistency between dreams and reality. But that is a gamble at the moment. It might pay off for some, but hurt others.

Should we let users know about upcoming features? Can it make them angry if you tease them and then underdeliver?

Let's find out.

There is much buzz about whether AI could replace human product managers. I am not very concerned. Much of my work involves dealing with stakeholders at different levels and pursuing various objectives. AI will find it challenging to substitute that side of people interaction. I mean politics in a sense of power dynamics among multiple groups of stakeholders.

We don't like politics in the workplace, but it is inevitable when there are more than a dozen people.

Dealing with internal or external stakeholders always involves politics and personal-professional relationships. The larger the organization, the more complex the political landscape and the bigger the stakes.

The power dynamics impact everyone in the organization, including individual contributors. When an individual contributor (IC) transitions to a manager role, they become a part of the game without any choice.

For future plans, please don't create one-liner tickets in your backlog.

The only excuse is when you must "proof" some future work. I knew a project manager in an outsourcing project who told business analysts to create 500 Jira issues to showcase to a customer the scope of work for continuing a development team's assignment.

In recent years, I have been dealing with massive backlogs of outdated items written by people no longer around. That has resulted in painful and time-consuming reviews and (re)-negotiations with stakeholders.

If you have such experience at least once, you are likely a fan of focused and precise backlogs like myself.

Onboarding is a crucial process of incorporating a new person into a team, product, or domain (for simplicity, let's generalize all that as "area"). The purpose is to align or increase performance as soon as possible after the unavoidable drop due to a structure change. If approached wrongly, it may cause substantial trouble, especially when you dive into a new area as a product manager (PM).

Whether it is a new or same organization, new role, or new area - the approach to onboarding will vary. Here, we talk about horizontal growth within an organization, keeping your role but acquiring a new "area" (for simplicity, let's use this term to generalize one or several products, teams, lines of business, etc). That is the situation I am currently in, so I have something to reflect on. Also, most onboarding guides focus on vertical growth with a new role in another business. So, it is a good topic to uncover.

I follow the patterns of 3 key knowledge types in product management suggested in the "Building Products for Enterprise" book (I wrote about it here): organizational, product, and market knowledge. So, let's construct the onboarding strategy for each.

I finished reading "TRANSFORMED: Moving to the Product Operating Model" by Marty Cagan. This is not my usual a few thousand-word review—rather, it is a few aftermath thoughts.

It was a sunny day in 2019 when I found myself in the largest bookstore in Dubai, surrounded by a sea of books. I had three hours to choose my next read, a decision that would shape my professional journey. After careful consideration, I picked up "Product Management in Practice" by Matt LeMay, a choice I've never regretted, even though "Building Products for the Enterprise" was a close contender.

Even though I read and appreciated both books in the end, that choice impacted my career without any doubt. At that time, I was a business analyst in an outsourcing software development company who desperately wanted to become a product manager in a product organization.

I can't say that the book made me a product manager. But it definitely impacted me as the professional I am today - for better or worse (I hope for the better). I read it 3 or 4 times while transitioning from a business analyst to acting as a PM. Each time, I was surprised at how much wisdom was placed in that slim book and how differently I looked at some things throughout the years. It is like a peaceful harbor, and you want a return after fighting yourself through multiple storms.

In 2024, I realized that the 2nd edition was published in 2022, so before writing this piece, I enjoyed reading it. There are many changes compared to the previous version, but it is the same brilliant book. Here, I will talk about the 2nd edition.

If it is not the best, then it is one of the best books about product management. Below, I will prove my point.

I almost missed a point of reaching a three-year tier in my product manager career, which nearly matches with ten years in IT. I wrote essays about my previous years (year one, year two, combined article on Medium) as a retrospective of my thoughts and feelings.

I had doubts about whether I wanted to write the continuation. I re-read previous pieces, which made me realize I needed to continue. First, the "Sophomore Year" was quite depressing. Second, I need to finish the series, and having that as a trilogy sounds right.

I don't say it will be optimistic than a previous one. A bit brighter, maybe. And most probably, the last. Writing that in a third time felt more like an obligation.

Anyway, it is time for a retrospective of my 3rd year of being in product management.

Platform engineering and product management​

Last year, I had an identity crisis because my job seemed to be far away from what is written on product management. It coincides with general terms, but the devil is always in details.

Then, I realized that platform engineering and product managers who are working on Internal Development Platforms (IDP). There is a community, books, webinars, courses, and tools around that. Many people are doing similar things I am trying to do and have similar problems.