Skip to content

Welcome to My Blog πŸ‘‹

πŸš€ Insights on Product Management, Building Enterpise Platform, and APIs
I write about API design, product management, business analysis, and other related topics based on real-world experience.

πŸ“Œ Check out my e-books: Requirements & API and Replacing Legacy!

πŸ“š Topics I Cover

πŸ”Ή APIs & Integration – Best practices, documentation, and real-world challenges.
πŸ”Ή Product Management – From stakeholder alignment to backlog management.
πŸ”Ή Enterprise Dynamics – Org structures, team collaboration, and execution.

πŸ“’ Recent Updates

πŸ’‘ Follow me on LinkedIn for more discussions!
πŸ“¬ Subscribe to my Medium for new posts!

πŸ“– Recent Publications

Stakeholder Alignment: The Underrated Skill Every Product Manager Needs

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.

New Chapter of Requirements & API - Workflows

A new chapter in the Requirements & API series is available.

The final chapter of my Requirements & API series is here! This article dives into designing and documenting hashtag#workflows, showcasing how to manage several API interactions effectively.

πŸ” Key Highlights:

πŸ–ŠοΈ Using UML Sequence Diagrams to illustrate interaction flows across multiple actors.

πŸ–ŠοΈ Exploring the new hashtag#Arazzo specification from the OpenAPI Initiative, which enables referencing existing OpenAPI operations to outline workflows step by step.

πŸ–ŠοΈ Taking a look into ServerlessWorkflow, a powerful DSL for designing and executing workflows that support various protocols.

This was one of the most challenging articles to write, given the variety of notations and languages involved. But I’m thrilled to share it with you!

Previous chapters:

2024 Reflections & 2025 Plans

cover

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.

Achievements

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.

BArszawa Blog #7 (December'24) is available!

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

What is inside:

  • Community updates from recent events "Product Metrics Unveiled" and "AI as Game-Changer for Modern Business Analysis".
  • And traiditionanly a new portion of useful materials.

Previous BArszawa editions:

Note: that is the last BArszawa blog edition under my editorial watch. In 2025 I will focus exclusively on my blog.

New Chapter of Requirements & API - Interface Definition Languages (IDL)

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:

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.

New Chapter of Requirements & API - Design

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:

BArszawa Blog #6 (September'24) is Back!

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

What is inside:

  • Community updates from recent events "Offer of the Dream" and "What's in the Box?".
  • A mini-interview with insights about SAP implementations.
  • A bunch of useful materials.

Previous BArszawa editions:

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!