What User Behavior Should a Product Change? The Product Manager's Main Question
Exploring the fundamental question that defines a product's meaning, and why without an answer, the product is doomed.
What User Behavior Should a Product Change? The Product Manager's Main Question
Teams can "do everything right" for months: design beautifully, develop quickly, release stably. But if user behavior hasn't shifted a millimeter, the product is likely dead. It just doesn't know it yet.
A product doesn't die from a lack of features. It dies from a lack of movement in the user's life. At the core of the PTOS methodology lies a simple, yet uncomfortable question that brings the team back from the world of features to the world of real value.
The Main Question
What user behavior must change for the product to have meaning?
If you cannot name a specific, observable change in a person's actions, you don't yet have a product. You have an idea, mockups, plans. But meaning—no. Meaning only appears when a person starts doing things differently.
Fundamental Principle: User → Value → Money
This chain lacks romance, but is full of meaning:
- User—the source of meaning. Neither the team, nor documentation, nor investor can "give meaning" to a product. Only the user can do this through their choice: to start using, to return, to integrate into habit.
- Value—is a change in behavior. Value is not something we invented and called "useful." It's what made the user change their habit. It's a measurable difference "before/after" in their actions.
- Was: "remember in my head" → Became: "record immediately."
- Was: "do once a month with pain" → Became: "do every day effortlessly."
- Money—proof of value, not the goal. Money (as well as time, risk, reputation) is the most honest test of reality. Payment is not an opinion, it's an action. It kills self-deception and proves that the value is real.
Why Is This So Important?
Because the team's brain loves busyness. It gives the illusion of control: "we're doing it, we're moving." The question "what behavior are we changing?" is uncomfortable. It's about responsibility. About reality. About the risk of suddenly realizing you've been building in the wrong direction.
But it is precisely this question that separates successful products from "feature factories" that produce a lot of noise but have no meaning.
How to Apply This in Practice?
- Explain the product without features. Try to describe it in three sentences, without naming any function, focusing on changing behavior.
- Formulate tasks as X → Y → M. * "Currently, the user does X. We want them to do Y. We will know this by metric M." *
- Define the "stake." What is the user willing to "pay" for value? Time for setup? Risk of data import? Money?
The most common reason for failure is not "lack of features." The most common reason is that the team couldn't answer the main question: what user behavior are we changing and how will we prove it? Ask this of yourself and your team every day.