Genio Present

The origin of Genio Present was an internal Alpha Hack focused on opportunities in the DSA market. The event was deliberately built around an alpha mindset: prioritising learning over perfection, making something tangible quickly and then validating it afterwards.

Our team explored presentation anxiety and the rehearsal process. By the end of the hack week, we had shaped that thinking into an early concept called Yaply. The opportunity we saw was that most presentation tools focused on the final delivery, usually the slide deck itself, whereas we were more interested in what happened before that: how someone practised, became familiar with their content, built confidence and worked out what they needed to improve.

My role was to help take that early opportunity and turn it into something we could properly investigate, then stay with it through discovery, delivery and iteration rather than treating design as a separate stage.

We looked at the wider opportunity space, including competitor products in the DSA market, and started putting low-fidelity concepts in front of people using Ballpark. The direction was still open, so the goal was to understand the problem area and whether the idea was useful, not to get people to approve a finished design.

The research helped us understand how people were already rehearsing. Some practised in front of a mirror, some with friends or family, and others in groups at university. We also wanted the wider context: what they were studying, how presentations were assessed, how they prepared, how they shared material and where rehearsal fitted into everyday study.

Before moving into more direct research with students, the team worked with Legal on consent and the practicalities of involving people in early-stage testing. I then helped run moderated sessions and used rapid AI-assisted prototyping to make different directions concrete enough for people to react to.

That gave us evidence about what people expected, what surprised them, what they hoped the product would do and which parts of the idea were actually landing. I could take those insights back into the squad and use them to shape what we explored next.

We tried to make each step purposeful: test a hypothesis, answer the next important question and rule things out as we went rather than trying to solve the entire product at once.

That applied to both the user problem and the shape of the solution. We explored whether this should be a standalone product, a Chrome extension or something that lived inside tools like Google Slides, and used technical experiments alongside research to understand what was actually viable.

Engineering spikes surfaced constraints we could not have known from research alone. Google Slides’ API was too restrictive, browser speech-to-text was not reliable enough, and Slides and PowerPoint introduced synchronisation problems once we tried to layer rehearsal behaviour over them.

We also used simple tools like prioritisation matrices to balance desirability, value, feasibility and complexity. That helped bring the squad around the same problem, make trade-offs visible and give everyone a clearer sense of what we were testing next and why.

We deliberately combined qualitative and quantitative research because they answered different questions. The qualitative work helped us understand people’s frustrations, behaviours and environments in depth. Surveys helped us see whether the patterns we were hearing in individual conversations held up more broadly.

As the alpha developed, we kept relationships with testers rather than treating each session as a one-off activity. We could return to people with new ideas and working versions of the product, understand how they were actually using it and learn what was useful, confusing or still missing.

That combination became the evidence base we used to keep shaping the product. Research was not a referendum and it was not something we completed once. It was an ongoing input into product judgement.

What shipped

The released product covered the full rehearsal loop, from organising presentations and repeating practice to reviewing a transcript and deciding what to improve next.

The focus was one core flow: get set up, record a rehearsal, review it, gather feedback and rate your own confidence. That gave us something useful end to end without trying to solve every possible part of the experience at once.

We knew AI could add real value and the research supported that, but it also carried more feasibility risk. Rather than add AI simply because it was exciting, the product trio agreed to deprioritise it for the first release and focus on the parts we were confident we could ship well.

That meant leaning into the more human-centred feedback loop first. Users could share a rehearsal, gather comments from someone else, leave their own reflections and rate their confidence both immediately after recording and again after reviewing their performance.

Once that core experience was live and we had feedback from internal users and alpha testers, we continued working on the AI capability in the background. The decision was not “AI or no AI”. It was about sequencing the product so the first release delivered clear value while giving us more time to build the higher-risk AI experience properly.

We captured feedback in Productboard so we could see recurring themes, gather evidence over time and use it to help shape the backlog. Alongside that, I kept speaking to people who were actually using the product, both internally and externally.

Those conversations helped us uncover bugs, usability issues and areas of friction in the core rehearsal flow, so we could keep improving the experience rather than treating the first release as finished.

A lot of that iteration focused on strengthening the review experience. That included smaller interaction improvements, such as helping people jump back to the right moment from a comment, as well as broader fixes based on how people were actually using the product.

We also continued exploring ideas beyond the first release, including AI Q&A. Not everything moved into build straight away, but the research and feedback stayed useful as a backlog of validated opportunities we could return to when priorities allowed.

The main thing I took from the project was that discovery, delivery and iteration were never really separate phases. My role was to keep connecting them: helping the squad understand the problem, making ideas tangible enough to test, using evidence to shape decisions, working with Engineering on what was feasible and continuing to learn from the product once it was in people’s hands.