We killed a key feature from our MVP and built a better product 

It was just another ordinary day at work, until I stumbled upon our VP of Business Intelligence. “Zlatan, listen, we talked with several of our clients, they have issues with their SMS costs exploding.”   

The problem was obvious: bad actors were abusing clients’ application or the web to trigger SMS with a time password/code for second-factor login.  

This wasn’t a problem until this skyrocketed on a huge scale (even Elon Musk claimed that this fraud cost Twitter (now X) about 60 million USD a year). 

The first question anyone will ask: why can’t they just implement their own anti-bot solutions? Well, some are outdated, costly, or cause user friction (like hard-to-read captchas). 

But as a provider of the service (we deliver SMS to subscribers worldwide) we were responsible for doing something about it, even if fraud is not happening on our platform directly. 

Now that we understand the problem and have some clues about how it happened, we started working on a solution/product. 
 
And how do you build a product?  
 
Of course, we followed all principles such as stakeholder interviews, JTBD, and idea validation with several clients. It was a bumpy road, the domain was unfamiliar to us, and we weren’t direct consumers of the product we were building, but we trusted our data and common sense and logic.  
 
We needed the detection part and the “consuming part.” For the detection part, we worked with several clients and analyzed multiple attacks to detect patterns and vectors. Checkmark: done.  

The action part was tricky.  
 
During client discovery and talking with various stakeholders, we identified that they want to have control over who is blocked and when. This seems logical: we provide information, and you do blocking at your side. The solution was to build an API service that would send phone risk scores along with a description for each SMS attempt. 

We rushed to “get something live ASAP” and after a few months, we finally launched our MVP.  

For the sake of this text, we will use Client A and Client B – both of them were eager to start using the product.  

Initial results were great: Client A implemented an API and started to immediately block bad traffic. Our celebration didn’t last long, the number of fraudulent transactions slipping away increased day by day! 

The pressure was bad and intense, the client was losing money and patience, and the threat of client churn was real. This went on for some time, talking about issues, feeling frustrated, and how come we can’t see any pattern or problem.  

Finally, we exchanged some numbers: their SMS attempt numbers are much higher than ours! Because they block so aggressively already on their side, we didn’t have visibility of those attempts so our system couldn’t detect any anomalies at all.  

This was a completely new challenge, how to detect something if you don’t see it?  

In the meantime, Client B came with a new request: “I don’t have resources to implement your API, can you block it just on your side?”  

Our minds were blown!  

Someone will allow us to block fraud for them? Is this happening? During discovery and initial calls, this option was rejected immediately, with usual corporate reasons: our security team will not allow it, our privacy team will not allow it, our company policy doesn’t allow that, etc…  

But, as always, the future is unpredictable and this is the period when big layoffs in tech started, the IT bubble during the pandemic started to burst, and everyone was cutting costs where they could. Things that were unimaginable before now became reality. Of course, this wasn’t the only request, so we decided to support this option as well. 

This is where puzzles are sorted out: API is killing our product!  
 
Our Client B’s request to develop automatic blocking would also solve Client A problem too!  
 
Clients will not block anything anymore on their side – they will send all traffic to us, and our system will filter fraudulent ones, legitimate ones will proceed to the end user as usual. This is the moment when you feel sad and happy at the same time: you found out that it is wrong, but it happens to be a key (at that time) part of your product. 

The change was implemented quickly with immense impact. Blocking numbers were high again and the client was happy. In fact, 55% of their traffic was detected and stopped as fraudulent. This is where reality hits us: API needs to go, yesterday.  
 
Nobody is happy throwing away a couple of sprints into the garbage, but the decision was made, and we realized it was best for the client and the product. 

At the beginning of the project, I was sure: this was it; we did a good job of defining it and it will be a great MVP. I was naive – the market shift and clients needed change much faster than we anticipated. Some features, even good on paper, can be validated only on production. 

At that time, a change of scope and throwing pieces of product into a bin looked like personal and team failure. Could I predict this? Why did we waste time on this?  

Now, after a year and a half, I am sure that we succeeded, not because of the initial idea, but because of how we adapted, rejected old premises, and changed a big part of our product. 

We are building a new product now, and I know we will fail with some of the features and throw them away, but now I watch that as learning and improvement, not failing anymore.  

Fear of failure will often result in no action at all. It is OK to fail as long as you adapt and learn something from it.  

Sometimes it is OK to just kill a product too, but this is a story for another time.  

The product Zlatan wrote about is Infobip Signals. If you want to learn how it works or learn how to fight SMS Pumping, check these links.