10 posts tagged with "Product Strategy"

Any stakeholder management framework is ineffective if there is no trust between you, as a product owner, and your stakeholders. Trust is challenging to gain, resourceful to maintain, and very easy to lose.

For stakeholders, you represent your team, your product, and your organization. If they don't trust you and consider you an unreliable partner, then it is a chain effect with a downward spiral.

How to build and then maintain that trust? It is straightforward - deliver expectations. If you can't deliver, then manage those expectations.

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.

Disclaimer​

The following case study focuses on dependency management, omitting other details that are irrelevant to the topic or might be sensitive to share publicly.

I do not necessarily speak on my behalf. Let's assume some Product Owner (The PO) appeared in such a situation and acted a certain way to resolve the dependencies.

Background context​

There are a few details to be mentioned to provide context:

• PO joined an ongoing project at its critical stage. Thus, there was no room for cross-organizational changes.
• PO had a flexible number of responsibilities, which might vary considerably from that of the vanilla Scrum product owner.
• PO had a great team; it would be impossible without them.

Dependencies structure​

This is what the team topology looks like, approximately. And that impacted how dependencies are distributed.

Three organizations are involved, each with their own development teams and management. It is obvious that each side pursues its own goals in accordance with contractual obligations.

Recently, LinkedIn asked me to share my insights to be eligible for the "Top Voice" badge. I realized that I have something to share with my followers in a more extended way than typical (ChatGPT-generated) answers to those top-voice questions.

Definition and classification of dependencies​

As usual, let's start with the definition, which is rather made on my own. When you need someone to do something so you can do your work, that is a dependency. Postponing the dependency means a delay in delivering your work and the expected outcome, which causes financial losses.

Your team/service can have one or several dependencies and be a dependency for someone else. Sometimes it can be both. And dependencies might be temporary when you need something to be done once or permanent when you continuously need something to operate.

There can be external dependencies, meaning that you are waiting for something to be done outside your organization. Or that will be done inside your organization, which is an internal dependency.

We can distinguish cross-team, cross-stream, and cross-department dependencies, each with its own peculiarities.

In my world, dependency means an API or a software library. In your world, that may be anything else, like a vehicle part or a plumber to fix a pipeline leak.

Throughout my career, I participated in the development of a few supplements for so-called “parent” products. They were standalone services with their own, not big, but still considerable business value. Recently I realized that even though those supplement products were developed in different organizations and in different business areas they did have common traits. Moreover, they shared the same problems.

It was something laying on the surface. Sometimes you shoot yourself in the foot twice before starting to see obvious things. What is the nature of those Sidekick products and do they inherit the problems of “bigger brothers”? Let us sort it out in this essay.