QH #4: Why Technical Decisions Matter in Product

Product Managers need to be involved in technical decisions

This is the fourth installment of my “Quick Hitter” (QH) series devoted to delivering a lesson or insight you can digest in a short amount of time.

TL;DR

If you are in product management, I can’t stress enough the importance of digging deep into the technical decisions with your engineering counterparts as these decisions can have broad implications downstream on the business and your customers.

Guidance

Show up to the architecture review sessions, listen, and provide input specifically on the trade-offs in customer experience and impact on the business. I was fortunate enough to spend a bit of time as an engineer and architect where topics like dependency management, fault tolerance, and scalability of infrastructure are commonplace. These conversations should not be delegated and isolated to engineering. The quality and resiliency of your products (and services) are directly dependent on the systems and infrastructure they are built on. Think through the trade-offs of those design choices with engineering. Avoid getting tunnel vision on any specific aspect of your product and thinking that engineering will take care of all the technical bits. Get involved in these critical decision points.

Example

A common trade-off and decision point that afflicts the hyperscalers is the question of creating a circular dependency. The prime example is this is AWS S3. Do you follow the DRY principle and have every service take a dependency on S3 and introduce a single point of failure? Or do services roll their own? One school of thought is to take the dependency and build a better, more robust, resilient dependency. Another school of thought is to isolate and build those dependencies within your service. The decision comes down to the service you’re building, but 9/10 times I agree with the former, follow DRY, take the dependency, and take advantage of the efficiency gains and economies of scale. Not to mention, your centralized service becomes more resilient over time (gotta love dogfooding) and your overall architecture less complex. In rare instances you can’t follow this path, go with a failover strategy that hedges against the single point of failure and complete isolation. If your shared dependency fails, you can failover to the isolated dependency, albeit this introduces more complexity. Either path significantly impacts your business in terms of cost and customer experience in terms of quality of service.

My Ask

Thank you for reading this article. I would be very grateful if you complete one or all of the three actions below. Thank you!

1. Like this article by using the ♥︎ button at the top or bottom of this page.

2. Share this article with others.

3. Subscribe to the elastic tier newsletter! *note* please check your junk mail if you cannot find it