Here is the next blog edition of our Business Analysis Community in Warsaw: BArszawa Blog #6 (September'24)

What is inside:

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.

Here is the next blog edition of our Business Analysis Community in Warsaw: BArszawa Blog #5 (May'24)

What is inside:

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.

Here is my writing routine: the way how I structure my research on various topics and then write an article.

It is not my usual type of content, but it might be helpful to someone. And yes, I need to fill the vacuum while working on two new writing pieces: a book review and a new topic.

Writing Tools​

I use Obsidian as a knowledge base and content management. It is free, keeps your data in your hands, not in a vendor cloud, uses Markdown for formatting, and has a variety of great plugins. 

The latter is handy as my blog is also built with the MkDocs engine based on the Markdown format. So, I keep writing and editing in Markdown, which is very convenient. I don't particularly appreciate it when each tool tries to reinvent the wheel with its custom formatting, which is incompatible with anyone else. With Markdown files stored on my local machine and my cloud storage, I can quickly grab them and migrate them to another tool.

I use the Zettelkasten technique in Obsidian when I research something and need to document some information and my thoughts to reference it later. You can find a lot of information about this approach. I keep my notes connected with tags and internal references where possible. Obsidian provides a nice graph where I can filter out some notes and track references.

Once a year, I clean up by editing, merging, or even deleting some notes. So, I try to keep the number of my Markdown notes from spreading. You can see a part of the notes graph in the attached image below.

A month has almost passed, so here is a new edition of the BArszawa blog, where I serve as a contributor and editor: BArszawa Blog - April’24 Edition

What is inside:

Last month, I started summarizing all my API-related posts, workshops, and webinars into extended and structured reading. That is usually a part of the Essays section, where you can find my recent Replacing Legacy series.

Reflecting on my past materials about API, I realized they were disconnected and lacked a logical narrative. However, I am proud to share that I am starting anew, from simple concepts to in-depth reviews of various Interface Definition Languages, showing significant improvement in my approach.

The new chapter, "Analysis," focuses on business analysis and aspects of requirements engineering. That was tough to write and edit, cutting pieces that did not fit and made text difficult to comprehend. Hopefully, I will get a satisfactory result.

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.