The Right Way to Ship Features in a Startup
11 November, 2021
null at DoorDash
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.
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.
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.
- 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.
Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader
Jord Sips, Senior Product Manager at Mews, shares his expertise on a common challenge for product managers – finding root causes and solutions.
Senior Product Manager at Mews
Snehal Shaha, Lead Technical Program Manager at Momentive (fka SurveyMonkey), details her short-term technical strategy to unify processes among teams following an acquisition.
Senior EPM/TPM at Apple Inc.
Pavel Safarik, Head of Product at ROI Hunter, shares his insights on how to deal with disagreements about prioritization when building a product.
Head of Product at ROI Hunter
Sourabh Sahay, Engineering Manager at Meta, discusses how talent acquisition can be made more efficient by refining the hiring processes.
Engineering Manager at Meta (Facebook, Oculus, & Family of Apps)
Brad Jayakody outlines the roadmap to maintaining a healthy balance between technical debt and team growth. However, just as balancing acts go it is important to have a strong foundation.
Director of Engineering at Motorway
You're a great engineer.
Become a great engineering leader.
Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.