Another year is almost over, so it is time to summarize all that happened and discuss what is coming. First, let me wish you a Merry Christmas and Happy New Year before I dive into self-reflections relevant only to a few readers.
In 2024, I published 24 articles, including 7 editions of the BArszawa blog, where I acted as a writer and an editor. That's two times more than in 2023.
Here is the next blog edition of our Business Analysis Community in Warsaw: BArszawa Blog #7 (December'24)
What is inside:
Previous BArszawa editions:
Note: that is the last BArszawa blog edition under my editorial watch. In 2025 I will focus exclusively on my blog.
A new chapter in the Requirements & API series continues uncovering API design specifics. This time, we look closer into IDLs (Interface Definition Languages).
I examine OpenAPI as an industry standard, Microsoft-powered rival TypeSpec, and an underdog JSight. They have a similar purpose but achieve that in very different ways.
We are approaching the end of the journey. In 2025, one more article will describe API workflows.
For now, that's it for 2024. Of course, there will be an overview reflecting on the past year and sharing some plans for the upcoming one.
Stay tuned!
Previous chapters:
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.
A new chapter in the Requirements & API series focuses on structuring each layer to design an API. This time, it is more practice-oriented, with examples of an HTTP API call and its OpenAPI definition.
I am in the hallway through that series. Almost a year ago, I did two webinars on the topic. Those articles help look deeper into the topic, which is better done in writing.
I originally planned to retell my material from offline and online events. However, reality is different, so there are many deviations and extensions.
So, two more chapters will come, and the topic will be closed. I have been writing and talking about APIs since 2022. I continue working as a product manager on the API Platform, and the articles about APIs get more attention from the audience than anything else.
So enjoy reading on Medium (friend link)
Or here: Design
Previous chapters:
Here is the next blog edition of our Business Analysis Community in Warsaw: BArszawa Blog #6 (September'24)
What is inside:
Previous BArszawa editions:
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.
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:
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:
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!
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:
FYI: The BArszawa blog is taking a well-deserved summer break. But don't worry. We'll be back with more exciting content! Stay tuned!
Previous BArszawa materials: