At its core, a product manager’s job is simple to describe: come up with ideas, then turn those ideas into something real. The part that actually creates value is not the idea itself, but whether the implemented idea earns recognition from users and the market.
I’ve long believed that there are no truly new needs on earth—only new ways to satisfy existing ones. That is why generating ideas is not the hardest part of product work. Anyone with a bit of life experience can notice unmet needs and imagine possibilities. What is genuinely difficult is designing a product solution, especially a good one.
Internet products are ultimately software, and software has a classic formula behind it:
algorithm + data structure = program
This statement, proposed by Niklaus Wirth, the creator of Pascal, is one of the most influential ideas in computer science. Its importance to the field is comparable, in spirit, to Einstein’s E=MC^2 in physics.
If you look at product work through that lens, two career bottlenecks tend to appear very early for product managers. These two bottlenecks also define a product’s breadth and depth.
A product creates value by solving one or more user needs through a high-quality way of satisfying those needs. In essence, it improves efficiency within the user’s real-life context. To make that value visible and usable, two things become crucial: experience and structure.
User experience
Every product is, in practice, an attempt to satisfy a user need through a new experience. That is why user experience is foundational knowledge for product managers.
In many companies, product experience is not owned by a dedicated specialist. There may be no separate person fully responsible for UX or UI decisions. In those situations, the product manager becomes the person who makes the final call. The higher the product manager’s level, the higher the ceiling of the product experience.
That makes user experience the first major bottleneck most product managers need to break through.
User experience starts with a user-centered design mindset and applies a goal-directed design approach to internet products. That means understanding users’ expectations, needs, motivations, and contexts of use. More importantly, it means understanding their goals, and how those goals should shape interaction behavior.
The key is to identify user goals more clearly and focus on those goals rather than obsessing over the tasks users must perform. The path from intention to outcome should be simplified as much as possible.
Put more bluntly: users are not stupid, but they are far lazier than most product teams imagine. Unless your product has the pull of a hard, unavoidable need, you should avoid increasing the user’s learning cost or operational burden.
There are many ways to improve in this area. Reading platform design guidelines helps. So does studying articles and case sharing from well-known UED teams, which also exposes you to the tools, technologies, and methods used by leading companies. Training can help too.
But there is also a more direct way to build judgment: spend serious time using products.
Your hands rarely outperform your eyes. If you want to design better, you need to see better first. A practical way to train yourself is to take one product a day and study it deeply—its features, its interaction flows, its strengths, and its weaknesses. If you do that consistently, even for a month, your understanding can move up a level.
Product architecture
A product manager who understands nothing about technology will never become a strong architect.
Many people struggle in product roles for one important reason: they lack architectural knowledge. In reality, product planning and product design are, to a large extent, architecture planning and architecture design.
Only large companies usually have dedicated architects. In many organizations, the product manager is effectively filling that role as well. But architecture leans toward the technical side, and technical ability is not something you can fake or acquire overnight. That is why so many people have a slow start in product management: they do not have enough technical accumulation.
Following the program formula mentioned earlier, product architecture is inseparable from data structures. Data structures are heavily technical, but product managers can gradually approach the same logic through information architecture. That is also why information structure deserves top priority when writing product requirements.
Technical architecture and product architecture are not the same thing. Product managers usually do not need to master the full technical architecture. What they do need is a solid grasp of product architecture: the product’s information structure and the logic that drives it.
No one understands a product’s requirements, intent, and future direction more clearly than the product manager. That is why the product manager must keep the product’s architecture from becoming chaotic. As long as the information structure is sound, there can be many ways to design the logic on top of it. Once that foundation is in place, the interaction layer can express many different user experiences. Architecture is the lowest layer of the product, but also its most central foundation.
There are fewer shortcuts for breaking through this bottleneck. The main requirement is to understand some technical principles and common technical knowledge. Learning at least some data structure concepts is extremely useful.
In the United States, product managers often come from computer-related backgrounds, and many move into product from engineering. In China, by contrast, product managers come from all kinds of fields, so many lack technical grounding. One common result is messy product architecture.
Another factor that shapes architecture is the product model, which leans more toward the market and business side. That side is usually not the biggest bottleneck. If you can identify a viable market or business model, execution there is often more straightforward. The harder problem is when you can see the market opportunity or the business logic, but cannot come up with a product architecture capable of supporting it.
For product managers, these two bottlenecks—user experience and product architecture—appear early, and they set the limits of what kind of products you can actually build.