Growing up, I’ve always been fascinated by Gundams — not just the anime and the manga, but the building of action figures inspired by the franchise. Every time I did well in school, I wouldn’t ask my parents for anything other than a fresh set to build. Nothing brings me more joy than opening the box and seeing all the parts still encased in the plastic frame, then eventually freeing these parts and beginning the building process. Seeing a gunpla being built from the ground up gives me an immense feeling of pride, knowing that my blood, sweat and sometimes, tears have gone into the creation of this fully-mobile, albeit miniature Gundam. My favorite one, to this day, is still the 1/60 scale, Perfect Grade Unicorn Gundam. It’s fully transformable from two modes; Unicorn and Destroy mode, and it comes with fully functional LEDs and has a full arsenal of weapons that covers the whole body.
This borderline obsession followed me until university, where I majored in engineering and specialized in mechatronics and robotics. I thought I was on my way to fulfilling my dream of building my very own Gundam Unicorn but alas, there were no practical applications for such a build. Life instead led me to financial technology (fintech), where I began my career as a product analyst, and then, a product manager.
The interesting and fun part of product management is that you have the opportunity to build something from scratch. I have always liked the thrill of piecing things together and understanding how things work. Just like building Gundams, product management requires you to oversee a product from beginning to end: from understanding what pain point we’re solving, which target market we’re building for, and developing the right solutions that will push the product forward and that end users will ultimately find valuable.
Just as you read the instruction manual and mentally plan out how to create an action figure, part of product management is planning, coordinating, and then executing through collaboration with cross-functional teams. Dissimilarly, the time you spend building a product is not always under your control: many factors come into play like market readiness and the financial runway to get the product off the ground. Through my experience in fintech, I’ve realized that agility is definitely crucial in getting things done.
Agility can be defined as the ability to move quickly and easily. In terms of product management, this means being flexible enough to know when something is not working and humble enough to pivot to another idea when needed. This could also mean keeping ears on the ground to understand what your users need from your product and how this could become a solution. One of the challenges I’ve previously encountered is that considering how big the organization is, it takes a lot of time to get something deployed. A new feature, from the drawing board to the customer’s phone, could take a minimum of a month or two, but in some cases that timeline is stretched even longer depending on institutional bureaucracy. By then, we would have missed the window of opportunity to provide customers with the correct solution at the right time — we don’t have the luxury of time to let the market wait. The moment their needs are addressed by someone else, it will be a lot more challenging to convert users to your product, unless there’s a very clear differentiator — and getting that ready will take some time too.
Now that I’m currently in a start-up, it’s all about speed-to-market (how quickly we can get a product/solution to our target customer), and iterative testing (testing and releasing incrementally, as compared to testing many elements in one go, and hoping to release the “perfect” product). While the flat organizational structure takes away most of the bureaucratic problems I’ve experienced in the past, an agile team is still a core necessity. The shift from a Web 2.0 product to a Web 3.0 product allows for less regulatory concerns in terms of building a product, but with the Web 3.0 shifting faster than the drop of a hat, it’s also incredibly important that we don’t wait too long before deploying a product.
Being a product manager, you have to move away from the traditional methods of tackling each step sequentially. Instead, understand and identify tracks that can be done in parallel, that will result with a short time to market, while also incrementally dropping enhancements to improve the existing product. . For example, if your platform can only cover 70% of what your users need (e.g. in terms of the billers that they transact with), you don’t wait until you cover 100% before you deploy — you launch with what you have while simultaneously on-boarding other billers that might cover the other 30%. Having an agile team allows you to not only work on multiple tracks, but also allows you space to strategize (and pivot, if necessary) to make up for the space you aren’t able to cover. At the end of the day, there will never be a perfect product, but there will always be opportunities to enhance or improve your product — you and your team will need to keep your eyes open and be agile enough to adjust when needed.
Just as there is no perfect product, there are also no right answers in product management. It will always depend on how you, as a product manager, will be able to organize multiple data points, and orchestrate the whole team, ultimately ending in your finished product. The finished product doesn’t mean a perfect product: the most important thing is that your product is clear in terms of addressing a specific pain point for your customer.
As product management is a highly specific field, how you approach your product is important, but the team supporting you is equally as important. However perfect your approach may be, without the right resources to execute and adjust properly, it really just is a plan written down on a piece of paper. To end, my main message for my fellow product managers is:
(1) Build a reliable team that you know has enough skills to be able to come up with solutions when things go wrong (and they usually do), and
(2) Don’t panic: break down big ideas into smaller actionable pieces.
At the end of the day, it’s really about properly communicating with your team and making sure every member is aligned with what you’re trying to build and achieve.
