When I can lead an entire validation path, I move quickly.
Once an idea appears, I make a mockup, find users on Xiaohongshu, move a minimum version forward and use conversations, retention and interviews to decide whether to continue or close it. With Mengya, the key judgments—from concept and cold start to MVP, research and review—sat inside a short decision chain.
In a company-level product, the speed changes.
The same problem may involve product, engineering, design, content, growth and existing users. It is no longer simply, “I think we should try this, so let us do it now.”
I once understood the difference as the frustration of difficult coordination. I now see it as two different systems of speed.
Speed is not only a matter of personal action
In this essay, an “independently led product” does not mean that I did every task myself or that the work necessarily happened outside a company. It means that I was responsible for the problem, measures, pace and stopping conditions, so the decision chain was relatively complete.
These products move quickly because the decision surface is small.
I can decide what problem to solve, which part to test first, how to judge the result and when to stop. If an experiment fails, the users and cost affected are relatively limited. Many decisions are reversible. When the data changes, I can change direction that day.
A company-level product carries more. It already has a stable structure, brand promises, technical foundations and many users. A small change to an entry point can affect an established journey. New users from a growth campaign can alter support cost, data definitions and future operations.
When the cost of being wrong increases, more people need to understand the problem, agree on the priority and share responsibility for the result. Work becomes slower, but that does not necessarily mean anyone is unwilling to act.
Speed is shaped by the number of dependencies a decision must cross, whether failure is easy to reverse and how many people will feel the result.
Fast exposes mistakes early; slow protects the whole from a locally correct decision
Mengya’s next-day retention was 15%, below our target. I could close it quickly because it was still a validation project and the cost of stopping was controlled. The decision prevented us from adding more features to an unsupported assumption.
In the Fanshu Intelligent Edition growth experiment, I also moved quickly to activate an external creator campaign. The data soon told us that the channel could create content and registrations while continued use among non-Fanshu users remained weak.
The next step could not be solved by changing one page myself. Retention involved product value, first experience, content supply, interaction, note capture and what users already believed Fanshu to be. Every local solution had to be judged inside a larger system.
The speed of an independently led project is useful for exploration. It makes mistakes appear early and cheaply. The collaboration of a company-level product is useful for turning a visible problem into something that can operate safely at greater scale.
Both have blind spots.
Fast personal judgment can mistake one person’s preference for the market or abandon value that requires time to accumulate. Slow organizational coordination can allow a window to close while people align, eventually substituting process for judgment.
A product manager’s job is not to make everything fast
I now care less about proving that I move quickly and more about identifying the speed a decision requires.
Which assumptions can be tested with a lightweight prototype instead of waiting for a complete plan? Which changes are reversible and should give the front line more autonomy? Which choices will be difficult to recall after launch and therefore require clearer risks, dependencies and definitions first?
In a company-level product, momentum does not only mean asking for faster delivery. It means translating a user problem into a structure every function can discuss, shrinking the scope of the first test, stating what this iteration will not solve and using evidence to reduce endless argument.
Independently led work taught me how to open a path inside uncertainty. Company-level work forces me to learn how a path travels through a real organization rather than living only inside my own judgment.
Fast is not the goal. Slow is not maturity.
The right speed lets a decision reach the user without hiding a cost that should have been carried together.