For those reading this with a PLG (Product-Led Growth) background, the assertion that there is no meaningful difference between bug and feature request may seem like a no-brainer. Others, however, may consider this claim strange or even ridiculous. Let me attempt to change your mind.

## Utilitarianism vs Deontology

First, let's start with a brief philosophy lesson. I promise it's relevant. Those who are fans of the philosophy of Netflix's "The Good Place" may be familiar with these two ethical theories. For those that aren't, utilitarianism posits that the action that does the most good for the most people is the one that is morally just. Deontology, on the other hand, asserts that some actions are inherently good while others are inherently bad.

An important criticism of utilitarianism is that it can justify inflicting undeserving suffering on one if it will provide a positive outcome for others. For example, forcing a person with a specific set of genetic traits to undergo potentially invasive painful medical procedures to potentially help others.

Deontology also has its set of criticisms. Here the most relevant one is that it doesn't consider the outcome of the action, only the action itself. For example, a follower of deontology would be unable to lie even if it were to spare someone needless emotional distress.

PLG vs. SLG

A quick definition of these two growth strategies provides further context to this discussion. PLG stands for Product-Led Growth, and it suggests that if a product is really good and continues to adapt to serve the needs of its users, it will find product-market fit and grow without the need for significant marketing and sales investments. On the other hand, SLG stands for Sales-Led Growth, which follows a more traditional approach, particularly for B2B software, where you have a sales team that ideally drives adoption and growth in the market.

What is a bug?

This depends on who you ask. Most sitting on the developer's side of the screen will say something like, a bug is something that doesn't work, something that's broken. Someone sitting on the end user's side of the screen will probably say something similar. However, they do not know the intent, so what they may see as a bug may, in fact, have been intentional.

What is a feature request?

Again, this depends on who you ask. From the developer's side of the screen, it's likely something new that the end-user wants to be added to the product. It may also extend to a change the end-user would like made in the product.

However, from the end user's side of the screen, that change or new feature may not feel like a feature request because it is something they would have reasonably expected.

Why does it matter?

Here's where we get to the really contentious part of this argument. Before you read on, take a moment to think about why you think differentiating between bug and feature request is important.

Here are some reasons I've been given:

• To determine priority
• To measure an individual or teams code quality
• To measure productivity
• For ticket routing

Coming from a startup that built B2C software with a team of only 12 and over a million users, some of these were foreign concepts to me due to the small size of our company. However, a business degree and lots of reading gave me some insight into where my colleagues at DevRev were coming from.

I'll address each of these but let's start with a story.

Story Time

I've always liked being the voice of the people, happy to put myself on the line when I was sure of the right thing to do, so I ended up practicing PLG before I ever heard of it.

Still, early in my career, I was going back and forth with developers over whether something was a bug or a feature request (if you're a developer, product manager, or support engineer, you have absolutely had this argument at some point). We always put out MVPs in service of being first to market, which had greatly contributed to the company's success; however, it also meant we'd go to market without features that a reasonable end user would probably expect.

This was one of those situations. As the voice of the user, I made the argument that not having it caused significant confusion, and the end-users often interpreted it as a bug and were understandably upset. I was met with the explanation that it was a feature request because we knew that it often wouldn't work and would require significant resources to make it fully operational.

After 15 minutes (and countless previous conversations) of going around in circles arguing about whether it was a bug or a feature request, I finally said with a little more force and frustration than I'd intended, "It doesn't matter if it's a bug or a feature request, from the end user's point of view it is something they expected to work and doesn't!"

Unfortunately, it didn't get that item fixed during my tenure at the company, but the concept stuck and helped us start making more user-centric product development decisions.

How does this all relate?

Great question. Referring back to the list of arguments above, let's start with Determining priority. Followers of Deontology would likely say, you should fix the bug because it's the right thing to do. However, the bug may be something that only inconveniences about 5% of your users, whereas there's a new feature that would significantly improve the experience for 80% of your users. With your limited resources, followers of deontology would still fix the bug.

On the other hand, followers of utilitarianism would work on the new feature because it does the greatest good for the greatest number of users. However, utilitarianism here has its own drawbacks. Just because a feature is requested by a significant number of users doesn't mean it is the best business decision for the company, particularly in cases where it requires significant resources but does not offer leverage over competitors' offerings.

The next two arguments, To Measure Code Quality and Productivity, are difficult topics. It's very human to want to quantify everything, give it a numerical score and determine if it's moving up or down, but it's been proven this isn't an exact science. The old approach was to measure by the number of lines of code written, but that's really nonsense considering it encouraged writing verbose, complex code rather than parsimonious efficient code. Here I'd refer to an article written by one of our founders Manoj Agarwal for Forbes.

The last argument, For Ticket Routing, is especially interesting because it is something the DevRev platform essentially eliminates by separating the end-user language from what the developer specifically works on without sacrificing the important context often contained in tickets. This means routing is done by the dev area of expertise rather than whose turn it is to address tickets.

The Cultural Shift of PLG Teams

There is an added benefit of getting rid of the distinction between bug and feature request outside of improving customer centricity, eliminating false prioritization, and minimizing sub-optimal routing of tasks.

It creates a natural shift towards a more collaborative culture by minimizing the stigma that seems to come with the word "bug." By removing it from our vocabulary, you no longer have a developer say they're "just doing bug fixes" but instead talking about their work in the context of the impact it is actually having.

Calling something a bug has an implicit element of blame to it making one feel like they're stuck doing tedious cleaning work rather than impactful development (whether or not this is actually the case). On the other hand, as builders, we are always drawn to making something new as a feature request implies. To quote Anoop Dawar, "I don't want to get into the debate of a feature versus a bug, so I use the word improvement."

So, what do we call it?

In our ecosystem, we simply call it a ticket. Tickets describe what an end-user is experiencing without the classification of "bug" or "feature request," thereby avoiding the trap of false prioritization based on these categories allowing prioritization to be determined based on the wider business goals. These tickets are then mapped to one or more issues. Issues describe what the developer is working on. This system allows the user-facing ticket to remain user-centric in language and the developer-facing issues to remain developer-centric. It is a many-to-many relationship as well, which means that developers are working on real issues related to their area of expertise instead of trying to clear end-user tickets that may really span multiple teams.

With this in mind, we find that the argument of bug vs. feature request is a distinction without a difference in a PLG-oriented company. To execute well on PLG, we must follow utilitarianism (within reason) to benefit as many end-users as possible in the decision-making. To that end, it doesn't matter what the work item is called. All that matters is that the end user's experience is improved.