Is It a Bug or a Feature?

by Sean Boyce
bug in the grass

That’s not a feature request, that’s a bug!

Your support team thinks it’s a bug.  Your engineering team thinks it’s a feature request.  Who’s right? Well ultimately the customer, but the point is that this dialogue happens at a lot of product companies and it’s a symptom of a larger problem.

This in-fighting happens due to a lack of process and data.  The confusion will mount between your engineering and support teams because they have different perspectives on the situation.  Ultimately, you want the customer to be happy, so what should you do?

Create a strong requirements gathering process

Gathering product requirements is critical to ensuring your product is successful.  If your requirements gathering process is lacking then you product will be as well. When gathering requirements, you need to thoroughly evaluate the problem that needs to be solved.  What is the problem that your product needs to solve? Who experiences it? What are they doing to solve it today? These questions set the stage for how important the solution is and what it will be compared against when evaluating how successfully your product has solved your customer’s problem.

Build a solid product requirements document (PRD) template

A strong PRD template will help improve communication between your functional teams.  The basics of a strong PRD template include:

Get our awesome product content delivered daily-ish to your inbox

  • The problem that needs to be solved (Objective)
  • How the solution is expected to work (Features)
  • Who benefits from it and why that’s important (Use Cases)

Gather multiple data points for new requests

Changing requirements after the work to build a feature is already in progress will only make your problems worse.  That’s why it’s important to gather multiple data points for new feature request right off the bat. In fact, you should always resist building a feature for only one customer.  A product business succeeds by building solutions to problems experienced by many customers.  

When filling out your product requirements document (PRD), ensure you are including data from multiple customers whenever possible.  If you can’t get data from multiple customers, then this feature should be pushed down the list of priorities until that data becomes available.  

Wondering whether or not your product requirements process is up to the task?  Let’s talk it through, email me at sean@nxtstep.io or visit us on the web at NxtStep.

To get product stories like this one delivered right to your inbox – sign up for my emails or subscribe to my YouTube channel.

Related posts