Delivering a New Beta Product on a Tight Deadline
3 February, 2021
Staff Software Engineer at Dropbox
We had to deliver a new product on a very tight deadline, and as technical lead engineer, I had to decide between two design options. We could hack something together that would work, based on the old way of building things and that would have more features but at the cost of maintainability. In a nutshell, something like a smoke-and-mirrors for the demo or beta. On the other hand, we could try to build our thing on the new stack, even though it was not mature yet and would have less to show. But it would be built on a more solid foundation that could be used later to build into a product. I encountered a dilemma -- should we build a throwaway thing or try to build something that would be less capable but better situated for the long run?
The stack was fairly new, and we had dependencies on other teams that had their own things to do. If we were to start using their stack, we would need support from them that they didn't have a lot of margin to give.
Supported by our product lead, I decided to make a case that we should build it on the new stack though that option would be less featureful and harder to get the support we needed. My decision was mainly motivated by our plans to -- following our big marketing demo -- rapidly release it to more customers and build what we were doing based on customer feedback. Also, the company had recently refocused on getting customer feedback and building it into our products. We keenly felt that pressure to build things quickly and get rapid feedback so that we could reincorporate those improvements and build something more in line with what customers needed rather than on what we decided in our ivory tower.
I talked to a great number of product managers and did many engineering reviews with the people who were building the platform we were considering and who would have to support us. Those conservations helped me strengthen my decision to go with the new stack but also helped me collect robust feedback on our approach.
Once we decided we needed to build it on the new stack, we had to go and convince those other teams with whom we had dependencies to support us. We had to come up with a concrete plan for them to show what we needed their help with. Also, we built an integrated schedule that would help us minimize the impact on them and increase the likeliness of their support to build out the infrastructure we needed. Needless to say, that required a lot of proactive planning.
Typically, we would make a request, and rather than waiting to see when they could get around to it, we would work hard to get it on their roadmap and provide our help with the critical things at the critical moments. By doing so, we were able to successfully include our requests into their plan and work with them closely to get the support we needed.
We built and released the demo by the deadline. However, it turned out, in the end, that our product was cut from the demo because of time reasons, and we didn't even get to show it. But we released it to our customers when we said we would and were able to take that over the next six months and develop it into a product for an open beta that anyone could sign up to use.
The long-term goal of taking a product to a wide audience in a short period of time implied that it was worth the extra care and pain to build it the right way upfront so that we could get that feedback and iterate on it. If we had gone the other way, we would have had something that would look nicer and perhaps more people would like, but it would have been much more difficult to turn that into a real product six months later when we needed to release it to the world.
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
David Kormushoff, Director at Koho, recalls how he galvanized his team to tackle a time-sensitive problem, sharing his tips on how to shift chaos into calm.
Director at Koho
Matias Pizarro, CTO and VP of Residents at ComunidadFeliz, recalls a time in his early career when he took a technology risk that had wide-ranging benefits to his product's user experience.
CTO and VP of Residents at ComunidadFeliz
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.