I start from the problem and from what we still do not know about it.
The work combines analysis, investigation, engineering, and validation. Depending on the engagement, it may lead to a strategic decision, an organizational model, an architecture, a prototype, an MVP, or a technological solution.
Before choosing technology or proposing a solution, I need to understand what is really happening: what the organization is trying to achieve, which actors are involved, what constraints exist, what has been tried, and what consequences the problem has.
What are we really trying to solve?
Complex problems are often distributed across people, processes, systems, and documents. Building a shared representation —a model, flow, map, or conceptual architecture— makes it possible to reason about the whole and detect relationships that would otherwise remain hidden.
How can we represent the situation so we can think about it?
When there are unknowns, they need to be reduced. This may involve reviewing existing knowledge, analyzing data, evaluating technologies, building experiments, testing hypotheses, or studying how a similar problem has been solved in other contexts.
Depending on the problem, techniques such as machine learning, generative AI, computer vision, NLP, graphs, simulation, or other approaches may be involved. They are means to obtain evidence and decide better, not the starting point.
What do we need to learn before deciding?
Investigation is not the final objective. The knowledge gained must become criteria: choosing a direction, reducing scope, prioritizing, discarding alternatives, or deciding that more evidence is still needed.
Given what we know now, which path makes the most sense?
A useful decision must be able to become something real. Depending on the problem, it may materialize as a strategy, roadmap, governance model, process, architecture, prototype, MVP, or system. When the response is technological, I can also participate in the architecture, development, and validation of an initial solution, without reducing the work to mere technical execution.
What do we need to build or define to put the decision into practice?
Validation is not only about checking that something works technically. It must also confirm that it solves the problem that originated the work, that it can be used in its context, and that the initial hypotheses remain valid.
Validation may include QA criteria, metrics, functional and load tests, behavior of the complete system, operation, and usage feedback.
Does the response work for what we actually needed to solve?
A test may force a hypothesis to be reviewed. An integration problem may change the architecture. A finding may modify the initial understanding. Going back is not leaving the process; it is learning before continuing to invest.