App Growth Needs to Become a Sales Validation System Before You Write Code
The biggest waste for a product team is writing code blindly before validating why anyone would buy; real growth requires closing the loop on sales and user acquisition before the first line of code is written.
Growth should become a sales validation system before you write any code, not something you bolt on as promotion after launch. @MengkePM wrote about this shift in *Learn How to Sell Before Becoming Great*, and that core idea resonated with me much more than the specific tactics in his post. The article is a recap of a marketing session he taught at the Apple × Zhejiang University Mobile App Incubator Camp.
Among indie developers and small product teams, the most common habit is to build out every feature and set up a solid architecture first, then figure out growth and user acquisition only after the app is live in the store.
Pushing growth to the end of development often wastes a huge amount of resources. A healthy growth system should start before you write the first line of code, turning a vague product idea early on into a closed-loop sales validation test built around a target audience, positioning copy, search keywords, and small-budget ad runs.
This follows the same underlying logic as The Essence of AI Coding Is Turning Vague Intent into Verifiable Workflows: software engineering needs explicit test assertions, and business growth similarly needs objective, upfront acceptance criteria. Beyond verifying that our code runs, we need to verify as early as possible whether target users understand the selling points, have any intent to search for a solution, and are genuinely willing to pay.
The App Store Is the Warehouse; Content Platforms Are the Shelves
On the relationship between app stores and content platforms, I really like the author's analogy. Many teams used to treat the App Store as an organic traffic channel, but user journeys have changed. People rarely open an app store just to browse around. Instead, they get hooked by a specific piece of content in feeds like Xiaohongshu, Douyin, Bilibili, or X that hits a particular scenario and emotion. They remember the product name or the solution, and only then go to the app store to search and download.
The way I see it, an app store is just the "warehouse" where users pick up the goods, while social and content platforms are the "shelves" where products are displayed.
If a team spends the entire development phase polishing features inside the warehouse without ever testing how the product sits on the shelves, they will likely face a quiet launch with weak conversion. Moving growth upfront means stepping into that shelf environment early and testing real market reactions at a low cost.
Translating Features into Identity and Emotion
Developers with technical backgrounds easily fall into the trap of geeking out over their own features. When introducing a product to users, they often lead with lines like "four-quadrant task scheduling based on the Eisenhower Matrix" or "supports millisecond-level multi-device sync via iCloud."
There is nothing wrong with these technical descriptions on their own, but users rarely care how elegant your architecture is. They only care about one thing: "What does this have to do with me?"
My take is that proper growth validation requires working through five layers of language translation, from surface mechanics to deeper human hooks, before you touch the code:
| Layer | Core Question | Task Management Tool Example |
|---|---|---|
| Feature Layer | What underlying capability does the product implement? | iCloud multi-device sync, four-quadrant view |
| Value Layer | What practical benefit does the user get? | Jot things down without fear of losing them, available anytime and anywhere |
| Emotional Layer | What painful feeling does it help the user escape? | Breaking free from daily chaos, anxiety, and the feeling of being pushed around by chores |
| Identity Layer | Who do users feel they become after using the product? | Someone in control of their life, more clear-headed and disciplined |
| Content Layer | What makes users stop scrolling in a busy feed? | "Always getting chased by urgent tasks? Try this 3-minute morning reset" |
If a team cannot explain the pain points and value in plain, everyday language when kicking off a project, the product will struggle to gain market traction no matter how clean the code is.
Four Operational Steps for Upfront Validation
In practice, I prefer to break upfront validation down into four steps:
1. Distill a One-Sentence Positioning Formula
Before development starts, narrow the product positioning down to a single sellable sentence:
我们帮助 [明确的受众]，在 [具体的痛点时刻]，解决 [核心问题并带来特定改变]。In my experience, the more specific the audience (for example, "independent workers who easily get derailed by small errands" rather than a generic "office workers"), the sharper your targeting will be on content platforms.
2. Build a Search Keyword Map
Search behavior reflects strong, active demand. While mapping out features, I think a team should also put together a five-dimensional keyword library:
- Audience terms: freelancers, grad school test-takers, designers, junior developers;
- Scenario terms: morning check-in, retrospective review, capturing fleeting ideas, final exam prep;
- Product terms: APP name, plain-language names for core features;
- Competitor terms: alternatives to well-known benchmark products in the industry;
- Category terms: minimalist bookkeeping, lightweight kanban, to-do list.
Working these terms naturally into early content and landing pages is an effective way to gauge real search interest in the space.
3. Use Small-Budget Ad Runs as an Experimental Diagnostic Tool
I agree with using small paid ad runs as a low-cost way to test hypotheses. The point is to help the team diagnose problems; spending money just to buy vanity traffic misses that goal:
- Very low click-through rate: Your cover, title, or Hook isn't feeling relevant to users, so you need to rework the content angle;
- High click-through rate but very low conversion: The store listing, landing page handoff, or onboarding flow is disconnected, and the actual experience doesn't match the promise;
- High download conversion but very low paid conversion: The perceived value of the features isn't strong enough, or the Paywall pricing is out of touch with user expectations;
- Positive return on investment signal: You've found a repeatable buying trigger worth breaking down and scaling up.
4. Partner with KOCs Using a Clear Brief
In the early stages, I prioritize finding small-to-medium creators (KOCs) or seed users who genuinely have the pain point, rather than spending a big budget on top influencers for stiff promotional reads. The team can provide a clear Brief explaining the original design intent, the core tension the product aims to resolve, and the boundaries of what should not be exaggerated, then let creators talk about their experience in their own natural voice. Often, these outside testers help the team uncover key selling points that the developers themselves hadn't even noticed.
Boundaries and Reflections
Emphasizing upfront growth does not mean using marketing to cover up a mediocre product.
- Content drives the first try, but retention depends on the product itself: No matter how good your content seeding is, it can only bring users to the door. If the core experience is rough, crashes frequently, or fails to actually solve the problem, users will churn quickly and even leave bad reviews;
- Different product types require different acquisition channels: Content platform seeding works very well for consumer apps, productivity tools, and lifestyle products; however, for deep enterprise software and low-level developer infrastructure, professional communities, dense technical documentation, open-source distribution, and targeted direct sales remain the primary channels;
- Beware of over-packaging: Pumping out purely mechanical content in bulk without real user participation only creates meaningless online noise and won't build lasting brand trust.