48 Crucial Hours to Aid Palu-Donggala
How to be agile to build a time-pressing product for the greater good.
On Saturday, the 28th of September, a 7.5-magnitude earthquake struck the Indonesian island of Sulawesi, unleashing a tsunami that affected coastal settlements Palu and Donggala. About 2.4 million people are believed to have been affected, with a death toll reaching over a thousand. Residents were displaced from their homes, with limited fuel, food and water supply.
People from around Indonesia saw the news and wanted to help, but they didn’t know how. Tokopedia knew the important role it had to fill, to build a donation microsite specific for this cause and give back to its nation.
Time: 48 Hours to Live
I got a call Saturday Afternoon to build a platform for Donation Palu, it was set to launch end of day — we did it. Within one week, Tokopedia had compiled an astonishing 6 Billion Rupiah for those affected, comprising of over 53,000 donators*.
So how did we do it?
As the Product Owner of the Donations category of Tokopedia, I had an existing platform ready to be used. To meet the requirement by end of day, I had to launch an MVP (Minimum Viable Product) — To allow users to donate to Palu. The most feasible MVP was by using the existing Donation Category.
The existing Donation Category allowed users to donate to a multitude of donation organizations. I needed one additional option to donate to Palu.
When we first built the donation category, we anticipated the dynamic nature of this platform.
The purpose of this category was to allow users to not only donate to organizations but for different causes — and these different causes we could not predict the timing for.
Thus, we built the technical architecture to be scalable. The back end was dynamic enough to allow me to add another donation organization/cause through an internal tool — no development needed. I inserted the organization/cause name as “Donasi Palu”… and magic, “Donasi Palu” was an option for users to donate to. the MVP was live the same day.
Time: 47 Hours to Live
The existing Donation Category then just needed awareness. We needed an unmissable placement, one of the most expensive real estate on Tokopedia’s homepage: Top Icons.
The back end homepage was just as dynamic because so many changes happen on the homepage every single day. It had its own internal tools as well. On the internal tools, I replaced one existing icon with the “Donasi Palu” icon…press “submit” then frantically refreshed the Tokopedia App and…double magic.
There it was on the homepage, a seemingly new category called “Donasi Palu” for our millions of users to be able to donate to.
Time: 43 Hours to Live
That night I checked the ticket complaint dashboard.The number of complaint tickets for the Donation Category increased.
Users needed to find information about the cause. We needed an FAQ section.
Users needed to feel their impact. We needed a live count of funds compiled.
Users needed to know that we appreciate them. We needed a special thank you email.
These were new requirements we had to fulfill. It couldn’t be done in the current Donation Category comprising of multifaceted organizations and causes.
Donasi Palu needed its own platform that could suffice all these requirements, we needed to build the microsite immediately.
Time: 31 Hours to Live
I woke up Sunday morning, stated the new requirements and drew my microsite sketches on a notepad. I took a photo of them and sent them to the team comprising of back end and front end engineers, UX and UI designers.
They advised and measured feasibility by breaking down the tasks and estimating effort . With each feedback, I reiterated my designs. A mock up stripped to its simplest, a technical discussion happening at its most convenient — this was a Design Sprint on the go.
By the end of the day a mockup of the microsite was finalized, and the tasks for each team were clear.
Time: 12 Hours to Live
Monday morning with a coffee at hand, everyone started building their tasks.
Back End engineers had to create an API to attain live funds for front end to consume, as well as create a special thank you email.
Front End engineers had to build the microsite.
UI designers aligned on communication for banners, and had to create sizes for different social media platforms.
Operations helped create the FAQ content of the cause for the microsite.
A small team of us sat for hours in a “war room” set up for us — one centralized area for us to communicate fast and effectively.
Time: 1 Hour to Live
That afternoon the microsite was built with all requirements . We did a bug bash the last hour. We fixed the high priority bugs and gave the microsite landing page link for external parties to blast — 48 hours after receiving the call on Saturday.
At this time, Tokopedia had compiled an astonishing Rp 886,550,000… and that was just the beginning.
Donasi Palu made us learn what it really takes for us to be agile.
Configurable: Our back end had to be dynamic enough for us to be agile. I would not have been able to launch the MVP the same day, and cut through the sprint cycle if it wasn’t for the advanced internal tools developed. However, if we were to really talk about the nitty gritty, a lot of small developments happened, delaying launch time and stripping the expectation of the MVP because many components were still hardcoded.
Consistent: We should not only be fast but we have to be consistent. I always take into consideration four environments when developing a product/feature: Desktop, Mobile, Android and iOS. Our Desktop and Mobile environment are reactive. We build one code and the development is consistent on both environments. However, for Android and iOS they are two separate developments. We realized the same “Donasi Palu” category looked different on Android and iOS, and it was hard to maintain the requirements. For example, there should be a header called “Donasi Palu” in the category. For Android it was possible because the header took data from the donation organization’s name, but for iOS, the header did not take that same data and was thus empty. This was one example of many consistency issues we had to build around to meet the requirements.
We will always strive to be as configurable and consistent as possible — but this Donasi Palu development truly heightened the necessity of it if we wanted to be even more agile. These two key components would lead to faster deployment, a better MVP, easier maintenance and less bug fixes.
At the end of the day, the team did not fulfill just the requirements, the team built a platform to uplift our people affected in Palu and Donggala. Together we pooled over Rp 6,000,000,000.
But this stands true not only to this product development, be it digitalizing bill payments, securing accounts, or personalizing the homepage… Every task we do, is to prioritize uplifting the convenience of our user’s lives.
If you would like to help donate for Palu, click here
For further information on the cause and funds disbursement, click here
*This number was also comprised of Tokopedia’s corporate donation and the exchange of Tokopoints for donation.
