The household should not have to fit inside one moving date

One moving date seemed like an elegant place to begin. It gave the planner a clear centre and let us arrange the surrounding tasks in an orderly sequence. I approved that structure. In a later study of thirty-two households, twenty-one described a phased move and eleven a single stage. The product had asked several different decisions to become one event. The resulting awkwardness appeared in the user's answers, but its source was the model we had chosen.

A person might begin a new job before the rest of the household could follow. Belongings might move in another stage. Temporary accommodation could sit between the work start and a more settled arrangement. These examples did not mean that every household needed an elaborate plan. They showed that the date which made our screen simple did not always describe the situation the screen was supposed to help. Treating the difference as an exception would preserve the design by making users work around it.

Find the decisions behind the convenient field

The study changed the first question I wanted product colleagues to ask. Before choosing an organising field, what decisions are the people actually trying to coordinate? A date can be a useful representation of one of them. It becomes misleading when the product uses it to stand for several commitments with different owners and conditions. The right response is not necessarily more fields. It is a clearer account of the relationships the product must represent before the interface is simplified.

The commercial objection was reasonable. One date made the product easy to demonstrate and the opening task quick to understand. A more flexible model could overwhelm users who did have a straightforward move. Support could help the others without changing the main experience. I did not dismiss that concern. Product complexity has a cost, and a research finding does not automatically justify exposing every possible variation to every person who opens the planner.

I chose to retain a single-stage route while allowing separate stages where needed. The ₹39 lakh redesign had to explain how those stages related without turning the first screen into a catalogue of every conceivable move. That was harder than adding an exception note. It required the product to stop treating one sequence as the natural form of the household and start treating it as one supported situation among others. The choice gave up some demonstration simplicity in exchange for a more faithful planning account.

Our software remained a planner. Independent providers retained quotations, schedules, acceptance, transport and safety decisions. A household could describe an intention in the product without the provider having confirmed it. This boundary became especially important once several stages were visible. The timeline could help people see dependencies, but it could not make external arrangements true merely by drawing them in order. Product structure and provider commitment needed to remain distinguishable throughout the experience.

Preserve a simple path without making it compulsory

A common design mistake is to confuse a useful default with a universal requirement. The single-stage path still served the eleven households whose study accounts fitted it. Removing it in the name of flexibility would make their experience worse for no demonstrated reason. The work was to preserve that path while making the alternatives intelligible. Simplicity should reduce unnecessary effort for a particular situation, not erase the situations the chosen shortcut cannot describe.

We tested the revised planner with a distinct group of twelve households. Nine completed the planning task without assistance and three needed help. I retain the three in the account because they show that a more accurate model is not automatically an easy product. Users still have to understand the choices and their relationships. The next design work should investigate those difficulties rather than treat the new model as finished simply because it represents more of the household's circumstances.

The pilot group also cannot establish a market-wide preference for phased moving. The earlier study and later pilot were different exercises with different purposes. One helped us understand situations; the other examined use of the revised planner. Combining their counts into a broad success percentage would make the evidence appear more comprehensive than it was. A product leader should be able to describe a useful decision without borrowing certainty from a study that did not answer the wider question.

There is a further organisational cost. A flexible planning model can change support scripts, product explanations and the way employer-sponsored users discuss progress. Colleagues need to understand what a stage means and what completion of it actually records. If the interface becomes more faithful while the surrounding service still assumes one date, the same difficulty will reappear elsewhere. Product responsibility therefore includes the explanation and support needed to make the revised structure usable beyond the screen.

Keep planning evidence separate from a completed move

Nine completed planning tasks are not nine successful relocations. The distinction sounds obvious when stated directly, but product reporting can blur it through convenient language. A person reaching the end of a flow has accomplished something within the software. The actual move depends on agreements, availability and work outside it. The case should record the planning result without allowing it to imply that the household's broader transition has been completed or every provider has delivered successfully.

That restraint does not make the product achievement trivial. Helping a household represent its real situation can be valuable even before the later arrangements occur. The value needs to be described in the terms the evidence supports. We changed a model that forced inaccurate simplification, observed how a small group used the revision and identified continuing assistance needs. Those are concrete outcomes. Inventing a later transport success would add confidence without adding evidence.

I would now bring the household's decision structure into the earliest product brief. I would ask which parts can share a date, which depend on another party and which may remain undecided while useful planning continues. I would also involve support in interpreting the study before deciding that an unusual answer can be handled outside the main design. An exception is sometimes a legitimate edge case. Sometimes it is the clearest sign that the product has mistaken its own convenience for the user's reality.

For directors considering a product-led service, the practical question is what the simplified model leaves out and who carries the resulting work. A clear interface can still transfer complexity to customers or support colleagues. The board need not design the planner to ask whether management has understood that trade-off. My own approval belongs in this story because it shows the leadership judgement involved. The product improved when I stopped asking households to fit the model and began asking which model would let them make their actual next decision.