Question before executing: a product manager's practice of ROI thinking.

There is a kind of moment in product work that nobody really teaches you how to handle. The CEO walks in with energy and a bold idea. It sounds forward-looking and powerful. It is not a small requirement. It needs real investment, real people, and real time. The CTO and technical leads are highly execution-focused, ask no questions, and start moving the same day.

Then they look at you and ask, "You are our product manager. What do you think?" You have no market report, no special user research, no competitor revenue numbers, and almost none of the data you would ideally want. But you still need to make a judgment, because a product manager is not only there to pass requirements downstream. A product manager should also think clearly about whether a requirement is worth passing on at all.

At that time I was working as a product manager at Qingyue Technology, a subsidiary of Fengwu Technology. We were planning an app for home-based elderly care, covering health records, medication reminders, meal ordering, emergency contacts, home patrol monitoring, and video calls. The original direction was to run this system on smart fridge screens or on the company's existing home control devices, which already made sense as a family information hub.

A product manager's first responsibility is to question before execution.

Before that direction was settled, the CEO proposed something completely different: build a physical home robot and make it the hardware carrier for the whole system. The idea was that it would feel highly technological, innovative, and attractive as a funding story. The CTO team started scheduling work immediately. Nobody questioned it. I started doing what I thought I should do.

Many people think the main job of a product manager is to clarify requirements and hand them to the team. I think that is only half true. A more important part of the role is to judge, before execution begins, whether the requirement itself deserves to be executed.

This is especially difficult when the requirement comes from the top. The CEO's idea carries authority, the CTO team is already moving, and the whole organisation is leaning in one direction. Questioning it in that situation requires both courage and a solid enough logic to make the challenge worth listening to.

I used ROI as my framework. Not as a precise financial formula, but as a way to split the question into two parts: the investment side and the return side. In other words: what would this require from us, and what could it realistically give back? This structure helped me turn a vague feeling that something was wrong into something that could actually be discussed.

On the investment side, the real cost was much larger than it first appeared. We already had three hardware engineers, but they were expensive, fully loaded on existing work, and none of them felt confident about building a robot from scratch. I also consulted a friend working on robotics at another company, and his feedback confirmed that the key roles needed for this kind of project were rare, expensive, and hard to retain.

Because of that concern, the product and R&D teams later chose a more pragmatic path: they bought several second-hand robots from other brands and studied them, exploring whether we might cooperate with an existing manufacturer rather than build the whole hardware stack ourselves. That was a reasonable way to test assumptions at lower cost. But it also revealed something important: even the team itself already sensed that full in-house robot development was too risky and too expensive.

Time was another major cost. Hardware takes mechanical design, prototyping cycles, hardware-software integration, supply chain preparation, quality checks, and certification. It is measured in years, not months. There was also financial pressure. The company had recently completed a funding round, but a large amount of capital had already been tied up in property-company acquisitions and integration. A new hardware track would compete for budget, attention, and coordination bandwidth with the existing app product. And after launch, hardware would bring ongoing maintenance, customer support, repair logistics, supply-chain management, and recall risk.

This was the most important and also the hardest part of the analysis. Without clean research data, I had to make an honest judgment about the market. My method was: first build a clear user picture, then estimate market size from that picture, and then test whether the product's value proposition could really stand on that size.

The target user was "elderly people living at home," but that is not yet a user picture. A product manager needs to ask: within that group, who would actually buy this, and why? In China at that time, most older users came from generations with strong expectations around family-based care. For someone in that group to accept a robot in the living room, they would need enough technical acceptance, a relatively independent lifestyle, and a family budget strong enough to absorb a product whose hardware cost alone could exceed 10,000 RMB.

Through a Jobs-to-be-Done lens, I asked: what job would an elderly person actually hire a home robot to do? The team's planned feature set was complete and coherent: health records, medication reminders, meal ordering, emergency contacts, patrol monitoring, and video calls. But the issue was not whether the robot could do these things. The issue was whether they were already possible through tools that were cheaper and more familiar.

Medication reminders and video calls could already run on phones or tablets. Safety monitoring could be handled by existing home cameras. The companionship part, which would have made a robot feel genuinely different, depended on AI capability that did not yet exist in practical form. In other words, the problem was not a lack of functions. The problem was that the same functions already had good-enough alternatives at much lower cost.

The labour-replacement logic also looked weak in China at that time. In markets where caregiver labour is very expensive, a care robot can have a stronger economic case. In China, hiring part-time or live-in support was not prohibitively expensive for many middle-class families, so the economic logic for replacing that with expensive, unproven hardware was not strong.

There was also the AI gap. At that time, large language models had not matured. The kind of natural conversational capability that would make a care robot truly useful did not exist in any practical form. And because the company was already maintaining an expensive AI team around computer vision and specialised models, closing that gap would have meant a major hidden cost that had not been fully accounted for on the investment side.

After thinking through both the investment and return sides, I realised there was another question a product manager should always ask: is there a lower-cost and faster path that can still satisfy the same need? In this case, that path was software on existing devices. If the same system could run on home control screens, tablets, phones, and existing cameras, the user's added cost would be near zero, the development cycle would be shorter, and the market direction could be validated much faster.

This was not an argument that hardware is always wrong. It was an argument that when two paths can move toward the same destination, and one has a much better cost structure and much lower execution risk, the other path needs a very strong reason to justify itself. At that time, I could not find that reason.

After finishing the analysis, I wrote an internal memo that captured the logic on both the investment and return sides, the user-picture judgment, and the software-iteration alternative. I made two things clear. First, from an ROI perspective, the case for building a home robot under those conditions was not strong enough. Second, using existing devices to carry the same software would be a lower-cost and faster way to validate the market direction.

That memo was never really passed up the chain. The CEO's direction had already been set, the CTO team was already executing, and the organisation's momentum did not stop there. The robot was built over the course of nearly a year, appeared as a concept prototype, and never truly entered the market.

I do not know whether the outcome would have been different if that analysis had been seriously discussed. Maybe not. But I still believe the judgment itself had value, even though it did not change the final decision.

I want to say something directly here: a product manager's value is not only in executing well after a decision has already been made. A product manager's value is also in thinking clearly about the conditions under which that decision should be made in the first place.

In this case, the initiator was the CEO, the executors were the CTO and technical leads, no one was really expecting me to question the requirement, and I did not have complete data. In that kind of situation, silence is the easiest choice. It is also the least responsible one.

If a product manager only writes requirements, designs flows, and follows delivery, but stays silent when the upstream requirement itself is wrong, then the organisation is simply moving more efficiently in the wrong direction. That is not strong execution. That is wasted efficiency.

What I learned from this was not only how to use ROI thinking. I learned that the right to question a requirement is part of the professional identity of a product manager. Even without perfect data, you still have a framework. Even if your framework is not adopted, you still did what the role required.

One more thing is worth saying. When this happened, large language models had not yet matured. The conversational and reasoning capability that would make a care robot truly useful did not exist in practical form. Today the situation is different. Embodied AI is a real developing field, and the demographics and economics of other markets may lead to a different conclusion.

If I were evaluating the same idea today, I would need to redo the analysis from the beginning: different market, different user group, different cost structure, different technology baseline. That does not overturn the original judgment. It only reminds me that product judgments have a shelf life, and knowing when to re-evaluate them is itself part of the work.

If you have ever been asked to weigh in on a top-down requirement without enough data, and your analysis still failed to change the result, then you may recognise this situation. It is more common than people admit.

To me, questioning a requirement is part of what it means to be a product manager. It is not optional. It is part of the role.