post

B2B product management

Artificial Intelligence (AI) & Machine Learning (ML)

Building Product Teams

Business Strategy

Data Driven Product Management

Digital Transformation

Diversity and Inclusion

Minimum Viable Product

OKRs

Prioritisation

Product Design

Product Research

Product Development Process

Product Ethics

Product Discovery

Product Leadership

Product Management Career

Product Strategy

Stakeholder Management

🌎 <a href="https://www.mindtheproduct.com/world-product-day/" style="color:#FFFFFF;text-decoration:underline;">Happy World Product Day!</a> Be sure to celebrate product, yourself, and your peers today! 🎉

Successful product management in companies where it’s least understood

Measuring critical user journeys – Javier Andrés Bargas-Avila (UX Director, Google)

A new way to look at applied experiments

Product survey findings: Only 15% of users are embracing AI features 

Building high-performing product teams: The PDLC approach

Footer About

Footer Contribute

Footer Get Involved

Footer Links

Mind the Product

Guest Post

Overcoming the 20% feature usage challenge

Product Management

Three product leaders to learn from at #mtpcon inside Pendomonium

Shiva Hullinakatte is a product manager with deep product management knowledge and more than 13 years of prior professional experience in technology. He has a track record of successfully delivering scalable technology solutions across the healthcare, travel, and telecom industries. He is currently a Senior Product Manager at  AT&amp;T and is supporting the design and launch of technology solutions on www.att.com that enables easy self-service access for more than 80M AT&amp;T customers.

Shiva Hullinakatte

In my <a href="https://www.mindtheproduct.com/beyond-amazon-com-amazon-as-a-service/" target="_blank" rel="noopener">previous article</a>, I talked about Amazon’s “Buy with Prime” option and how Microservices has played a key role in not only enabling “Buy with Prime” on partnering websites but also in creating “Amazon as-a-Service”.
In this article, I will talk about why should product managers understand Microservices. Further, I will also talk about how should an organization transition to Microservices and establish scrum/Pod teams based on Microservices.
<h2>Why should product managers understand Microservices?</h2>
To understand this, we will need to look at the opposing end of the Microservices-based architecture which is a monolith. Let us look at this example through the lens of an e-commerce company named “iShop”.  This company sells many items online and has seen immense growth over the last few years. iShop did not worry about best practices during growth and ended up building a Monolith as shown below:
<img decoding="async" src="//wp-content/uploads/2022/08/952f9e7b-12e8-4b6e-abbf-53a1fe6622f7_Monolith_iShop.png" alt="" />
Now, imagine being the product manager for the payments team in this eCommerce company in a monolithic architectural pattern and your team wants to work to launch a buy now pay later (BNPL) functionality. It is month 3 and your team code is ready. But due to the monolithic architecture, the release team will need to coordinate among many teams, and hundreds of developers, resolve conflicts among them, merge the code into a single version, and produce a master version that waits in the queue to be moved into production. It also adds a lot of overhead to the delivery pipeline. Once the code base is built and tested, the team finds an issue with the unrelated code of the offers &amp; catalog team. The offers and catalog team takes a few weeks to correct this code. The release team will then need to rebuild and test this whole code base again. In summary, an unrelated issue of another team impacted your ability to launch BNPL. This is what the Monolith did; it created speed and agility issues to launch new product features. For organizations dependent on technology to drive growth, this created a huge bottleneck in launching new features.
<img decoding="async" src="//wp-content/uploads/2022/08/0539af95-1c71-4568-9013-3bd9f0c03183_Monolith_Release20Schedule.png" alt="" />
Microservices can be used to solve the problems identified in a monolith. Microservices &#8211; is an architectural style that structures an application as a collection of services that are
<ol>
<li>Highly maintainable and testable</li>
<li>Loosely coupled</li>
<li>Independently deployable</li>
<li>Organized around business capabilities</li>
<li>Owned by a small team</li>
</ol>
<img decoding="async" src="//wp-content/uploads/2022/08/a20d6c5f-601f-4511-b53f-d3fd4d631ee6_iShop20-20Microservices.png" alt="" />
See below for how the service-oriented architecture enables a quick release of features in production. Imagine yourself as the PM of payments who would like to launch a BNPL functionality. You can do that without dependence on other unrelated teams.
<img decoding="async" src="//wp-content/uploads/2022/08/f0e94e96-497f-47c5-93c9-5a88f4be77f9_iShop20-20MS20Release20Schedule.png" alt="" />
If this architecture is set up well, it will enable product managers with the following benefits:
<ol>
<li>Faster time to market &#8211; Teams are organized around a set of services such as Customer Support, Payments &amp; Checkout. Customer Support can work and deploy its changes without having to worry about the work occurring in Payments</li>
<li>True omnichannel experience &#8211; Build and use the same services for websites, mobile apps, and external UX concepts. To cite an example,  mobile apps,  and websites can invoke the same Payment service to initiate and complete payment (<a href="https://www.mindtheproduct.com/beyond-amazon-com-amazon-as-a-service/" target="_blank" rel="noopener">Read this article</a> on how this can be achieved)</li>
<li>Better and less complex code &#8211; Create a repository to manage the code based on services. This makes it easy to manage and deploy the code</li>
<li>Easy deployment &#8211; It reduces the overhead to the delivery pipeline. Only the code base of the service impacted will need to be rebuilt, test cases re-run before pushing the service to the production fleet.</li>
<li>Independence to choose technology stack &#8211; The enterprise does not have to choose a technology stack. Teams will have the independence to choose the technology of their choice. This works well because the integrations among various technologies are achieved using restful APIs</li>
</ol>
The above benefits outline the key reasons why product managers should understand Microservices especially when facing problems with the Monolith. Further, suppose you are already a product manager functioning in an API-first platform built on Microservices. In that case, you may have to lead and design the composition of new microservices to enable logical use cases.
<h2>How to compose Microservices?</h2>
When implemented right, Microservices can lead to amazing business benefits. The obvious next question that comes to mind is: How do I compose Microservices?
To answer this, assume you are the product head of iShop which has seen amazing growth, has a large, complex monolith application, and faces multiple issues noted above. In order to solve these issues, you plan to transition your organization around Microservices.
The benefits of Microservices are not guaranteed. In order to achieve the intended benefits, the product leader should carefully decompose the large, complex application into a set of logical services. This decomposition should occur in a way that new and changed requirements only affect a single service. How do you then decompose your application into services?
One easy way to decompose an application into services is to define services according to the business capabilities. A business capability is a concept from the business architecture modeling. This is something a business does to generate value.
To continue with the example of iShop’s eCommerce site, the business capabilities of this company can include:
<ol>
<li>Membership and user management</li>
<li>Offers and catalog</li>
<li>Orders and inventory</li>
<li>Payments and checkout</li>
<li>Customer support</li>
</ol>
Below is a sample decomposition of iShop’s eCommerce website/app into various microservices/ capabilities. I further show how the customer support organization can be broken down into pods further.
<img decoding="async" src="//wp-content/uploads/2022/08/0d074e1a-84bd-455d-b1e0-a50a9e33c274_Monolith20to20MS20Composition.png" alt="" />
These teams comprising product and engineering members should follow the below principles:
<ol>
<li>The team should not comprise more than 6-10 people</li>
<li>The team should own one OR more services</li>
<li>The team owns one OR more services that should be autonomous. The teams should be able to develop and deploy their services with minimal collaboration with other teams</li>
<li>The services owned by the teams should be cohesive. Each service should implement a set of strongly related functions</li>
<li>Each service should be loosely coupled &#8211; The implementation can be changed without affecting the clients (i.e. the same services can be called any front-end client and will not need to change every time there is a change to a service)</li>
</ol>
The resulting structure gives the following benefits:
<ol>
<li>Stability because value-generating business capabilities are relatively stable.</li>
<li>Development and product organizations become cross-functional and are organized around delivering business value rather than technical features</li>
<li>The teams become cohesive and loosely coupled</li>
</ol>
In spite of the benefits, in order to do this transition, the organizations will have to address the issue of how to identify business capabilities. Identifying business capabilities and hence services requires an understanding of the business. An organization’s business capabilities are identified by analyzing the organization’s purpose, structure, business processes, and areas of expertise. Bounded contexts are best identified using an iterative process. Good starting points for identifying business capabilities are:
<ul>
<li>organization structure &#8211; different groups within an organization might correspond to business capabilities or business capability groups.</li>
<li>high-level domain model &#8211; business capabilities often correspond to domain objects</li>
</ul>
In summary, this article discusses why product managers should understand Microservices, and how to make a transition to Microservices to achieve its intended benefits.
<h3>Discover more great content on Mind the Product</h3>
<ul>
<li><a href="https://www.mindtheproduct.com/nft-the-new-playground-for-product-designers/" target="_blank" rel="noopener">NFT: the new playground for product designers</a></li>
<li><a href="https://www.mindtheproduct.com/web3-for-product-managers/" target="_blank" rel="noopener">Web3 for product managers</a></li>
<li><a href="https://www.mindtheproduct.com/creating-for-creators-peter-yang/" target="_blank" rel="noopener">Creating for creators – Peter Yang</a></li>
</ul>
<div class="g g-21"><div class="g-single a-170"><a class="gofollow" data-track="MTcwLDIxLDEsNjA=" href="https://www.pendo.io/pendomonium/"><img decoding="async" src="https://www.mindtheproduct.com/wp-content/uploads/2024/06/MTP-Footer_ad.png" /></a></div></div>

Why should product managers understand Microservices?

Shiva Hullinakatte

Comments

Read next