My work on Kindred Hands included the e-commerce platform and multi-vendor functionality. The wider project also involved research and integration of virtual try-on. Those are different kinds of work, and I find them more useful to explain separately than to collect under the word advanced. Integrating an existing model is a different responsibility from creating that model.
The purpose gives the choices a direction: helping weavers and handicraft producers reach customers more directly. I was bringing the software setup together with guidance. That makes the requirement question practical. A capability should have a job in the service, rather than become essential only because it appears on an attractive feature page. I enjoy unfamiliar ideas, but the initiative should not have to depend on every idea I happen to find interesting.
I'm starting with three roles in my head: the person supplying a product, the person looking after the site and the person interested in buying. One person may do more than one job. What matters is that the jobs do not get lost when I start comparing software names.
For the supplier, I want to understand how the information reaches the site and who helps if that step is unfamiliar. For the person managing the site, I want to understand what needs checking and where a question needs attention. For the buyer, I want the product and the next step to make sense. Those are ordinary requirements. They become quite useful when I ask a tool to explain how it helps with them.
A choice shows the difference. In this case, one option offers an impressive extra display, while another makes it easier to keep product availability clear. If our immediate difficulty is knowing whether the product can actually be supplied, the less impressive-sounding function could matter more. That’s not an argument against the extra display forever. It’s a reason to explain why it belongs in this version before spending time on it.
The hard part is that I genuinely enjoy figuring out unfamiliar things. Following an extra feature can be a good learning experience. It just should not quietly become a requirement for an organisation because I happened to find it interesting. I have to separate what I want to explore from what somebody using Kindred Hands needs me to finish.
There’s a similar problem with replacing software. If I insist that the new combination must match every feature of the first option, I could give myself a large integration task without checking whether the missing features matter. Some differences may be perfectly acceptable. Others could break an essential task. I need a way to tell which is which, rather than treat every missing tick in the table as equally serious.
The useful question is what happens without a feature. Can a person still complete the job clearly? Does somebody have to do extra work manually? Is that extra work manageable, or does it depend on the same person remembering something every time? The answer could make a modest feature essential. It could also show that something with an impressive name is safe to postpone.
I want the smaller requirement list to have reasons beside it. “Needed” is easy to write. Explaining whose task depends on it makes the decision easier to discuss. It also gives me a way to change my mind later. If a new need appears, I can look at the old reason instead of pretending the first list was a permanent truth.
This is a helpful point to involve my mentor and people who understand the organisation's work. I can investigate how a tool behaves, but I should not decide by myself that somebody else can absorb an extra task. A technically convenient arrangement can still be awkward for the person who has to use it. That’s the part a feature table is least likely to show me.
I’m also thinking about what deserves to be left out of the first round. Leaving something out can feel like admitting the site is incomplete. But there is a difference between an unfinished essential task and an additional idea that can wait. I would rather understand that difference than keep the project permanently almost finished because another interesting option appeared.
One test I find useful is to imagine explaining the feature without mentioning the software. If I can say whose difficulty it removes, I have a reason to keep investigating it. If all I can say is that it would make the platform more advanced, I probably need a better reason. Being able to build something is an exciting possibility. It does not answer whether this is the thing the organisation needs from me first.
The shorter list is not a punishment for being curious. It’s a way to give that curiosity somewhere useful to go. Once I know the job I’m trying to support, I can explore the software with much better questions. I’m still allowed to be interested in the extra things. I just do not have to make Kindred Hands depend on all of them at once.