When Interaction Design and Product Management Started Feeling Closer

Recently, I keep coming back to one question: are interaction designers and product managers really as far apart as we often imagine?

I started thinking about this because my own work has changed a lot over the past few years. When I first entered AI music projects, I was still a very typical interaction designer. I cared about how users entered the creation flow, what they should input first, how to handle long generation times, how someone with no music creation experience could understand what AI could help them do, and how preview, editing, and payment should connect.

At that time, I naturally understood the problem as: how should this feature be designed? But the deeper I got into the project, the more the questions began to change.

From "How Do We Design It?" to "What Should We Build?"

In the earliest AI song creation work, much of the product logic still followed traditional music creation: users entered lyrics, selected a style, and generated a song. From an interaction perspective, that flow could be optimized endlessly. The entry point could be simpler, the input cost could be lower, and the generation process could be clearer.

But over time, I began to feel that the real problem might not be the flow itself. It was this: do ordinary users really think they are "composing"?

Most people may not know how to write lyrics. They may not understand genre, BPM, or arrangement. They may simply have a sentence they suddenly want to say, a story, a photo, a feeling, or a melody they hummed without thinking.

If what users truly want is to turn their own expression into a song, why should the product force them to begin the way professional music creation begins? That thinking later led us to explore conversational songwriting, image-to-song, one-sentence songwriting, and humming-to-song.

This stage changed me because it was the first time I clearly realized: I was no longer only optimizing an existing requirement. I was helping decide what the requirement should be. "How should this page work?" and "Does the user actually need this page?" are two very different kinds of work. The first looks for an answer. The second sometimes requires questioning the premise.

After Launch, I Started Understanding What "Results" Really Mean

Another shift was that I began to care much more about what happened after launch. In the past, it was easy for me to treat "the design went live" as the end of a stage. After working on commercial products, I started to understand that launch is often the real beginning.

Did users actually generate anything? Where did they drop off? Why did they not return after their first generation? Why were some people willing to generate again and again? Why did users choose not to pay after previewing? Did the experience we thought was smooth actually make users feel that creation was easier? All of these questions eventually show up in the data.

In AI Singing, we redesigned the preview and payment path. In AI song creation, we kept shortening the creation path and adjusting entry points and generation methods. When the business data later changed, I gained a different understanding of what a "design result" means.

It was not because I started believing data mattered more than experience. It was because I realized that design files are not the result. Passing review is not the result. Development completion is not the result. The real result is what happens after the product reaches users.

From that point on, the boundary of my responsibility started to expand. Before, I would think, "I need to be responsible for whether this feature feels smooth." Later, I found myself asking whether anyone was using it, why they were using it, whether it converted, whether it was worth further investment, and if performance was poor, whether the issue was the experience or whether the thing we chose to build was invalid from the beginning.

Vemus: Thinking from the Perspective of a Whole Product

If AI song creation brought me into product definition, Vemus was the first time I clearly thought from the perspective of a complete product. Building an independent app is completely different from building a feature inside QQ Music.

Mature platforms already come with many default answers. Why users open QQ Music, how accounts log in, how content is distributed, and how payment works are all supported by existing infrastructure. But for a 0-to-1 independent product, far fewer answers are already in place.

When working on Vemus, the question became: why do we need an independent AI music app at all? If QQ Music already has AI song creation, why would users download Vemus? Should it serve the same audience? Do users really need to generate one song once, or do they need a place where they can keep creating music? Why would someone come back the next day after their first generation?

I also had to think about what should matter most in the first phase: generation, consumption, community, identity, or content. Which features had to be built first? Which features looked attractive but would only slow the launch if we tried to include them too early?

By this point, it became difficult to separate the work cleanly into "product" and "design." Everything was connected. Product positioning shaped the home page. Model capability shaped user expectations. Commercialization affected the generation path. Engineering resources determined feature priority.

A plan that feels complete as an experience is not automatically worth investing in right now. And a feature that is not yet 100 percent complete may still be worth launching first if it can validate the most important product assumption faster.

I used to habitually ask: how can we make this better? After Vemus, I began asking more often: is this worth doing right now? That was a turning point for me, and one of the moments when I started moving from interaction design toward product management.

Mini-games: From Receiving Requirements to Creating the Project

What truly made me realize that I enjoy product work was a series of music mini-games I initiated later. These projects were different from most requirements I had received before because they did not exist at the beginning.

No one handed me a PRD saying, "We need a music mini-game. Please take charge of the design." It began with an opportunity I noticed myself.

Every time a music platform has a new song release, artist collaboration, or fan campaign, there are many promotional needs. But many traditional campaign formats are still pages, charts, check-ins, and lotteries. At that time, I kept thinking: why can't music be played?

A song has rhythm, lyrics, visuals, a worldview, and artist content. Why should those things only be displayed instead of becoming interaction mechanics? So I began actively proposing mini-games as a direction.

From that point on, the work was no longer an ordinary interaction design task. I needed to identify the right project opportunity, judge what kind of gameplay fit each song, propose the product concept, evaluate whether it could actually ship, find development resources, coordinate business, design, artist assets, and engineering, control scope, and still meet campaign and release timelines.

When development resources were limited, I continued from design into front-end implementation and deployment myself. Then the project launched, and I watched whether real users actually played it.

From One Song to a Small Product That Actually Launched

Take aespa's "LEMONADE" project as an example. No one began by telling me, "Let's make an ordering game." I first looked for parts of the song and artist content that could become interactive, then gradually turned the Lemonade concept into a playable scene.

During that process, I was no longer thinking only about whether the interface looked good or whether the buttons felt smooth. I had to ask: why this gameplay? Does it actually relate to the song? Can users understand it at first glance? Can they get feedback within one minute? Why would they want to play again? What level of complexity can our current resources support? To meet the launch timeline, what must stay, and what must be cut?

In the end, this project attracted more than 30,000 participants within four days after launch. Later, Lay Zhang's side-scrolling action project followed a similar process and gained more than 30,000 participants in three days.

Looking back, the most important thing is no longer just "I designed a few mini-games." It is that these were projects I actively initiated and carried all the way from idea to launch.

At the beginning, there was no requirement, no complete team, and not even a confirmed gameplay direction. I had to first prove that the direction was worth trying, then find the resources to make it happen. From opportunity identification, to product concept, gameplay definition, resource coordination, engineering delivery, and launch validation, the full chain felt very close to what a 0-to-1 product manager does.

I only realized later that I genuinely like this kind of work. I do not only like solving an existing problem well. I like discovering an opportunity that did not previously exist, then finding a way to make it happen.

From One Successful Case to a Repeatable Capability

After doing this several times, my focus shifted again. At first, I was asking: can this song become a game? Later, I began asking: can mini-games become a long-term capability for music products?

If an artist's new song can become a mini-game, what can be reused? Can gameplay mechanics be standardized? Can a song's BPM, sections, lyrics, and emotions directly inform the game mechanics? Which types of gameplay are better for acquisition, sharing, or fan retention?

I also started asking whether mini-games had to live only inside one-off H5 pages. Could they enter the player? Could they become part of digital albums? Could they connect with artist campaigns, membership benefits, or even offline experiences?

When I began asking these questions, I was no longer designing only one specific game. I was thinking: can a creative idea that worked once be turned into a product capability that works repeatedly?

That shift mattered to me. As a designer, I used to focus on making one experience as good as possible. Now I ask one step further: why did it work this time? Which parts can be reused? Will it still work next time? If we do it ten times a year, can the current method still hold up? Is this direction worth continued investment?

What Is the Difference Between Designers and Product Managers?

If you ask me now whether interaction designers and product managers should merge, I do not have an absolute answer. I do not think every designer should become a product manager. I also do not think the two roles will become exactly the same. In mature products, specialization still matters.

But I do increasingly feel that in AI products, innovative businesses, and 0-to-1 projects, the boundary between design and product becomes much more fluid. Many times, we do not yet know what the right product form should be. Is AI a tool? A creative partner? A content producer? A new way to consume media?

These answers are hard to define completely at the beginning. Often, you have to build something, let users try it, and then revise your judgment. A prototype itself can become product discussion. An interaction method can change the requirement. A single piece of user feedback can overturn the initial assumption.

At least in my own work, there is rarely a perfectly clean process where product defines the requirement, design executes, and engineering implements. More often, product and experience are shaped together.

Why I Believe I Can Become a Product Manager

Now, I actually do not really want to say that I am moving from design to product, because I do not feel that I have left design. Many of the judgments I make in product work still come from design training.

When discussing a feature, I still naturally ask whether users know it exists, why they would tap it, whether they understand it the first time, and whether a flow that makes sense logically also feels natural. Those habits do not disappear just because a title changes.

But now I keep thinking further. Why build this feature? Is it the most important thing right now? How many resources is it worth? How should we coordinate people to make it happen? When should it launch? What should we use after launch to judge whether it worked? If there is no result, should we keep optimizing it, or should we let it go?

I think this is the biggest change in me over the past few years. Before, I hoped I could be responsible for a good experience. Now, I also hope to be responsible for product direction, priority, resources, delivery, growth, business results, and even whether a project should continue or stop.

If I had to describe the biggest difference between designers and product managers, I would now put it this way: how large a result are you willing to be responsible for?

I still care about a button, a path, a piece of feedback, and whether an animation feels natural. But now I also want to know why that button exists, why the feature is worth building, why the product is needed by users, why it should be built now instead of something else, and after spending people's time and energy on it, whether it actually produced a result.

So for me, moving from interaction design toward product management is not leaving design. It is simply that I have started wanting to be responsible for a larger result.