Product Categories — Pain Killers, Vitamins, and Steroids

Product Types

After some soul searching and meditation (not really), Iʼve come to accept that products generally fit into one of these broad criteria. Itʼs not to say others donʼt exists, but if you squint hard enough, this categorisation will most likely work.

Pain Killers

This is a product that solves an obvious problem. It gives you instant relief and the pain is subdued. Panadol, Advil, and Tylenol are what come to my mind when I think of products in this category. To make this a bit more relatable to us (in tech), letʼs look at monitoring or alerting platforms such as Datadog or PagerDuty. Itʼs clear that we can live without either one of these products but, for a few seconds, think of a world where these solutions donʼt exist (or are not readily available). In the worst case scenario, weʼll have to rely on our customers to tell us when something isnʼt working — not great. These types of products exploit and provide relief from obvious pain. Customers already know they have a problem and you are providing a solution. With this type of product, customers are willing to accept the sharp edges since they need the immediate relief.


As Iʼve gotten older more experience and forced myself to accept the fallacy that my grey hair is a sign of wisdom, Iʼve come to appreciate vitamins a lot more. In other words, you donʼt realise you need these products until itʼs too late. My bones are now too weak and in need of massive amounts of calcium that I should have been taking in my 20s, oh the glory days. When I was with AWS, I ran Simple Queue Service (SQS). Internally, we were dogmatic about using SQS when communicating between services (unless you needed sub milliseconds latency/synchronous responses) because it gave the service superior levels of resiliency in case down stream services were operating in a degraded mode. AWS is dogmatic about this because customer obsession and years of outages forced AWS to think about architecting services to be highly available and to avoid single points of failure (where possible). Letʼs be honest — If any of us were to start our own company today with a product that had a snazzy UI and a bunch of services on the backend, itʼs highly unlikely that we would worry too much about scale and resiliency out of the gate. We would focus on time-to-market and adoption (i.e. monthly active users / MAU) before worrying about scale or decoupling our synchronous dependencies. The point is that products that fall into this category have the most difficult time growing its user bases. Customerʼs will only realise they need products that fall into this category after theyʼve experienced the pain these products are trying to mitigate (e.g. scale and resiliency in the case of SQS). You can alleviate this with a fantastic marketing team that can communicate an airtight value proposition to your addressable market. Products in this category have to go above and beyond to help customers solve their problems. This is because products in this category help customers get better and faster only if they choose to invest. Customers have less patience for 💩. They want a crisp and sharp experience or they will quickly divest.

Graduating from Vitamin to Pain Killer

Products such as Facebook, Instagram, and Pinterest have graduated from vitamin to pain killers. These products started off as vitamins (no one knew they wanted/needed/craved them) but are a key source of information for a large part of the population (large being relative …). Some of us even rely on these products as our primary source of world, local, social, and tech news.


Yup, this category is exactly what you thought it would be. It makes you better at what you already do. For us, think of NoSQL databases when compared to relational ones. Relational DBs are awesome and theyʼll chug along, but NoSQL DBs will give you far greater levels of performance due to their inherent denormalised architecture.

Crossing the Chasm

Regardless of the type of product that you own, work on, or have invented, one of the universally accepted adoption patterns, as defined by Geoffery Moore, is as follows -

  • Obsess over customer experience
  • Define your milestones and metrics early and track them obsessively
  • Pivot early (with data and conviction)
  • Donʼt be afraid to invent
  • Take risks and fail



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store