Did you know how Amazon Web Services was born?

In early 2000s Amazon was growing quickly and hiring new software engineers, yet they were still finding, in spite of the additional people, they weren’t building applications any faster…The internal teams at Amazon required a set of common infrastructure services everyone could access without reinventing the wheel every time, and that’s precisely what Amazon set out to build — and that’s when they began to realise they might have something bigger.

This is an excerpt from TechCrunch. AWS was an extraordinary solution to a technical debt.

When product discovery is behind you or you are running a very stable product line, you tend to accumulate technical debt. Usually we attribute the building of technical debt to short-term solutions that your development team has adopted over a period of time which starts affecting the agility of the product. Product Managers usually tend to think that technical debts falls into the arena of the engineering team; however experience tells me that Product Managers have a huge role in unearthing the right technical debts.

Scenarios where you can unearth tech-debts:

1. Prototype evolving into full-fledged business: Product discovery phase may not sometimes build something that can last because that is not the goal during discovery phase. However, when prototypes attain market fitment, the focus turns towards time to market. When you later see your non-functional metrics like speed and up-time falling over a period of time – you must question why it is happening till you find the root cause. Most often adding hardware is not the only solution scaling problems, the root cause will usually be the short cuts you took in the initial phases.
2. Repetitive work not taking advantage of economies of scale: It is possible that you do some feature work that kind of finds traction and more similar ones flows in. However you see that developers take same amount of time for each such feature work with lot of similarities. This must ring alarm bells in your head – because something that started as one-off is now a generic requirement – so the product needs to be architected differently.
3.  Unavoidable bespoke work spawning off: This is a product manager’s nightmare. Early stages of market fitment will lead to bespoke work on the product, more so when starved financially. This can lead to a para-product line of its own. Most often development teams get bogged down supporting multiple flavours of the supposedly same product. However, there are silver linings in such cases; make the product more generic and have a team (typically “professional services”) who can build upon the generic product and customise as required.
4. Supporting multiple versions of the underlying platform: Usually tech-debts are a result of difficulties in maintaining scores of platforms. Product Managers must have the courage to retire support for platforms that have aged instead of playing gymnastics with multiple platforms.

Tech-debts do not pay off immediately but does over a period of time, however when rightly chosen, builds an advantage that the competition cannot build overnight. That is the reason why prioritising the tech-debts is a tough in-depth exercise and should take into account the following:

• Long term product strategy: If you are struggling to find what this is, then do not work on the tech-debts.
• Evolution of the eco-system: Sometimes changes in the eco-system is on the horizon and in such cases a wait and watch approach is advised.
• Opportunity in complementary product lines: This one is big. Some solution to tech debts can be something many outside the company also needs. The birth of Amazon Web Services is one big example of how tech debt led to this highly successful company.

So, are you not excited to create the next AWS!

Image Attribution: StockMonkeys.com