The Right Way to Ship Features in a Startup
11 November, 2021
null null
null at DoorDash
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.
Discover Plato
Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader
Related stories
10 December
Supporting principles on why being data led (not driven) helps with the story telling.
Vikash Chhaganlal
Head of Engineering at Xero
5 December
Your Org Team may as well be a Sports team. Let's explore how this cohesive, multi-skilled team can be optimized for Great Group Playoff.

Jaroslav Pantsjoha
Google Cloud Practice lead at Contino
2 August
Viswa Mani Kiran Peddinti, Sr Engineering Manager at Instacart, walks through his experience scaling a team, product and his skills as a leader.

Viswa Mani Kiran Peddinti
Sr Engineering Manager at Instacart
12 July
A proposal for how to create an org structure that will deliver software systems that you want, not ones you get stuck with.

Ram Singh
Principal / Founder at id8 inc
23 June
My accidental journey into product management

Michael Castro
Sr. Manager, Product Management at Capital One