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

  • in Books
  • 2 min read

Julius Caesar Was a Startup

While reading Julius Caesar’s biography by Adrian Goldsworthy, I learned a surprising fact: he funded his political career as a startup would today.

Caesar was from a very noble patrician family. However, at the moment of his birth, his family was not incredibly rich and powerful compared to other Roman nobility. They have significant connections, but that alone would not be enough to build an outstanding political career.

The Roman political system was not characterized by parties but rather by individuals. Those individuals spent a large amount of their money to gain popularity among the citizens, support their lifestyle, engage in what we today consider bribery, and so on.

As we know, Gaius Julius Caesar was a very ambitious person. From an early stage, when he began climbing the career ladder, he consistently borrowed money from his wealthy political supporters, who saw potential benefits in a future leader. He also used those funds to maintain his lavish lifestyle, which was considered extravagant by Roman standards of the day.

Caesar had to rush to maintain the belief in his support, so money continued to flow to gain more popularity and cover previous borrowings. And he did exceptionally well by reaching each new position in a political hierarchy as soon as his age allowed him to do that. And sometimes even earlier.

There were cases when Caesar was near what we can call a “bankruptcy” 💸 when he undertook some drastic actions. A notable example is that he refused a triumph dedicated to his military campaign in Spain, which can be considered the pinnacle of anyone's career in Rome, to run for consular nomination that year.

Consularship was a prestigious elected office in the Roman Republic. Two consuls held it, jointly exercising executive authority, commanding armies, presiding over the Senate and assemblies, and were replaced annually to prevent the concentration of power.

So, Caesar could have obtained his triumph and waited another year to secure the consulship. However, for him and his donors, advancing his career was critical; he could not wait.

Only during his Consulship, and more likely his subsequent military campaign in Gaul, did Caesar finally become reliant on the funds he had gained. Using modern language, he achieved the required profitability level without further investments 💼📈. He was above his 40s, and the most interesting part of his life had only begun.

After reading that, I was amazed at how easily we can draw a line between today’s startups and 2000 years ago.

Considering his impact on humanity's history, Julius Caesar was one of the most successful startups in the world. 🏛️🔥

Traditional Goku and the Book

Do We Need Junior Business Analysts?

The Temptation to Say No

I saw on LinkedIn a rare opportunity for 2025: a vacancy for a Junior BA. I wondered whether hiring someone for such a junior position makes sense, considering the current level of AI advancement.

My immediate answer is NO: as a Product Manager managing a portfolio of products, AI could do the same work as a junior Business Analyst does. And sometimes, with a better quality and less involvement of someone who needs to guide that person.

Let's discuss the statement above, because the answer is not as simple as it may seem.

AI-generated nonsense

The Product Manager's View on Composability

Composable Definition and MACH

Composability, also known as Composable solutions or Composable commerce, is a design principle in which individual components or services are modular, independent, and interoperable. It allows them to be easily combined, reused, or replaced to build complex systems.

We have a custom-built core product for software businesses, whether a monolith or a set of microservices. In addition, you (when I mention you, I mean a product, area, or organization) have several external integrations with different levels of complexity.

For non-software businesses, several vendors of different scales have some in-house solutions. Those businesses are the primary beneficiaries, as Composable is a way to eliminate vendor lock-in and gain more control while also being flexible enough to adapt to market changes.

Composable addresses the latter case by using "best-of-breed" components available, whether market or house-built and adapting them according to business requirements.

To build such a miraculous system, you need middleware that connects several headless subsystems via API and provides governance and data consistency.

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.

  • in Media
  • 1 min read

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.