Enterprise Product Managers are a bit different compared to the others. There are certain degree of technical knowledge that you have to know in order to proceed smoothly. One particular issue that I often see is, whether to scale up a product quickly or not.

As you know that being a Product Manager for internal teams give me some confidence that I can easily extract requirements from them and scale it smoothly.

But that’s not simply the case. Let’s say that you want to create an all-in-one service to create payment system to vendor, and since you are too eager to scale it up you instantly suggest engineers to create a microservices and then struggle heavily because in the end it’s too powerful and didn’t even get enough usage from stakeholder to be considered success. Implementing microservice so quickly when you are not sure about the usage would be a big waste to do. In this case, I’m thinking maybe I should suggest a monolithic architecture instead.

Product Manager usually have pretty limited knowledge about engineering stuffs. But I do think knowledge about monolithic and microservices will be useful since product managers are the one who have more knowledge about their product phases, and thus, can give useful suggestion to engineers.

Before proceeding, I want to share the definition of monolithic and microservices.

Monolithic software is designed to be self-contained; components of the program are interconnected and interdependent rather than loosely coupled as is the case with modular software programs. In a tightly-coupled architecture, each component and its associated components must be present in order for code to be executed or compiled. [1]

Microservices are an architectural approach to building applications. As an architectural framework, microservices are distributed and loosely coupled, so one team’s changes won’t break the entire app. The benefit to using microservices is that development teams are able to rapidly build new components of apps to meet changing business needs.[2]

so we can see that the the key here is interdependency and scalability.

Monolithic are not loosely coupled, so that one change in any of the part could harm the other part as well. This architecture are pretty straightforward. It is easier to develop and build as well.

Since Microservice are loosely coupled, it can support as if there are any fix / upgrade we want to do on a concentrated part, it can be done easily. Think of it just as a building block where you can change, upgrade, and fix something without worrying that it would bring any harm to the other building blocks. Even though the interdependency part would mean greater requirement of precise testing since every building blocks are expected to have different behaviour. It is easy to scale up as well depending on the business needs.

From product manager’s perspective, having the right kind of architecture would give us a development and maintenance efficiency for any product that we’re currently building.

So I want to share my take when to suggest for monolithic and when to suggest for microservices from several aspects:

Product Phases

When our product are still on proof of concept / MVP phase, I strongly suggest to use monolithic architecture, since there is no guarantee that the product would be used often. In worst case failed product-market-fit could lead to system deprecation, so that Monolithic architecture are the better thing to build.

Meanwhile product that already achieved product-market-fit and has a significant number of loyal customers who keep coming back to use our product would be better off with microservices architecture. For example if we have an ecommerce product, there might be infrastructure dedicated to search, payment, and loyalty points.

Search services would focus more on scalability of load since the search request would be extensive. Payment would focus on reliability since it involves money in the process (we don’t want our payment to be dissapeared in the process, do we?), and Loyalty point would be heavy on converting and calculating point based on any conditions.

Forcing this type of behaviour with monolithic architecture would result on inefficiency of development time and performance, since a platform would be forced to have both extensive load balancing, reliability, and calculation where actually it isn’t necessary to do so.

Scope of Team Responsibility

On the early phase of startup, usually one team would be in charge on end-to-end process. For example, earlier there would be only one team who are in charge of end-to-end process in ecommerce marketplace from search to loyalty point. In this case, it would be easier to use monolithic architecture because limited number of team member (according to Marty Cagan, ratio are 6–10 engineers for every product manager) [3] would result on overwhelmed work, let alone if there are bug appearing everywhere.

Meanwhile, after product scales up and 1 product team would be responsible for a process (let’s say 1 team dedicated to search, 1 team dedicated to payment, and the other for loyalty point). It’s better for the architecture to be microservices. Because every team would have different metrics and OKR. Search Metrics would be their reliability of search result and load balance. Payment Metrics would be payment reliability and successfull checkout-to-payment, and Loyalty would be the correctness of calculation and conversion/redeem rate of loyalty points. Thus, makes the strategy and development roadmap different from each other.

Go-to-Market Speed

The speed to go-to-market could be critical on deciding which architecture could be best to implement. For example: if you want to release the product as soon as possible for reason such as data gathering, market testing it would be better for you to implement monolithic since you want to ship it ASAP and this product/feature still needs to be validated. We don’t want our engineer to be forced developing something so big just for it to be deprecated the next week / month.

On the contrary, if you want to plan carefully for a major product release with lots of preparation, it might be better for you to implement a microservice, especially if your product want to have a rigid value proposition to customer.

Testing Maturity

Having a monolithic means that it is easier to test, since there are no connection needed for inter service communication. If your company still have manual testing method. It would be easier to use monolithic architecture. But if you already have some kind of framework which supports automated testing, then it would best to have a microservices.

Getting the right choice at the right time

So in terms of technicality, engineers are still best at it. Even though Product Manager could be a big influence on their system architecture design since Product Managers are the one who knows the product phases, vision, and performance in terms of product market fit. So always communicate your findings and plan about the product to engineers, and help them on creating the right decision.

Reference

[1] Anonymous, Monolithic Architecture, 2016, unknown publisher

[2] Anonymous, Microservice Architecture, 2017, unknown publisher

[3] Marty Cagan, Roles and Ratios, 2007, Silicon Valley Product Group