How to evaluate the quality of an application

I have always been asked about how to provide a rather definitive evaluation of an application. Especially for partners of which are now outsourcing part of their services to the third parties, or ones during the primary stage of a specific interview. Even for me, as a senior-level product manager, I still being asked about "Could you please briefly provide optimization advice based on your experience" or " How do you think of the product quality of xxx ( the name of the product). " Well, I'm gonna say I was as same confused as you while being asked about this series of questions cause you can just not give a definitive product evaluation during a quick interview or in a few words.

Here comes the question mark: How to fully evaluate the quality of an application?

I believe that before your team or you start working on some specific projects or ground-up product, you need think over the structure and also every single point listed above. A good product starts with a very clear vision and knows clearly about their mission, or what kind of product it will finally be grown up.

1. The Business part is going to be the most attractive part that can be shown to the later Venture Capitals of whom are interested in investing your company. There are exits countless of companies which successfully gained millions of users but meet their bottleneck while talking about their commercial value or liquidity. A good product should show a clear vision and confidence to the investors at this point. Also, it needs to have strong enough differentiation to make it outstanding among all the existing competitive products. In a word, a good product can always combine business vision perfectly with the user values.

2. Once the business plan settled, it comes to the technology it will use to realize your vision. The tech part should include the framework of the whole services including front end, middle end and backend. I believe that every ground-up project may have limited resources to give a support at the very first beginning. That means you need to consider efficiency and cost at the same time, that means your tech construction could possibly have two stage to go:

• Stage one: Agile Dev. Make sure the output can be quickly launched with most well-experienced features. During this stage, you may not take two weeks to discuss why node.js instead of Vue or Angular, why Ruby instead of Phython. You also may not rewrite or even have time to construct a whole new CMS systems yourself. During this stage, a forcible output in order to verify the competitive strength in the market is exigent. So the team may suggest open-sourcing toolkits, existing APIs which only needs little customizations or everything can help quickly push the release.
• Stage two: Overall construct. After several quick iterations, your service has finally become a relatively stable version and if you're lucky enough, your service may have already gained appreciable user base. And also at the same time, your service is becoming bigger day by day. Here's the moment that your system architect will stand out to do sth. The former front end may not editable enough to meet the frequent edit and update requirements. Your backend system may not safe enough for all the personal user info. The whole system needs to be upgraded to face the upcoming traffic, DDOS attack defensiveness needs to be strengthened, service needs to be more redundant to solve overload, etc. ( I suggest the guy is as brilliant enough as Bertram Gilfoyle from Pied Piper:D）

3. To explain the Empathy, I believe it would not be strange to show " The Hook Model" (by Nir Eyal). The model explains how a user is attractive by your service at the very first beginning, or what brings them here for further actions. If it comes to an application, usually, it would be called First visit guests. After that, your service will keep update, release new features, debugging to make sure it continuously bring better usability. From which stage, the DAU, MAU, Retention, etc can be brought to the table for help evaluate your service quality. A good product will also contain strong attractiveness to let user generate original contents, aka UGC as a further investment for the platform no matter if it is a product of social property or not.

4. After all the ways above to evaluate a specific product, what's the next? Obviously, it is still not enough or can not be the full stop of the evaluation.On the contrary, it is just the beginning.

There are already exist several standards to evaluate every version or parts for the whole lifecycle of a product. As a PM or POM, you need care about all the points mentioned above in the table. Of course, the most important part for you could be the usability cause it has the strongest link to the user experience. But as mentioned, you should know every part of RUPRS+ would actually make a significant difference in your product quality, and until the product is dead, could you stop worrying about the possible impact it will bring to your product. Except for the usability, the RPRS are usually taken over by your R&D and QA team. Surely, some of the parameters can be easily felt or tested on your own, but most of them need professional data test on different occasions. What is the performance on peak hour? How it performed in a specific overseas target market, the performance and the standard to measure them would vary accordingly.