4. Always be ready to make changes.
This is similar to the last point but different in the perspective. While the last point referred to changes in the App that can be hampered by being too attached to the Application, this refers to changes in processes as a whole.
As humans we prefer the comfortable and familiar routes, and as such try to avoid changes as much as possible. This could lead to a waste of a lot of resources, just because we would rather stick to the devil we know.
You have to be ready to step out of your comfort zone and try out new things, methods, and possibilities. Do not be scared to be wrong.
5. Perfection is overrated: Be Effective
While building, you will run into situations where you have to implement fixes or features in a not-so-elegant manner and clean them up later. The term used to describe this in the engineering ecosystem is called Engineering Debt. You would have to get comfortable with the Debt because more often than not it is required to achieve the fastest implementation and delay could result in nothing being shipped or released because time is wasted wanting to get it all done perfectly.
Even when everything has been done ‘perfectly’, there are still times when issues show up only after the product has been pushed to Live and it is being used. There are some problems that can only be detected by the customers. That said, measures should be put in place to ensure this is an exception, rather than a norm, otherwise, you would lose your customers.
Bonus: Be calm, sh** happens
In an ideal world, a Live or production application should never break, have issues, or have an error; but this is not the case in reality. Production does break, as a matter of fact, more often than can be imagined.
When this happens, the priority should be determining whether to deal with the issue immediately or at a later time. From my experience, the core value of the product determines the urgency.
- If the issue is annoying but does not stop your users from being able to access the core value of your product, then you have the opportunity to prioritize the issue against existing issues or tasks. This is a good scenario.
- But, in a situation where the core value of the product is hampered, you have no choice but to prioritize the issue over all else. Sometimes, you would need to issue an immediate patch or a dirty fix while working on a more permanent fix.
At the time of writing this article, one of the largest cloud providers, Amazon AWS had nothing less than three issues in Q1 2022, which affected a great number of applications and software across the world including but not limited to Instagram, Tik-Tok as well as others. This is despite all the measures set in place to avoid such issues, those cases have been more of storage or server issues but there are also different sources of such issues.
Let’s Recap
Begin from the basic structure, which is the smallest portion of the app that provides functionality that is required for you to even call it an app or product.
For instance, to a payment app, the minimum version of the app should allow a user to log in, initiate a payment to a specific recipient, and know the status of that payment. The MVP for a dating app would be a simple Chat app with a profile and pictures.
Always be ready to retrace your step and make changes, both in your Product and processes as this could be the difference between the Life and Death of the product.
You can never completely achieve perfection, it is a continuous process, so do not waste time trying to perfect the product before getting it in the hands of the customers, they would be the ones to perfect it for you.
Finally, do not beat yourself up, potato is gonna potate!
Let me know what you think about this and your experiences friends.
