Skip to content

2022

  • in API
  • 8 min read

API Design Tooling

This article is a part of the API Design series, where I will review several API design tools and summarize my experiences. There are the following criteria I use in selecting and evaluating the tools:

  • it is free: either open source or a free plan of a paid product
  • out-of-the-box functionality is considered only: no plugins
  • both web and desktop products are considered
  • it allows designing REST API definition in OpenAPI 3.x with JSON/YAML (low-code), UI means (no-code), or a combination of both
  • code generation functionality is not required as there are several 3rd party libraries to do that

I am not promoting, just expressing my honest opinion. But I might have my favorites. Also, I will describe these tools at the moment of December 2022.

  • in API
  • 6 min read

API Design-First

This article is a part of the API Design series, where I will uncover API design concepts for my non-technical peers. You don't need to be a developer or an architect to participate to design or even build an API, but there is something you should learn to succeed.

So we start with API design-first, which takes the opportunity to democratize the API development process.

  • in Books
  • 5 min read

Thoughts about J. Gharajedaghi’s "System Thinking"

Cover

This is a new rubric in my blog as I tried to avoid any posts about specific books before. I am taking some notes about the best books I have read. But those are not for the public eye. So this piece was not originally planned to be published. I just feel a need to share something with the world after I read a book in the title. Because that was a wonderful but pretty tough experience.

Before we begin, let’s make clear that:

  • It is not a review. I will not write about bad books in my blog. By default, any book which has a separate essay is worth reading. Period.
  • That will be in the form of an internal dialog.

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.

Sidekick product

Cover

Throughout my career, I participated in the development of a few supplements for so-called “parent” products. They were standalone services with their own, not big, but still considerable business value. Recently I realized that even though those supplement products were developed in different organizations and in different business areas they did have common traits. Moreover, they shared the same problems.

It was something laying on the surface. Sometimes you shoot yourself in the foot twice before starting to see obvious things. What is the nature of those Sidekick products and do they inherit the problems of “bigger brothers”? Let us sort it out in this essay.

Product Manager: Year One

Cover

One year has passed since I was promoted to a Product Manager position: first six months as an Associate (a Junior grade), and then I stepped in as a fully-fledged Product Manager. And that was a drastic shift that made me revisit some aspects of my work and added a new dimension to my view on product development.

In this essay, I want to summarize my experience with the insights I collected throughout the year. Some of them might be obvious to a more experienced audience. But for me, some were revelations, and some were hugely underestimated initially. It is a good exercise to conduct such a personal retrospective, and others can benefit from that as well.

Pre-interview tips for Junior Business Analysts

Cover

Recently I was looking for a Junior Business Analyst to join my team. I considered candidates with little or no experience in IT. And that was an excellent experience for me. For the first time in my career I:

  • wholly owned job requirements for the position
  • made a final decision to hire someone or not
  • was not doing the tech part of an interview
  • interviewed Junior-level specialists.

It is different from interviewing a Middle or Senior BA. You can discuss various topics with more experienced professionals: practical cases, challenges, techniques, recent articles, etc. But that is hardly applicable for the Juniors as they can share only their background and knowledge of theory with the ability to apply that in practice, at the very least.