P0 Issue Definition from a Product Perspective
This applies to B2B SaaS because that’s what I build. Simply put:
P0: Your clients are losing money due to your issue/bug.
P1: You are losing money due to your issue/bug.
I’m using the word “money” in my definitions because it’s tangible but “money” could mean anything that ultimately equates (or contributes) to the “return” on investment that your product is optimized to produce; e.g. impressions, pageviews, calls, GB stored, DiskWriteBytes, contract renewals, SLAs met, etc.
I’m not concerned with P2-P4 issues in this article. A ton of content already exists related to classifying and prioritizing bugs using various methods. Most are very logical but are written from an Engineering perspective.
P0 Issue Examples from the Real World
At EdgeCast, we delivered Twitter’s content via our CDN. The more content that Twitter users can consume, the more “promoted tweets” (early-days ads), Twitter could serve. People have a short attention span, and if content lags, they bounce. Thus, if we made a change to our IaaS that broke a PoP (point of presence) that was caching Twitter’s content for delivery to a geo with a ton of users, they’d serve far less content and ads. This would cost Twitter money. Therefore, it’s a P0 issue.
It’s important to note that in almost all cases, a P0 issue also costs your company money. In the example above, our SLA with Twitter had tiered pricing that reduced our revenue for content delivery from an out-of-geo (i.e. slower delivery time) PoP.
PriceMaster
At MarketShare we had a JV/Partnership with Live Nation / TicketMaster. We built an internal-facing dynamic ticket pricing platform (PriceMaster) that’s still used to this day.
The foundation was a large codebase of data ingest pipelines, Matlab routines, and mountains of data stored in DynamoDB. Every night, the scripts would run and output the optimal ticket price for each individual seat in a venue that was selling tickets to a future live event (ball game, concert, etc.).
“Orphaned seats” are those that do not have an available seat to the immediate left or right in the same aisle. This concept is extremely important in ticket pricing because people typically do not like to attend live events alone. Thus, orphaned seats are often worth far less to event-goers than are other seats. In a model, an orphaned seat can be represented as a dummy feature with a binary value (0 or 1).
The value of that single feature determines whether our model priced an orphaned seat at $20 (it’s real market value) or at $3,000 because it’s the last available seat in an otherwise sold-out section. Thus, if occupancy data for the surrounding seats was stale or interpreted incorrectly, TicketMaster wouldn’t sell the orphaned seat because it wasn’t priced correctly. This would be a P1 issue because it would cost TicketMaster sales.
Microsoft
At EdgeCast (again), Microsoft used our API to create a white-labeled CDN for their clients. Basically, they re-sold our CDN as a service in Azure… it might still be that way (I don’t know). We built tons of endpoints specifically for them.
On more than one occasion, we had bugs or bottlenecks in the DLL of our application that would cause POSTs (used to create/configure a new service) to fail or timeout. Microsoft was spending millions of dollars a day to market Azure to web-based businesses in order to sell them our white-labeled CDN. If a newly-converted user experienced an error when trying to create their first CDN service, they’d exit and wouldn’t come back. Thus, the $300+ that Microsoft spent to acquire that user was wasted. This would be a P0 issue because it was costing Microsoft money.
P1 Issue Examples from the Real World
EdgeCast MCC
We allowed SMBs to use our CDN in a self-serve paradigm through our client-facing application called the MCC (Media Control Center). Most clients had multiple (oftentimes hundreds) of content-rich sites. If we released a breaking-change to the frontend of the app, existing clients wouldn’t be able to add new domains (for content delivery) or configure existing domains. It wasn’t a huge deal for our direct clients because their websites would still be operational and deliver their content directly from their host. But, less content delivery for Edgecast meant less revenue. This would cost us money but wouldn’t cost our clients anything → P1 issue.
Sony
We delivered Sony’s device updates and drivers via Edgecast’s CDN. At some point, we realized that one of our internal delivery monitoring systems wasn’t correctly capturing data delivered from a newly deployed PoP. I’ll spare you the details on what went wrong but the result was that we were systematically undercharging Sony a significant amount (on the order of $10k) every month since the new PoP was brought online. This was a P1 issue because it wasn’t costing Sony anything -rather, it was benefiting them -but it was costing us a lot of money. Needless to say, we fixed it quickly.
Replay.io
This is a simple one. We had a $300/day marketing budget for CPC that we spent to buy traffic across social channels and search. We were using StormPath as an Identity Provider (part of our account creation workflow). A few days after we deployed a change to our app (a new integration with an analytics provider), I noticed that our conversion rate on free trials went to zero… didn’t seem right. Some investigation revealed that we inadvertently broke our integration with StormPath’s API. It cost us a thousand bucks (on wasted marketing budget) but didn’t negatively impact our existing customers or cost them anything because our product continued working → P1 issue.
