AI Experimentation in Low-Code Development with Magda Pereira | Episode #36
Magda Pereira explains how product teams test AI features, connect research with delivery, and turn developer and design experience into product insight.
Magda Pereira's route to product ownership crossed project management, software development, and product design. Her first job was in project management, but after a year she returned to development because she wanted to understand what happened behind the scenes. Building software then made her more attentive to the experience surrounding the features she created, which led her into product design. Product ownership became a natural next step because it brought the technical and user perspectives together.
At OutSystems, a low-code platform for building web and mobile applications, Magda worked on embedding AI into the development environment. Her teams used models to offer logic suggestions and guidance when developers were stuck. In this conversation with Dwayne Samuels, she explains how a product owner can connect research and engineering, test uncertain ideas, and learn from mistakes without treating every experiment as a binary verdict.
What you'll learn
How development and product design experience can strengthen product ownership
Why AI product work requires close coordination between model research and application development
How hypothesis experiments differ from A/B tests on an existing feature
Which adoption, engagement, success, performance, and error signals can guide a test
Why regular reflection helps turn mistakes into specific improvements
Connect technical work to user value
Magda worked with two closely connected teams. One built within the OutSystems development environment, while the other researched and developed AI models. As her responsibility grew from one team to both, she spent more time defining the future product vision and identifying the steps that could move the current experience toward it.
Her development background helps her discuss implementation with engineers and recognize when a team needs space or a stronger push toward an ambitious goal. The value is not simply that she can follow technical details. She can also translate a feature into the user problem it addresses. She wants developers to understand why the work matters to people using the platform, not only what has to be delivered.
Her product design experience supports the other half of that translation. She enjoys talking with users, showing them new features, and hearing how they experience the product. Those conversations help her generate possible solutions, but ideas are starting points. Experimentation determines whether they deserve further investment.
Separate exploration from optimization
Magda describes two broad kinds of experiments. The first starts with a hypothesis about a problem and a feature that might help. The team can expose the idea to a limited group, observe it within a particular flow, and assess whether it supports the intended goal. The outcome may be to build, stop, or adjust the hypothesis before turning it into a production feature.
That middle outcome matters. An experiment can show promise while revealing that the concept still needs work. The team then has to compare the effort required to refine it with other hypotheses in its opportunity tree. The question is not only whether the feature could work, but whether this is the best place to invest more discovery and delivery effort.
A/B testing serves a different purpose once the team has a feature or alternatives ready to compare. Magda notes that teams can test interface details, backend behavior, performance, or errors depending on the goal. In one AI example, users could be segmented between two models and the team could compare adoption, engagement, and success. Production data then makes the difference between the versions visible.
The practical lesson is to define the uncertainty before choosing the test. A new concept needs evidence that the problem and proposed direction are useful. Two existing variants need a fair comparison tied to explicit measures. Calling both activities experimentation does not make their methods interchangeable.
Learn through a deliberate retrospective
Magda's curiosity is central to how she works. She describes situations where a book only made sense after later experience gave its ideas context. That gap is frustrating, but it also reinforces her commitment to learning from actual work.
When she makes a mistake, she asks why it happened, what it can teach her, and what she can do differently to avoid repeating it. She tries to conduct that retrospective daily or at least at the end of the week. For product teams working with uncertain AI behavior, that habit complements formal metrics: experiments improve the product, while reflection improves how the team designs the next experiment.
Listen to Episode #36 to hear Magda's full discussion with Dwayne Samuels.
Continue with the workflow pages
Use the ideas from this episode inside the selector, Playwright, and bug-reproduction pages that connect content to product intent.

