This week, the spotlight returns to Adriel who is a member of two VB18 projects — Pratu and TrueSign.
Pratu was conceived with the purpose of providing investors access to hospitality properties in Thailand at a fractional rate, making it accessible to a wider market to purchase without being over-leveraged. TrueSign aims to be the choice solution provider for institutions dealing with complex document flows and identity authentication.
Over the course of the past 6 months, Adriel has met with his fair share of highs and startup teething lows. When asked about one of his major pet peeves, he immediately mentions the technical side of things, and the challenges they bring.
I came into the Pratu and TrueSign projects with the illusion that I was simply going to throw the technical part of the projects to these professionals, and all we had to do was just manage them and wait for magic to appear on our screens.
I soon realised this is not as easy as it seems. Whether or not it was dealing with a professional development house or a team of student developers, I found patterns when it came to understanding and managing the relationship between our customers and the technical team we were in charge of.
Handling a technical team is something every entrepreneur has to learn — whether you’re dealing with an inhouse team of developers or a band of outsourced vendors, one needs to be absolutely clear with the approach towards your vendors if you want to achieve mission success.
Below, Adriel outlines 4 key lessons he learnt regarding managing a tech team.
Lesson #1 — The difference between the aesthetic layout and data fields
The aesthetic layout (or user interface) of a product usually deals with how the customer looks at it. Whether you want it to resemble an e-commerce site or whatever kind of user journey you want your customers to experience, the onus is on your research.
It is critical to get the interface right because it is a very steep learning curve that a user has to overcome in order to fully experience what the app/ site is intended to offer. Realistically, you have less than 5 seconds to grab the attention of a prospect. You have to make full use of the limited time; every second counts!
On the other hand, the data fields are the foundation that your aesthetics are built upon. If you do not have your foundations right, your app or site won’t work the way you want it to.
A simple registration page could look unassuming to a consumer, but many questions have to be addressed behind the scenes. For example, how are you storing your users’ information? What other stakeholders require access to your users’ information apart from your administrators? Can your administrators access the information and edit it?
Lesson #2 — Having a technical product lead saves time and pain.
When you’re trying to create something completely out of your field of expertise, it is extremely valuable to have someone that can bridge the gap between your software developers and your product lead. Oftentimes, this requires an individual with the ability to understand what the tech team is saying and is still able to explain things to you in a layman way.
This individual should also be able to process requests from the product lead and turn it into a diagram which the team can refer to and know exactly what they are building.
Lesson #3 — Set expectations with customers.
Sometimes, as you reveal your product to your customers, you realise that they start to request for additional functionalities that you did not account for in the beginning, or you find that certain features that you initially thought were easy to build turn out to be much more complicated. Oftentimes, such functionalities would have to be dropped for the time being.
Many times, it could feel like being caught between two parties — torn between meeting the expectations of the customers as well as realistically managing the goals of the tech team.
Lesson #4 — It’s not about the ability of the team, it’s the ability of the leader.
No matter how inadequate the team might seem, the onus lies on the leader to lead the team out of a bad situation. Selfishness, blame, and refusal to take responsibility is detrimental to the team as nothing gets done efficiently.
Adriel illustrates his point with the story of Jocko Willinks’ Navy Seal leadership experiment, which can be found in full here.
I hope you’ve enjoyed these 4 lessons that I’ve learnt! Avoid making these mistakes if you can, but if you can’t maybe these lessons would serve as a memory jolt, to remind you of the things to look out for.
Till next week! Bye!
