What we learned 1 year after launching StashAway

Photo credit: Rawpixel

This article was co-authored by Gerald Yeo, one of the first engineers to join StashAway.

Our product has been live for a year now. It took about eight months to build the initial product and, in the subsequent year, our processes and priorities have greatly changed.

In the beginning, our objective was to build and ship the product as fast as we could. Now, we juggle many objectives: improve the existing product, add new features and products, update the infrastructure to handle the exponentially increasing volume, and expand internationally, to name a few.

We’ve also naturally become more open, cross-functional, collaborative, and democratic because we slowed down and became strategic alongside the business team. Here are the lessons we learned.

Know when to move fast

A year after launching the product, we realized that we needed to fix the things we had to sacrifice as we moved fast. But it was good that we launched quickly because we were able to get feedback immediately and improve our product accordingly.

If you want to build a future-proof solution that encompasses every possible issue you’ll eventually face, it’ll take a long time to launch the product. A product for 200 people doesn’t work for 10,000 people. So, build a product that caters to 100 users first. Then, when your users grow to 200, tear your product down and build one for 1,000 users. That way, you can build the best experience for your customers in the fastest way possible.

Moving fast comes with a price. We had to make a decision between launching fast and building a product for long-term use. But it’s always a matter of striking that balance. Ultimately, launching is more important than perfection.

Know when to slow down

The decision-making process at a startup may initially use a top-down approach. You don’t want to deal with too many decisions or discussions, which may delay your product launch. Then, once the product is launched, you can be more strategic in your planning.

In the past, the product team would design the screens, the developers would say, “OK,” and, after some discussion, we’d say, “OK, it will take five days.”

Now, we get to be strategic. We’ve restructured how the product team communicates with the development team so that we have longer-term roadmaps and a more collaborative culture.

One thing we do is play scrum poker to develop a plan. We put all the requirements for both the product side and the business side up on a screen. Then, everyone on the tech team votes on how long they think each feature will take (we do this before a sprint). Outliers explain their points of view, and then we try to incorporate their thoughts into our estimation.

Communicate early and often with the business team

Manage expectations