Episode #24: Richard Ferreira on Evidence-Led Product Decisions

Richard Ferreira took what he calls a scenic route into product management. Growing up in Mozambique, he later studied graphic design and web development in South Africa, then moved into mechanical engineering. Those experiences now help him work across design, software, and technical problem solving without treating any one discipline as the whole answer.

His conversation with Dwayne Samuels focuses on a practical question for product teams: how do you move from an idea or feature request to evidence strong enough to justify building? Richard explains how his work at venture builder The Delta combines discovery, experiments, prioritization, and delivery, especially when a young company has limited runway.

What you'll learn

• Why a feature request should trigger questions about the underlying need, not immediate implementation

• How to build a progressive line of validation from interviews, prototypes, landing pages, and observed behavior

• Why what users do generally provides stronger evidence than what they say

• How a scoring matrix can support prioritization without replacing product vision or judgment

• When asking a teammate for help is more valuable than continuing alone

Translate requests into problems

Richard's design and development background helps him understand how designers and engineers describe their work. That shared language creates mutual respect, but it also carries a risk: technical experience can pull a product manager toward solutions too early. Richard says he had to unlearn the habit of accepting requirements as fixed and immediately asking what could be built.

His preferred response to a feature request is to keep a neutral mind and investigate why the user wants it. The request is one possible solution, not necessarily the best expression of the problem. Once he has identified the likely root need, he can bring that need to developers and invite them to form product hypotheses. Engineers can compare implementation paths, surface constraints, and suggest approaches that the original request did not anticipate.

An earlier role involving artificial heart valves sharpened this shift in perspective. The technical device mattered, but so did the doctor who would use it to implant a valve. Thinking about that real usage context pushed Richard to spend more time in the problem space before committing to a solution.

Build evidence in stages

At The Delta, ideas are examined through desirability, feasibility, and viability. Richard describes validation as progressive: each step should produce stronger evidence and earn the next investment. In short engagements, he worked across more than ten projects, often running quick experiments to decide whether an idea was ready to advance. In a longer client engagement, discovery and delivery run alongside one another.

A discovery pipeline can start by aggregating feedback, current knowledge, and the venture's intended direction. The team forms hypotheses about what users may want, creates the simplest useful representation, and tests it. The sequence might include a customer interview, a prototype, a landing page, and a more realistic emulation of the experience.

The important distinction is evidence strength. An opinion or stated intention is useful, but observed behavior carries more weight. Teams should look at what people actually do, combine qualitative and quantitative findings, and assess how strongly the result supports a value proposition. The evidence can feed a scoring matrix, but Richard does not present scoring as an automatic answer. It creates a common baseline for discussion, which still has to be checked against the startup's mission and vision.

Prioritize for the moment you are in

For an early-stage company, the key question is not simply whether a feature is worth building. It is whether it is worth building now. Runway, funding milestones, and the need to get something valuable into users' hands all affect the answer. Choosing one item also means delaying another, while growth, sales, and product may each advocate for a different priority.

Richard aims for an option that is good enough for the current moment, is not fatal, and can be revisited as evidence improves. That framing makes prioritization less about proving one department right and more about preserving the company's ability to learn.

He applies the same judgment to his own work. His instinct was once to struggle with every problem until he had mastered it. He now distinguishes between problems that reward a deep solo investigation and problems where an early conversation with a tech lead prevents wasted effort. That willingness to ask for help has become part of how he moves work forward.

Listen to Episode #24 for Richard's full discussion of venture validation, evidence, and prioritization.