The 160 Most Expensive Insights on How to Sell Your Product

This content comes from the printed student handbook our team made for developers during the Apple × Zhejiang University Mobile App Incubation Camp.

Here are 160 truths that App founders are reluctant to admit:

The day you finish writing code is when the real challenge begins.

“Learn to Sell Before You Achieve Greatness” unexpectedly went viral on X. Many people asked the same thing in the comments: I understand the theory, but how do I actually do it?

Today, I’m sharing some of the knowledge from the handbook publicly for those who couldn’t be there.

🍎

1. This course ultimately answers one question: Who will need your App, and at what moment.

2. Growth isn’t something you start after launch; it needs to be involved before the product is even clearly explained.

3. A product isn’t about expressing yourself or constructing a complete world; it’s about serving a specific need for a specific user.

4. Build is only the first half; Sell requires a different set of skills.

5. A good App with no downloads usually isn’t because the features aren’t enough, but because the user didn’t understand why it matters to them.

6. The Apple ecosystem doesn’t automatically distribute traffic to new Apps. The App Store is more like a warehouse than a shopping mall.

7. The App Store can receive users, but it can’t do user education for you.

8. Before a user downloads an App, they typically go through the stages of seeing, understanding, believing, and knowing the next step.

9. Growth can be broken down into several parts: problem, user, messaging, content, channels, conversion, data, and iteration.

10. Don’t treat content as something you do at the end of a promotion. It is itself a tool for validating the product.

11. Promotion isn’t about pushing the product in front of more people; it’s about giving specific people a reason to understand.

12. This course covers “Problem and Messaging” in the first half-day, “Sustainable Content Production” in the second half-day, and “Validation System” in the third half-day.

13. Apple users are not an abstract, high-end demographic; they are specific users in many specific scenarios.

14. Specs, features, and technical details are not purchase reasons that users naturally understand.

15. Users don’t first understand your product’s structure and then decide whether to download. Instead, they first judge, “Is this relevant to me?”

16. Developers tend to write about what they can do; users care more about what pain they can avoid and what results they can gain.

17. The more features an App has, the more it needs to be translated into fewer, clearer usage scenarios.

18. The old path is: write code, launch, wait for downloads. The new path is: build the product while simultaneously testing your messaging.

19. The product doesn’t need to be fully finished to test the problem, scenario, title, keywords, and user reactions.

20. The minimum verifiable object isn’t necessarily a feature; it can be a problem, a phrase, a screenshot, or a use case.

21. Before doing growth, ask: Whose high-frequency, strong, or clear problem does this App solve?

22. “Anyone can use it” is usually not an advantage; it means the messaging hasn’t been narrowed down enough.

23. Users saying “it’s nice” doesn’t equal willingness to download. Searching, saving, commenting, DMing, and trying are closer to real signals.

24. Product value can be explained in terms of saving time, saving money, reducing hassle, reducing uncertainty, gaining a sense of control, and gaining emotional support.

25. The first sentence introducing an App shouldn’t try to explain all the features. It should let the target user immediately know it’s relevant to them.

26. User language is better suited for titles, covers, and selling points than developer language.

27. The core action in this course isn’t “packaging”; it’s translating the product into language that users can understand, repeat, and act on.

28. Xiaohongshu (Little Red Book) isn’t the only answer, but it’s suitable as an early content validation training ground.

29. For Chinese developers, the Google Play path is more complex due to accounts, payments, distribution, etc. The iOS path is relatively clearer.

30. For indie developers and small teams, validating demand with low-cost content is usually more stable than large-scale paid acquisition from the start.

31. Apple users aren’t just buying features; they’re buying things like smooth experience, pleasing design, and the feeling of being understood.

32. When translating your product, don’t just ask “What features do I have?” Ask “At what moment does the user need this change?”

33. Scenario-based messaging answers: “Under what circumstances does the user use it?”

34. Emotional messaging answers: “What anxiety does the user feel less of, or what feeling do they gain more of, after using it?”

35. Identity-based messaging answers: “Why is the user willing to consider this App as their choice?”

36. For utility/tool Apps, clearly state: “What steps are saved, what repetition is reduced, what mistakes are avoided.”

37. For emotional/wellness Apps, clearly state: “What feeling the user gets, what moments the App accompanies them through.”

38. For AI Apps, don’t start with model capabilities. Start with which task the user finds easier.

39. For developer tools, don’t start with the architecture. Start with which pitfalls the developer avoids and what time they save.

40. For health, habit, and journaling Apps, don’t just talk about data. Talk about how the user can more easily stick with it.

41. For productivity Apps, don’t just talk about lists and reminders. Talk about how it reduces the user’s feeling of chaos.

42. For finance and expense tracking Apps, don’t just talk about statistics. Talk about how the user can feel more at ease knowing where their money goes.

43. The messaging direction isn’t fixed once. The same App can test multiple user scenarios and selling points.

44. To judge if the messaging is good, don’t look at whether the team likes it. Look at whether the user is willing to take the next action.

45. A good title usually points to the problem, result, or scenario first, not a product self-introduction.

46. A good cover makes the user know in one glance: “This is relevant to me.”

47. Good body content provides story, process, evidence, method, and next steps, not just emotional expression.

48. A phrase that a user can repeat to a friend is a relatively solid product message.

49. When writing a one-line App description, it’s best to include the target user, use case, and the change it brings.

50. If a one-line description needs a lot of explanation to be understood, it hasn’t been translated well.

51. Xiaohongshu is more like a searchable magazine than just a real-time feed.

52. Search traffic on Xiaohongshu is very important. Many users don’t stumble upon you while browsing; they find you when searching for a problem.

53. Content on Xiaohongshu should have a magazine-like quality. This doesn’t mean fancy decoration, but rather well-organized information.

54. One post is best for solving one clear problem. Don’t cram all selling points into a single post.

55. The title pulls the user in, the cover helps them understand, the body builds trust, and the comments section continues the conversation.

56. Keywords for Xiaohongshu should come from user search terms, search suggestions, actual comments from users, and competitor content.

57. Keywords should naturally appear in the title, cover, body text, comments, collections, and account bio.

58. Xiaohongshu cannot directly link to the App Store download page, so you must design a clear download path.

59. The download path can be handled via the App name, account bio, pinned comment, DM keywords, official website, or community.

60. Don’t just write “Search the App Store.” Tell users what to search for, which one to tap, and why they should do it now.

61. The account homepage is where users make decisions. The avatar, bio, pinned posts, and collections should all serve conversion.

62. The first month shouldn’t just chase viral hits. Instead, build a set of searchable, reusable, and comparable content samples.

63. The purpose of early content cadence isn’t to show presence daily, but to test users, problems, titles, covers, and conversion paths.

64. After publishing a Xiaohongshu post, look at search exposure, click-through rate, saves, comments, DMs, App name searches, and download changes.

65. Not going viral doesn’t mean failure. Lack of any valid signal means a change in direction is needed.

66. Comments often tell the truth earlier than meeting rooms. User questions and misunderstandings can be used to modify product messaging.

67. The closer the case studies in your content are to the user’s real life, the easier it is to build trust.

68. App content doesn’t have to look like an ad. It can be like experience sharing, tutorials, pitfalls to avoid, retrospectives, checklists, and real-life records.

69. Overseas organic validation should precede overseas paid advertising.

70. It’s not about having as many overseas channels as possible. Each platform serves a different validation task.

71. The App Store handles reception and conversion. Title, subtitle, screenshots, preview video, ratings, and reviews all affect downloads.

72. Product Hunt is better for a launch moment and amplifying momentum, not as the first step of a completely cold start.

73. Reddit values genuine problems and non-advertising answers. Hard ads are often rejected.

74. X is better for building awareness through opinions, progress, demos, and continuous development logs.

75. Before overseas paid acquisition, confirm that your website, App Store page, payment, privacy explanation, and support paths can receive users.

76. An account isn’t a company website. It’s the ongoing presence of the product.

77. Choose your account strategy based on resources. Don’t try a complex matrix that exceeds your team’s capacity from the start.

78. Founder appearances are good for building trust, especially for products that need to explain philosophy, judgment, and long-term companionship.

79. Product official accounts are suitable for steady output of feature explanations, tutorials, version changes, and user case studies.

80. KOC or non-influencer matrices are good for covering multiple scenarios and keywords, but have higher management and compliance requirements.

81. Development logs are suitable for showcasing the real building process, letting users see how the product improves step by step.

82. Founder IP is more valuable for B2B, developer tools, and high-trust products.

83. Technical content can attract developers and professional users, but it shouldn’t just be tech ego-stroking.

84. Account positioning should state: who I am, what problem I solve, why I’m trustworthy, and what the user should do next.

85. The first 10 pieces of content before a cold start should cover: problem explanation, use case, product method, real case study, common questions, and download path.

86. During cold start, don’t change your positioning every two posts, or the data won’t be comparable.

87. Don’t hide the product too deep. After reading the content, users must know this is an App they can use.

88. Early on, don’t take follower count as the only metric. Focus on real problems, real interactions, and real conversions.

89. Account content should have regular columns, so both users and creators know where the next piece of content is coming from.

90. Existing users can provide real case studies, reviews, and repurchase signals.

91. New users can help the team break out of feedback loops from acquaintances and existing user inertia.

92. The account promise, product experience, and download page messaging must be consistent, or conversion will break.

93. AI content production isn’t about generating posts with one click. It’s about making the content process faster and more stable.

94. AI will make much content similar. The real gap comes from product facts, user details, and creator judgment.

95. AI is suitable for topic expansion, structure organization, title variations, initial drafts, and rewriting.

96. Humans must provide real materials: product screenshots, user quotes, usage scenarios, failure experiences, version changes, and limitations.

97. A good prompt should include: one-line product description, target user, specific scenario, keywords, messaging direction, reference style, and prohibited content.

98. First drafts written by AI usually need to be rewritten to sound more like real human speech.

99. AI cannot judge whether users actually need this product.

100. The Vibe Coding development process itself can become content material.

101. Feature choices, trade-offs, error states, iterations, and launch processes can all become developer logs.

102. Don’t wait until the product is perfect to record. Real processes are more credible than retrospective packaging.

103. Content production should first build a material library, then let topics grow from that library.

104. From material to publication, a piece of content can be broken down into: material, topic, title, cover, body text, comment interaction, and data review.

105. One real material can be rewritten into a tutorial, case study, pitfall avoidance, checklist, retrospective, or short opinion.

106. AI can provide multiple title directions, but the final choice should be based on user language and platform feedback.

107. Before publishing, check three questions: Is the problem specific? Is the evidence real? Is the next step clear?

108. Comments and DMs should feed back into the next round of prompts, not just be handled as customer service.

109. The most dangerous thing about AI content isn’t that it looks bad, but that it looks reasonable but lacks real user basis.

110. Paid advertising isn’t a wish list. It’s using budget to test which messaging is worth continuing.

111. Without any organic signals, it’s not recommended to use a large budget for paid acquisition.

112. A 5000 RMB test budget isn’t for buying growth. It’s for buying judgment.

113. For a small budget test, start with 3 to 5 pieces of content, each with 100 to 200 RMB, run for 2 to 3 days, and look for signals.

114. Search ads test clear demand and keyword reception.

115. Feed ads test interest, covers, titles, and first-glance appeal.

116. Before running ads, you must have a landing page, App Store page, account home page, or DM capabilities to receive users.

117. The App Store product page is a crucial landing page. Screenshots, title, subtitle, and preview video all affect conversion.

118. Product Page Optimization allows you to test the impact of different product page elements on conversion.

119. Custom Product Pages allow you to prepare different landing pages for different audiences or advertising directions.

120. App Analytics should track: impressions, product page views, downloads, conversion rate, activations, and retention.

121. Many ad problems aren’t about backend settings; they are issues with content, reception, and next-step design.

122. The App growth funnel can be broken down into: exposure, click, landing page or home page, download, activation, D1 retention, and long-term usage.

123. iOS privacy mechanisms affect attribution accuracy. Early on, accept “directional judgments” rather than pursuing absolute precision.

124. The strategies that work on mature platforms usually have the same underlying principles: content, next step, traffic, and rules.

125. The “add to cart” in e-commerce corresponds to the App’s download entry, landing page, website, TestFlight, community, or DM reception.

126. The “store” in e-commerce corresponds to the App’s App Store page, website, account home page, and registration process.

127. Ratings, reviews, and after-sales service in e-commerce correspond to the App’s ratings, reviews, retention, feedback, and support system.

128. Matrix accounts in e-commerce correspond to covering different search terms and user stages through different App content accounts or different content columns.

129. “A plants, B harvests” means A creates the demand, B makes the recommendation, and C, D, E continue to fill in experience, price, pitfalls, or usage details.

130. The comment section for “A plants, B harvests” isn’t casual chat; it’s a script that step-by-step overcomes user skepticism.

131. The “Zhengzhou gang” style involves flooding a large number of small accounts, disguised as regular users, to mass-produce content, comments, saves, and DMs across multiple scenarios.

132. Both “A plants, B harvests” and “Zhengzhou gang” disguise ads as public consensus and recommendations as real discoveries.

133. The underlying structure of these tactics can be broken down into: question, explanation, case study, Q&A, and next-step reception.

134. The transferable actions from these tactics are: covering different search terms, different user stages, and different doubts with different content.

135. The parts of these tactics that cannot be directly copied are: fake comments, disguised regular users, fake experiences, and mass comment control.

136. More sustainable alternatives are: real user feedback, developer logs, product case studies, version changes, and clear download paths.

137. Gray-hat tactics can only solve the appearance of wide coverage and credibility; they cannot solve whether the product itself has value.

138. Traffic sources can be divided into: organic traffic, paid traffic, self-created traffic, and influencer/media traffic.

139. The endpoint of good paid acquisition is not constantly buying traffic; it’s finding the set of messaging and paths that can grow organic traffic on their own.

140. A 30-day action plan isn’t about scheduling a content calendar. It’s about designing a validation route.

141. The action plan should clearly state: one App, one target audience, one core scenario, one primary channel, and one key metric.

142. Week 1: Confirm the user, problem, one-line product description, keywords, and first batch of content topics.

143. Weeks 1-2: Test the audience, problem, title, cover, and download entry.

144. Weeks 3-4: Amplify the content directions and reception paths that already show signals.

145. When there are no valid signals, first adjust messaging and audience. Don’t immediately suspect you need more budget.

146. If the same question is repeatedly asked, it might be worth continuing to create content about it.

147. If the same selling point repeatedly brings in searches, DMs, downloads, or activations, it might be worth increasing the budget.

148. Weekly review should look at: content data, user questions, download data, activation data, and retention data.

149. Key App data isn’t just about downloads. Also look at activations, key action completion rates, D1 retention, and user feedback.

150. Resources determine the strategy. A one-person team shouldn’t take on a complex matrix, heavy paid acquisition, and multi-platform syncing from the start.

151. First, complete a small loop, then expand. This is better for early Apps than building a large system from the start.

152. Product, content, account, paid acquisition, and data aren’t five separate things. They form a single validation chain.

153. Content validates product messaging. Accounts receive user trust. Paid acquisition amplifies effective messaging. Data helps you decide the next step.

154. The best outcome of this course isn’t “learning Xiaohongshu.” It’s knowing what your App should validate next.

155. The minimum action in the first week can be: publish your first post, rewrite your one-line product description, build a landing page, find 10 real users, or run one small-scale test.

156. Don’t replace user language with internal jargon.

157. Recognition from investors, judges, and peers doesn’t equal real user demand.

158. Long-term trust in the Apple ecosystem comes from: product experience, privacy awareness, restrained messaging, and continuous iteration.

159. Long-term growth comes from real value and credible messaging, not from a one-time buzz.

160. Growth isn’t a single event. It’s a continuous cycle of translating the product to the right users and then using feedback to refine the product.

🪐

People who build products have a bit of idealism inside. They believe that what they make can make someone’s life a little better.

This handbook hopes to help ensure that this sincerity doesn’t get buried.

Hope this inspires you.

Turn talent into money, so you don’t let yourself down.