My background in Informatics taught me how to solve technical problems. When something did not work, my instinct was to explore it directly, try different approaches, and ask questions when I reached a point I could not solve by myself. But my first role at Solve Education! taught me something that was harder to learn from code: the problem itself is rarely presented clearly.
Behind every technical request is a person working in a particular context. They may understand the problem through their daily tasks, while an engineer sees it through systems, data, and implementation. Before we can build a useful solution, those different perspectives have to be translated into a shared understanding. That process of translation has become one of the most important parts of how I learn and work.
When a Technical Problem Is Also a Context Problem
My first role at Solve Education! was an IT Specialist in People and Operations. I worked on automating internal business processes and frequently moved between different stakeholder contexts. At first, I approached the work mainly as a technical challenge: understand the steps, identify what could be automated, and build something that worked. But every stakeholder had a different way of working. A process that appeared simple from the outside could contain decisions, exceptions, and habits that were only visible to the people doing it every day.
This taught me that a technically correct system is not automatically a useful one. Before building, I needed to understand what people were actually trying to accomplish. Which part of the process was difficult? What information did they need? Which steps existed for a reason, and which ones were simply repeated because that was how the work had always been done? A more experienced teammate helped me see both sides of the work: how to approach the technical implementation and how to understand the context behind it. The task was not simply to convert a process into code. It was to translate someone’s working reality into a solution that still made sense to them.
Moving From Processes to Product Experiences
When I later moved into Product Engineering, the context changed again. I had to understand a new development workflow, learn how the existing product worked, and begin contributing to a product feature. My habit of exploring things directly helped me navigate the technical side, but product work introduced a different kind of question. Instead of only asking how a process should work, I also had to ask how someone would experience it.
One of my first assignments involved a new-user onboarding experience. The intention was to make the beginning of the product journey more relevant to different users. At first, I saw it as a sequence of screens and decisions that needed to be implemented. But the more I thought about the people entering the product, the less simple the experience became. Our users may come from different age groups, have different levels of familiarity with technology, or live with cognitive or visual impairments that affect how they understand information and navigate an interface.
That raised questions I could not answer by looking at the technical workflow alone. Would a new user understand what they were being asked to do? Would the information on the screen be clear enough? Could the same experience work for people with different abilities and levels of confidence? Were we making the product more relevant, or accidentally making the first step more difficult? These were not only design or engineering questions. They were questions about how accurately we understood the people we were building for.
Translating Needs Into Product Decisions
Personalisation often sounds like a technical capability: collect information, process it, and adjust the experience. But before deciding how to personalise something, we have to understand what information is actually meaningful to the user. We also have to make sure that collecting it does not create unnecessary difficulty.
A product team may describe a requirement in terms of screens, fields, and logic. A user experiences it differently. They see a question they may or may not understand, a button they need to find, and a reason to either continue or leave. The implementation has to connect those two perspectives.
This made me realise that Product Engineering involves more than turning requirements into working features. It also involves examining the assumptions inside those requirements. Who are we imagining when we say “the user”? What abilities are we assuming they have? What knowledge do we expect them to bring? What might be obvious to the product team but unfamiliar to someone opening the application for the first time? Asking these questions does not always produce an immediate answer, but it helps reveal where more understanding is needed before a technical decision becomes part of someone’s experience.
Tools Can Help, but Context Still Has to Be Learned
As I adapted to Product Engineering, I also began using AI-assisted development tools to help me explore unfamiliar systems and possible implementations. They helped me understand parts of an existing system, examine different approaches, and move more quickly from a question toward an implementation. But the usefulness of their output still depended on the context I provided and the judgment I applied afterward.
A tool can help explain what the code does. It cannot automatically know whether an onboarding question will make sense to someone with a different level of digital familiarity. It cannot decide which assumption about the user should be questioned, nor can it replace the conversations and observations that help a team understand why something should be built. The challenge was no longer only learning how to use a new tool. It was learning how to provide the right context and evaluate whether the result matched the actual problem.
Asking Before I Get Stuck
I still learn best by trying things directly. That part has not changed. What has changed is when I ask questions. Previously, I often asked for help after reaching a technical dead end. Now, I am learning that important questions should also be asked before the code becomes a dead end, or even before the code exists.
What is this person actually trying to do? What could make this experience difficult for them? Which part of the problem have I not understood? Are we translating the user’s needs accurately, or only building from our own assumptions? These questions help me move between technical systems, stakeholder perspectives, and product experiences without treating them as separate worlds.
The Skill Behind the Solution
Moving from internal automation to Product Engineering required me to learn new tools and workflows. But the most valuable skill was not a particular technology. It was learning how to enter a new context, understand how other people see the problem, and translate that understanding into something a team can build.
Technical tools will continue to change. They will help us explore, automate, and implement ideas faster. But a solution only becomes useful when it reflects the reality of the people behind the problem. Solving problems is part of technical work. Learning how to understand and translate them is what gives the solution its direction.