Bring familiar product judgment into app development
Economic Daily's October 21 article described Han, formerly a senior AI product manager at Meitu, developing apps involving communication, recording and scheduling. It said AI supported research, code generation and testing while she handled product direction, requirements and quality.
This combines product experience with development tools. We examine its business choices through mobile use cases, without converting listing counts into revenue or assuming every app calls a generative model internally.
Small phone tasks often allow little patience
Desktop users may sit down to learn software, whereas phone tools are often opened between other activities. Someone recording an arrangement may only want to type one sentence; someone preparing a conversation may need help with one difficult passage. The intended action determines what the product should explain first.
For a hypothetical calendar task, observe where arrangements arrive, why they are not recorded promptly and when the user next needs them. If information is scattered across chats and notes, more visual themes may not help. This is our proposed observation method, not a feature or study attributed to Han.
Initial users should recognize themselves in the demonstration
It is easy to describe a mobile tool as suitable for everyone. An early demonstration can instead show one task: the old process, the step performed in the app and the final result. Recognizable situations help viewers decide whether to try it.
Store descriptions, demonstration clips and help pages should follow that same task. Promotion focused on complex agents can create mismatched expectations if first use is simply a form. Choosing demonstration language is part of product work.
Each app needs its own reason for further investment
The report described Han independently developing and listing multiple apps within a year. That suggests continuing experimentation, without identifying which app brought payments or needed most support. Treat each as a separate decision when examining this route.
Record current recurring needs, repeat-use moments and time spent resolving problems. A popular demonstration may deserve reassessment if users cannot identify when they will need the tool again. A quieter tool may serve a clearer recurring task.
AI lowers production barriers, but attention remains limited
Faster feature development creates more choices. A small team can define the next question about a user group, difficult action or demonstration channel, then decide whether to continue, narrow scope or pause. This makes choices more comparable than following a feature list alone.
We have not verified official entry points for each app, complete collaborators or finances. Han's case concerns product experience selecting a small problem and AI helping make a testable tool. It does not prove that learning to generate code reproduces the same market results.
Further reading: specific uses of Cat Light; compute and support burdens in a product portfolio.