Delivering a New Beta Product on a Tight Deadline
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.
Connect and Learn with the Best Eng Leaders
We will send you a weekly newsletter with new mentors, circles, peer groups, content, webinars,bounties and free events.