Disclaimer: The thoughts and opinions expressed in this piece are my own and in no way represent my former employer. Also, Presto is still in active development, but I've since left the team; this post only covers my tenure up 'til then. So technically this should be a "mid-mortem"...?

© Presto Universe

Presto is an omni-channel lifestyle services app for Malaysia, built around an e-wallet and payments platform. That's quite the mouthful of a description- I guess if we're really going to be trendy about it, we could call it a super app, though I never did like the term- more on this later.

To elaborate a bit: we provide users with one-stop access to lifestyle services (movie ticketing, flights, bill payments, etc.). We also give them the means to pay for services through our payments platform, where users pay using their Presto e-wallet or via more traditional methods like credit cards. The omni-channel part really comes into play here, as we support online-to-offline retail merchants through QR-based payments.

My team and I started working on Presto back in 2017. For most of us, it was our first experience building a product. As I mentioned before, my experience up to that point had always been with projects. And as with any first-time venture, there were a lot of, shall we say, learning opportunities along the way.

It was also my first experience in this role mishmash of product manager and engineering lead, and that kept me flip-flopping between the feelings of excitement at the impact I had with the role, and the sense of being overwhelmed at the amount of things (and people) for which I was responsible.

This is an initial attempt at distilling some of those experiences into some personal insights on the product development process. Given I was often at the intersection of business, product, and engineering, I've taken learnings from all of those perspectives.

1. A strong, well-defined business direction is essential.

I mentioned at the start of this post that I don't like the term super app. I don't like it because it implies a dilution of business focus in favour of service consolidation, something that not every team is equipped to handle, much less a small one.

The main problem with building a super app isn't building the actual tech; it's in building traction. Without a sizeable user base, the question becomes, "Why use your app?" To me, this strategy makes sense if you have grown big enough that a lot of people look to you to fill a specific need (i.e. become almost like a commodity) . That or you have deep pockets- if there's one thing that (temporarily) attracts users, it's cash back.

I won't talk much about business strategy beyond this point as I also don't have enough information to make judgment calls about Presto's overall strategy.

But even with a limited perspective, it's evident that having a focused business direction can only be advantageous for product development. Much of the tricky parts of development come down to balancing building features with time-to-market. You always want to move fast, but you can only do so with the right set of viable features- a minimum viable product (MVP) in other words. And that can best be achieved with a clear focus.

For what it's worth, I believe Presto is heading in the right direction. Presto has recently become siblings with Presto Mall (formerly 11street.my), one of Malaysia's top e-commerce portals, and with that collaboration comes traction and a stable vertical around which to build the rest of its ecosystem.

2. Be prepared for pivots.

Presto, 2017 to 2019 (low-res screens for emphasis)

Presto started out as a social marketing e-commerce app, in the vein of Groupon and other group shopping apps. We featured "deals" with discounted prices, but our main differentiator was providing a sliding scale of cash back users could earn, that increased the more people you shared the deal with, and the more people that bought the deal.

That sounds like a far cry from what I just told you Presto is, right? Where are all the other services? Where's the e-wallet?

In fact, we actually built the e-wallet first, before everything else! We were, however, unable to launch it during that time, and so we had to quickly pivot to something else, this "something else" being the aforementioned idea.

We eventually ended up putting back the e-wallet functions. And then we pivoted again, transforming our app into a lifestyle services and e-wallet app than one that's social marketing-focused.

The funny thing was that by the time we merged the e-wallet code back, our technical knowledge had grown, and this code was one of the first things we wanted to refactor.

This functions well as a corollary to my first point: no matter how strong your focus is, circumstances beyond your control may still force you to pivot in a totally different direction, though hopefully for the better.

3. Make technology serve the product.

Engineering has to keep up with the pace of business and product teams. In a very real way, the pursuit of technical perfection (or at least such pursuits that lead to bike-shedding) are the enemy of productive engineering teams.

That's not to discount the value of well-designed, thoughtful system architectures- something that enables engineers to implement features at a fast pace, with sufficient extensibility, and of a good level of quality. But a key takeaway for me while working on Presto was that development speed forms a big part of said value, especially in a product startup environment.

Prioritise features that provide the most business impact. This statement at first seems like it should be directed at the product team, but I think it serves most effectively as a reminder to engineers that whatever things we build by themselves provide no value unless they're in line with business goals.

Lest I sound like a spoilsport, that is not to say that there's no space for technological innovation- in fact, there's lots of room for it! We just need to make sure we're aligned with the other teams. When we are, that gives us the confidence to also push for our own technical features as we know it advances our shared interests.

Which leads me to...

4. Put in effort to make the right things flexible.

A bit of planning and consideration during technical design can go a long way in saving you time and effort during implementation. Sounds like a given, but when put into the product engineering context, where team resources are often stretched thin and release cycles come hard and fast, we need to be extra smart about where we choose to spend our precious time on. Execute this well, and it can seem like the engineering team's doing magic.

One initiative in particular stands out for me.

One of the systems I'm most proud of is our omni-channel payments framework. From our product roadmap, we knew that we had a pretty tight window to: firstly, implement physical QR payments; then provide a web payments API to our e-commerce partner; and finally, make payments available to our in-app lifestyle services.

That's a lot of things to get done and not much time. However, we decided to spend the bulk of the phase 1 (supposedly, QR payments) designing a more extensible platform. Because of this, we ended up building the whole thing in almost one-shot, with only smaller implementation details needing to be fleshed out.

QR, web, mini app, online, offline- you name it.

We ended up releasing phase 1 with a little bit of delay, but took almost no time to release phases 2 and 3, resulting in a (very) pleasantly-surprised business team. The leverage we were able to apply by spending some time designing an extensible architecture meant that we were able to leapfrog our roadmap and have a fully-functioning payment platform in a significantly less than the estimated time.

This works great, but is also the result of figuring out where best to spend engineering effort to maximise impact.

But speaking of technical decisions...

5. You will make technical missteps. Roll with it.

Back in 2017, we started building Presto as a mostly greenfield project, having very few constraints on what we could use (except in infrastructure, where we had a lot of compliance requirements and little flexibility at that time). The only main consideration was our team's prior knowledge and technical strengths, which bound us to a Java-based stack. (If you're coming in from a less "enterprise-y" world, I want to say I actually do like using modern Java and its library ecosystem- but that's a topic for another day.)

We focused on shifting a more scalable paradigm, moving away from the traditional servlet container (1 web request = 1 thread) monolithic service approach to an event loop-driven, non-blocking microservices approach utilising an asynchronous, reactive programming model.

Now, that's a lot of buzzwords I just threw at you... and back then, until we actually implemented it, it was just buzzwords for us as well. Of course, we did our research, but a technical design is one thing, and it was another thing altogether to put that design into practice.

It took us a while to get used to the huge mindset-shift, and it resulted in a first iteration that infra-wise, looked like we built decoupled microservices; and code-wise, looked like it featured asynchronous & event-driven processes... but it still behaved like synchronous, imperative logic within one inefficient spaghetti pile of a monolith. We ended up launching that initial system, but as we got better, we figured out what we were doing wrong and started the long road of refactoring that led us to a system that was more like the performant and scalable design we had initially envisioned it to be.

Even if we had some missteps, I'm still glad we took the chance to stretch ourselves with trying out different approaches. In the long run, it's worse to be stuck in the same paradigm doing the same thing, without knowing if there are better ways to build things.

Now this is was insight borne out of our technical inexperience, but I think it's still relevant at any level of proficiency, especially as we sometimes have to live on the bleeding edge of not just tech, but also of solutioning novel approaches to business problems.

6. Building the right team is just as important as building the product.

This whole building products thing has underscored for me how really, freakin' important it is to build the right team that's building your product. The product can go through so many iterations and pivots- Presto certainly did. And we wouldn't have pulled those off if we didn't have a great team- and a cross-functional one at that, covering business, design, product, QA, and tech.

The Singapore team at my favorite cafe near the office!

Sometime, especially when it's recruiting season, it can feel like you're unable to get anything done with the amount of interviews you have to do, but a few months down the road, when you're deep in the trenches with your team pushing towards your next release, the fruits will be evident.

The Malaysia team- with Presto!

However, even if you have the right team, you also have to give them the space to do effective work.

Empower your team. It's never a one-person show, and a capable team only becomes the right team if everyone has the freedom to exercise those capabilities. A lot of Presto's best features and systems were built through constant feedback and collaboration. Expanding the team's perspective this way enables us to build a product that's more relevant and technically sound.

And it keeps the team's morale high if everyone has a hand in each success- and builds a closer team bond with each shared setback. I'm grateful for the people I've had a chance to call teammates during our 2+ years building Presto.

7. There is enormous value in iteration.

Anyway, when building products, it all comes down to this: the only people that really know what they want are the actual users. And the only way to get feedback from users is to put something in front of them. Of course, you can (and should) try to do some market research beforehand, but ultimately, it's only when users can actually interact with your app will they figure out what works and what doesn't.

What you start with will most often not be what you end up with. That is to say: you won't generally get everything right the first time. We certainly didn't. But that's just part of the process, and with effective iteration, you will eventually start to hit the mark.

You do have to take steps to ensure that iterations are effective. Your architecture should support the ability to quickly build on top of existing functionality, as well as be able to measure the impact of those iterations. Otherwise, you run the risk of having inadequate data, and thus, decrease the effectiveness of your iterations.

This is something we're still learning and improving on, from the engineering perspective. We've yet to build enough of a harness for us to efficiently gather data and extrapolate learnings from it. This is something we focused on a bit late after roll-out, so it's a top priority for implementation. In the meantime, support from the product & business side has been invaluable in figuring out what the next iteration looks like.

This was my first brush with product development, and the past 2 years have been a wild ride. There's a lot yet for me to learn, and maybe these insights are just the tip of the iceberg. But just as there is value in iterating on your product, I think there's value in sharing these initial thoughts, and I'd be happy to hear yours!

You can also find this post (and comments) on Medium: https://medium.com/@jensen.ching/7-personal-insights-on-building-products-a-presto-post-mortem-ce3abc720db2