Applying artificial intelligence in a company starts with identifying a task, explaining its context and deciding how the result will be reviewed. Xavi Laballós, co-founder of Growth Hacking Course, talks with Edgar Guerrero about practical adoption and the training needed to make good use of it. Episode 26 of Toque de Ingenio applies these questions to an engineering company’s work: what to delegate, what information to provide and which decisions must retain professional judgement.
Guest: Xavi Laballós, co-founder of Growth Hacking Course and TheGrowthAgency.io.
Interview published: November 4, 2024. Episode: 26. Duration: 1 hour and 48 minutes
In this episode:
- How to move from using AI for isolated tests to integrating it into regular, everyday tasks.
- Why context, documentation, and review influence the quality of the responses.
- What’s the difference between simply getting a draft and completing an entire business process?
The interview was recorded within the technological context of 2024. It includes opinions and forecasts about models that were on the horizon at that time, as well as examples of the functions available at the time. This article focuses on the lessons learned regarding organization and adoption, and does not use those forecasts as descriptions of current tools.
Artificial intelligence for businesses: start with the basics.
Xavi recalls that his first experience with a complex request was disappointing. He uses this as a starting point to explain that the outcome also depends on how the task is approached and what is hoped to be achieved.
A company can test a tool and then abandon it after receiving an unhelpful response. It can also become overly reliant on a seemingly convincing output. Between these two extremes lies a crucial process: defining the task, providing the necessary information, and establishing criteria for evaluating the response.
Within an engineering firm, this approach allows for the study of activities such as preparing an initial document structure, organizing information, or formulating questions for a technical meeting. The effectiveness of this method should be evaluated against a real-world case. However, the project’s objectives and the responsibility for the deliverables remain with the team.
Xavi insists on reviewing his regular tasks and considering how AI can be helpful. He’s talking about freeing up time for activities that don’t receive as much attention. The key is to improve an existing task, rather than simply adding a tool without a clear purpose.
Transforming knowledge of a process into useful instructions.
Edgar describes how he was experimenting with personalized assistants for departments within his company. Xavi suggests starting by mapping out the process, testing the requests, and understanding what information the tool needs before it becomes a repeatable workflow.
The interview focuses these applications particularly on:
“the routine tasks”.
Xavi Laballós 20:39.
This expression doesn’t mean that any frequently performed task can be fully automated. It helps to identify opportunities where a pattern exists and where a specific desired outcome can be defined. If the conditions change, the instruction or necessary review can also adapt.
The exercise requires making explicit the knowledge that is often present in a person’s mind. Questions about the data consulted, the steps followed, and any exceptions that arise are useful, even before using AI. Documenting this process makes it easier for others to understand the procedure.
This project of requirements connects with product development and engineering: A solution is defined by the problem it’s intended to address. The technology chosen is part of the solution, but the context and acceptance criteria allow us to assess whether it truly helps.
The context is more important than a very general request.
Xavi and Edgar dedicate a block of time to writing instructions. They use examples from extensive documentation projects to illustrate the difficulty of requesting a complex outcome in a single request, without explaining its components.
For an industrial project, the equivalent would be to request a proposal without specifying the application, any restrictions, or the intended recipient. A response might appear complete, but it could be based on assumptions that don’t align with the actual work.
The editorial alternative suggested by this episode is to break down the approach into understandable decisions: what is needed, what information is already available, what format would be useful, and which points need to be reviewed. This organization helps to identify gaps and prevents confusing the flow of writing with technical accuracy.
It’s also important to differentiate between the material that has been provided and the conclusions drawn from it. When someone is summarizing documentation for a project, they need to be able to refer back to the original sources and verify the relevant data.
Team formation, adoption, and autonomy.
Edgar raises a question about his own approach: preparing assistants to work with colleagues can yield quick results, but it doesn’t necessarily involve teaching them how to build or review those processes. Xavi describes a progressive training method based on practical experience and guidance.
The difference is crucial for a business. A tool reliant on a single person may function during a demonstration, but can become difficult to maintain as needs change. Successful adoption requires the team to understand what it does, when it’s helpful, and its limitations.
Training can be based on real tasks within each department. This way, the individual compares the outcome with a task they are familiar with, and learns to identify errors or insufficient instructions. Reviewing then moves beyond being a generic step and becomes a concrete check.
In projects of Industrial automation, The principle of user participation is also relevant, although the technology and demands are different. Those who are familiar with the process can provide restrictions and situations that an initial description might overlook.
Drafts, outcomes, and professional accountability.
During the conversation, Xavi clarifies that AI does not fully carry out every task in which it is involved. This distinction helps explain his productivity examples. Getting help with part of the work does not mean eliminating the entire process that follows.
He expresses it with a casual warning:
“This isn’t Yupi’s world”.
Xavi Laballós 37:26.
Submitting an application to an engineering firm requires a clear approach: any structure, explanation, or preliminary proposal should be evaluated based on its intended use. A decision regarding design, manufacture, or operation needs evidence and a review proportionate to its impact.
The interview also addresses errors in the responses and the habit of comparing search results. Its value lies in reminding us that the ease of obtaining information does not replace verification. The source, date, and context remain an essential part of the quality of the work.
How a company’s search process is changing.
Edgar presents an example particularly linked to i-mas: finding a company that provides a specific service in a particular location. The conversation explores how participants can get involved in this discovery and what might happen with traditional search engines.
These are opinions formulated in 2024, not a previously verified forecast. However, the example helps to understand a stable need for an industrial website: to clearly explain what the company does, for whom, and to what extent.
One page Electronic engineering And a prototyping page addresses different questions. The cases, the people, and the related services allow the reader to understand each capability. This content should be both useful and verifiable, whether discovered through a search engine or by a virtual assistant.
Questions about AI in engineering work.
Where should we begin applying AI in an industrial company?
For a specific task with a verifiable outcome. This episode proposes observing regular activities, explaining their context, and testing the process. A small, manageable scope allows for assessing its usefulness before wider implementation.
What should the team retain when using an assistant?
Understanding the objective, the review criteria, and the responsibility for what is delivered. The tool can assist in preparing materials, but the team must verify that it aligns with the project and that it does not introduce incorrect data or assumptions.
Why is it useful to document the process before automating it?
Because it allows you to see their entries, decisions, and exceptions. This information helps to build instructions and to identify where a response stops being appropriate. It also makes it easier for other members of the team to understand and maintain the way of working.
Four lessons for adopting technology thoughtfully.
- Choosing a real task and defining how the usefulness of the assistance will be measured.
- Provide context and compare the relevant data with its sources.
- Train the people who will use and review the process.
- Distinguishing the process of preparing a draft for the validation of a technical decision.
At i-mas, product, electronics, and automation projects are defined based on requirements and usage conditions. If you need to develop an industrial solution, you can Please explain the process or product you want to improve. To define its scope.
To continue reading: Artificial intelligence and industrial design with Àlex Casabò.
Source of article: Edgar Guerrero’s interview with Xavi Laballós on Toque de Ingenio, published on 4 November 2024. The number 26 appears in the official YouTube and episode titles; the numerical field in the RSS feed contains a discrepancy. Quotations link to their original passages.
