Skip to content

Product Management

Pending Backlog Items Have a Price

AI-generated nonsense

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.

PM Onboarding - Same Organization, New Area

cover

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.

TRANSFORMED - Some Thoughts After Reading

Book cover

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.

You, as a reader, need to set the right expectations. If you read "INSPIRED" and "EMPOWERED," plus follow the SVPG (Silicon Valley Product Group) blog and watch Marty's interviews (which is my case), then you will find nothing new here.

This book is a logical continuation of Marty Cagan's previous works, focusing on organizational transformation. It streamlines the recent SVPG narrative into a single digestible source, empowering you with comprehensive knowledge.

With all that in mind, I consider "TRANSFORMED" a worthwhile and valuable reading.

If you are not familiar with Caganverse, I can still recommend it. However, you must read the previous books to get the complete picture. It touches on many topics that were explained before but without self-quotation. So this is an excellent point at which to start the journey.

I need to mention a shitty feeling you might have after reading those books:

  • "INSPIRED" trials, whether I am doing product manager work or a masked backlog administrator.
  • "EMPOWERED" makes you question your product leadership and whether you can become such a product leader.
  • "TRANSFORMED" questions the integrity of your organization and its capability to undergo such a transformation

I am convinced that triggering those feelings is intentional. I reflect a lot while reading, so it takes me longer to complete these books.

The "Product Operating Model" is a set of principles, not a framework or guideline, to transform your organization into something more innovative in shiny armor. That book is also for product coaches and others interested in the org-level transformation by:

  • Changing how you build
  • Changing how you solve problems
  • Changing how you decide which problems

These 3 points are enough to characterize the model and the book.

I like the transformation stories, especially ones told by people who participated in them, and the chapter about overcoming objections from different parties. While reading, I was also trying to put myself into an executive shoes who wants to transform a large enterprise. The author says it is a tough endeavor where external help is needed.

Is this book an advertisement for the SVPG consultant services? No, it is not.

It is a tool to popularize the Product Operating Model, a form of evangelism to encourage organizations to change their ways of creating valuable and commercially successful products. No certification is required to start applying those principles.

Only time will tell whether that model will spread around the world and scale, changing the way products are designed, developed, and delivered. Meanwhile, enjoy the book!

Best Book I Read in My Career - "Product Management in Practice" by Matt LeMay

Book cover

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.

Product Manager: Year Three

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.

Firefighting in the Dependency Hell: a Case Study

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.

Backlog Management - About Dependencies

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.Mixed pattern to resolve

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.

Thoughts about "Building Products for the Enterprise: Product Management in Enterprise Software" by Blair Reeves and Benjamin Gaines

After a long break, I return to book reviews in the form of an internal dialog. That time it is one of the most valuable books I have read about Product management: "Building Products for the Enterprise: Product Management in Enterprise Software" by Blair Reeves and Benjamin Gaines.

Book cover

OK. I am glad you are finally talking about this book. It is an obvious question, but I must ask it. What this book is about?

The title is self-explanatory enough: the book is about being a Product Manager (PM) in a B2B Enterprise organization.

Sounds fair. What is so unique about working in the Enterprise compared to other PMs?

First, let's agree that Product management is a vast discipline. Every organization looks at it from a different angle. So, a PM's responsibilities and role definition might vary for similar products but from other businesses in the same market.

Enterprise PM differs from a startup PM in that the first needs to survive in a complex hierarchy, build relationships, and comply with an Enterprise's restrictions. Also, it depends on whether it is B2B, B2C, B2G, B2B2B, etc. That impacts a lot on how products are developed and sold.

I will paraphrase the book to not expand on this topic further. What makes PM in the Enterprise different:

  • business model: usually direct sales or subscription
  • specialization: very specialized products
  • the split between customers and users

Product Manager: Sophomore Year

Cover

Toddler Vectors by Vecteezy

Last year I wrote a short essay summarizing my first 365 days as a Product Manager. One more year has passed, and it is time to share more insights or learned lessons.

Important notice: It is only about my experience, so some things may not apply to what other PMs are experiencing. Product Management is a vast discipline with different responsibilities across different companies and industries.

How I overcame my obsession with performance metrics

Cover

I fell into a common trap of every manager: obsession with performance metrics. Since I have been promoted to the PO role my responsibilities include tracking stats related to the backlog and team performance. That includes the team’s capacity, estimates, velocity, and other specific metrics. In an ideal world, the estimation of planned features matches capacity, the team performs a predicted velocity and (more importantly) delivers features in time. But we all know that doesn’t work this way.

This is the story of how I became obsessed with numbers instead of being obsessed with a product. And how I overcame that and shifted my focus to real value.