The Right Way to Ship Features in a Startup

Problem

We had a feature that we wanted to launch, but we were not sure whether it was going to be beneficial or harmful to our customers. All we wanted to do was an experiment with the app, and so the first time we built it, it was super hacky. We shimmed it into an existing system and data store because we were aware that it would be exposed to a small portion of the traffic to get the data points back. After a couple of weeks, we knew that it had the potential to bring a significant change to our ecosystem. We continued with the data analysis, but we found out that it was not sustainable with its construction. If we wanted to ship it to, let’s say, 50% of our customers, the current system would horribly fail.

Actions taken

We turned the experiment off and got rid of the entire POC that I had built in order to build the actual system. We proceeded with the plan since the data had shown us that it would work and that our customers would like it.

Split Things into Smaller Columns:

We stood its own service and data store because of the amount of traffic it would be sustaining. We worked through and explained why something wouldn’t work the way it should. We did this as a POC because we could do it in a day and start getting the data we needed, which would tell us that it’s worthwhile to stand up the infrastructure to build it.

Even if it’s a fully managed platform, there were a lot of things that needed to be done to make the system secure. Therefore, for the POC, we pushed it into the existing system to get the data. After that, we broke it down into smaller chunks and added all the tasks to our sprint of the different features we wanted to add. Not forgetting to add a few to our backlog for future plans.

Shipping Products:

It took us all week to get set up and ship the feature. We knew that we had a feature built in a sustainable way, which was going to work. We collaborated with the engineering and product managers. We launched it to all of our customers, which made them happy because they were getting better performance. We also ended up saving a lot of cash for the business.

Lessons learned

• Make sure to have a cross-team agreement and transparency so that no one’s surprised about anything. Make sure that all concerned parties are aware of the commitments and what they are to do on their part.
• End management is not product management. One of the common problems in a startup is that these two concepts get conflated. End managers should be concerned with the engineering soundness at first and then ship the products smoothly.