Episode #12: Learning Before Building with Angel Jaime

Small teams cannot always wait for perfect data. In this episode, Angel Jaime explains how product managers can learn quickly with qualitative research, lightweight experiments, and a team that understands the context behind changing priorities.

What you'll learn

• How Angel moved from operations into product management by taking on bugs, projects, and a backlog

• Why a small user base can make traditional A/B testing less useful

• How to separate discovery conversations from prototype validation

• How a notification framework helped a Booking.com team test many ideas before building full features

• Why over-communication, delegation, and trust matter in a fast-moving startup

Choose research methods that fit your scale

Angel's path into product management began in operations at Booking.com. As he worked more closely with engineers and designers, his responsibilities grew from fixing bugs to leading larger projects. Eventually, he was managing a backlog with a development team and was told that he was already doing the work of a product manager.

His later move to Yayzy introduced a different operating environment. The company had a team of about 15 people at the time of the interview, so Angel's role extended beyond typical product work. He might spend one part of the day on the product and another developing a recruiting process for engineers or creating a process to support UX designers' professional development.

That scale also affects experimentation. With a relatively small user base, minor A/B test variations may not reach statistical significance quickly. The team can test on a higher-traffic website at the top of the funnel, but it relies more heavily on user testing, surveys, and in-depth interviews to understand product needs. The broader lesson is to select a method based on the decision and available evidence, not because a particular experiment is fashionable.

Separate discovery from validation

Angel describes two broad uses for qualitative research. Discovery is open-ended. The team speaks with people about their problems, their efforts to live more sustainably, and the behaviors connected to that goal. These conversations help the team understand the problem space before committing to a solution.

Validation is more focused. The team may give a new or returning user a scenario, present a prototype or the actual app, and observe how that person attempts to solve a defined problem. The interview structure remains flexible, but it follows a few fundamentals: help the participant feel comfortable, ask open questions, establish the problem context, and avoid placing random solutions in front of the user.

This distinction protects teams from confusing interest in a concept with evidence that an experience works. Discovery informs which problems deserve attention. Validation examines whether a proposed solution makes sense to the intended user in a realistic context.

Build an experiment system, not every feature

Angel shares a concrete example from Booking.com. The company wanted to serve more holiday-home and small-accommodation partners, but its existing partner portal was complex and contained capabilities many of those partners did not need. Rather than immediately building a complete mobile product, the team created a simple app and a framework for testing different notification ideas.

The app included a basic dashboard with operational information, such as check-ins, checkouts, and new reviews, plus a timeline of notifications. An internal tool let the team manually send different messages to selected partner segments. A message might flag a new booking, point to a new review, or suggest adding availability for a sold-out period. Each notification linked back to the existing portal.

This setup allowed the team to compare which partners engaged with which prompts before developing full functionality around the most useful prompts. The investment was not in a long list of speculative features. It was in an engine that could test many hypotheses. As Angel puts it, a small amount of learning helped the team focus its development time on the right things.

Keep the team informed and empowered

Fast-moving startups change direction, which makes alignment a daily product responsibility. Angel prefers to over-communicate rather than leave teammates surprised. Sharing product performance, newly discovered challenges, opportunities, and the reasons behind a pivot gives people enough context to respond well.

He also learned to delegate, trust people, and focus on empowerment. A product manager cannot be everywhere or do every task. Giving teammates meaningful responsibility helps them gain skills and experience while freeing the product manager to concentrate on work that cannot be delegated.

The episode offers a practical operating model: learn before building, create reusable ways to test assumptions, and keep the team close to the context. Listen to Episode 12 on Spotify for the full conversation between Angel and host Dwayne Samuels.