Back to resources

Delivering a New Beta Product on a Tight Deadline

Product
Deadlines

3 February, 2021

Andrew Schamp

Andrew Schamp

Staff Software Engineer at Dropbox

Andrew Schamp, Software Engineer at Dropbox, recalls how he made a design decision using a tradeoff analysis that made them deliver a new beta product on a tight deadline.

Problem

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.

Actions taken

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.

Lessons learned

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.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader


Related stories

Scaling a Team in Two Parts: The Product and Manager

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.

Managing Expectations
Product
Scaling Team
Leadership
Meetings
Viswa Mani Kiran Peddinti

Viswa Mani Kiran Peddinti

Sr Engineering Manager at Instacart

How Product Management Chose Me

23 June

My accidental journey into product management

Product
Personal Growth
New PM
Career Path
Michael Castro

Michael Castro

Sr. Manager, Product Management at Capital One

How Product Marketing Can (and Should) Help Product Development

20 June

Pavel Safarik, Head of Product at ROI Hunter, discusses the frequently overlooked role of product marketing in getting high user adoption rates for your product.

Goal Setting
Product Team
Product
Different Skillsets
Cross-Functional Collaboration
Pavel Safarik

Pavel Safarik

Head of Product at ROI Hunter

How to Successfully Rebuild Your Product

6 June

Adir Nashawi, Senior Product Manager at Hibob, shares his insight and experience from rebuilding a product to handle many feature requests and offerings.

Customers
Product
Dev Processes
Users
Prioritization
Adir Nashawi

Adir Nashawi

Senior Product Manager at Hibob

How to Empower Teams to Build Out a Product Portfolio During Company Growth

6 June

Ivo Minjauw, Global Product Director at OTA Insight, discusses the importance of structuring your teams when undergoing company growth.

Alignment
Goal Setting
Product
Ownership
Performance
Ivo Minjauw

Ivo Minjauw

Global Product Director at OTA Insight