Product Categories — Pain Killers, Vitamins, and Steroids

Zak Islam
5 min readJul 14, 2022

I’ve had the fortunate experience of working with some awesome product managers through out my career and have also been influenced by a few celebrities (Nir Eyal, Geoffery Moore, Eric Ries) who have helped shape the way I think about delivering value to customers. An analogy that Iʼve learned to leverage to classify products and the value they deliver is pain killers, vitamins, and steroids. Once you deeply understand the problem your product solves and the value it delivers, you can figure out your go to market strategy (see below — Crossing the Chasm) and so on.

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.

Check out the summary of Hooked: How to Build Habit-Forming Products by Nir Eyal -

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.

The biggest challenge product leaders faces is how to we make this happen for their products?


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.

Products that fit into this category donʼt solve an immediate pain but customers are willing to pay for them because the value they get is obvious and customers are willing to put up with some more complexity.

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 -

This is relevant to us in a few ways. We can take shortcuts (i.e. MVP) to get to the innovators and early adopters, but weʼll struggle to see adoption with the mainstream market if we donʼt deliver the crisp and sharp experience that the majority (early, late, and laggards) of our customers desire. The experience we deliver as a vitamin type product becomes even more critical to get right because many of our customers may not know that they need us. The experience has to speak for itself!

If you are not meeting the adoption (# of users using your product) or revenue metrics, think critically about staying the course (with changes to technology, marketing, or business development strategies) or pivoting.

Lastly, some lessons that Iʼve learned throughout my career when thinking about delivering customer value are:

  • 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