Is removing features from your product the key to success?
There’s a feature in the automated categories app that:
– Massively slows down processing of product catalog
– Create an inconsistent (and worse) customer experience.
– Add complexity to the codebase
So, it’s gone. 😘 👋
Product management is criminally underrated. And I’m now experiencing this firsthand of how valuable a skill it is. When building my app, I think that I’ve been sort of careful around which features I do and don’t add. And certainly, there are some that are still on the to do list, the wait and see list.
But this week I’m actually removing a feature. And so I wanted to share a little bit in terms of why on earth I’m doing that. We’re still at a very early stage in terms of the number of customers and subscribers. But I feel like this is the right thing to do.
So when managing a role, I’ve got various different fields that you can use to say whether or not a product should be in this category or not.
And one of them is variant option name and similarly, we have another one called modifier option name, which allows you to create a rule based on the variants within a product. And I thought this would be helpful for those that, you know, this is a good way of differentiating between product types. So you know that all of the t-shirts have t-shirt size, etc. etc.
And that’s a good way of kind of collecting your products together and saying they should be in this category. But, you know, some of the nuance, that once you get into it by making requests to BigCommerce for all of my products. So, you know, there’s times when I want to go through a customer’s entire product catalog.
And so I want to make sure that I can do that as quickly as possible. Now, if you do request and you see here, if you do request options or modifiers, which is the variant options or modifiers customizations, you can only request 10 products per API request. Now, going into that, if you’ve got a hundred thousand products, just as an example.
And we’ve already got stores where we’re managing a hundred thousand products. If you’re going to request 10 products per request, you’ve got 10,000 API requests you need to make, to have gone through the entire catalog. Similarly got the same catalog size, but you can make 250 products or you get 250 products in each request. You only need 400 API requests.
Obviously, an awful lot less than 10,000, but assuming one request per second is made, that’s the difference between just under seven minutes and three hours to go through the entire product catalog. And that just feels like it’s a feature that is not worth that. It’s not worth the complexity I’ve seen in the codebase because I now need to determine whether or not I can request 250 products or I can only request 10. So there’s the complexity there. There’s complexity when it comes to from the customer perspective because they now don’t know how quickly it’s going to take to, you know, they’re, they’re making product changes, but not seeing them immediately.
And, it’s going to take a long time to trickle through, and then there’s the knock-on effect from a infrastructure perspective, that’s a long time spent doing a full sync on a single customer. So removing this feature means that we’ve kind of got a much better experience. There’s less code to manage. You know, the experience from a customer’s perspective is much more consistent, we can get through entire catalogs much, much quicker. So it feels like the right thing to do. And looking through the 300 categories where we’ve already got in our, in our database, there’s only one person that has created one category rule using these options. So it feels like the right time now to remove that feature, look somewhere else for benefits that are going to mean people subscribe. See if I see if I’m wrong here and see if we get loads of requests coming in next week because this feature has been removed, but I think this is the right time to remove a feature to continue making this app better.