Building product process for an event platform

Nura Events is an event management platform, a purpose-built app for a single venue's events, guests and community, on web, iOS and Android. I joined as the sole Product Manager, reporting to direct management, with no product process in place. The product was at stage 0: some backend built, base frontend architecture in place, design mostly ready but with significant gaps.

The goal was an end-to-end event experience for a boutique community: invitation flows, guest list management by role, and payments. I ran the engagement from January to July 2026.

Challenge

The core challenge was operational. A cross-functional freelance team was delivering across three platforms in four time zones with no unified process: no ticket standards, no handoff structure, no QA documentation, no consistent reporting upward. Coordinating without direct authority or shared working hours meant every process had to be async-first and unambiguous by design.

I also never had direct access to users. It was a private community and member contact sat outside my remit, so what reached me arrived second-hand and too vague to act on. Every scope argument I made had to rest on the structure of the flow rather than on evidence from the people using it.

On top of that I was asked to scope and deliver a net-new fundraiser sub-product. Its payment architecture had two distinct flows: guests contributing to an external fundraising organisation, and hosts paying Nura directly for the venue. Each needed separate routing, with Nura never acting as a financial intermediary on the org side. That is a compliance question before it is an engineering one.

What I did

I built the PM process from scratch. A ticket pipeline of Deploy → Staging → QA → Done across all three platforms, async developer handoffs I owned end to end, and a structured weekly report upward. I authored the end-to-end Product Requirements Document and a PRD for each feature that followed, owned the roadmap and the backlog in Linear, and allocated the work across the team: what was built now, what was deferred, and who held it. I did acceptance QA myself against the criteria I had written, which is the first thing to slip when nobody shares a working hour.

I built the UX flows and designed the screens, high fidelity in Figma, so what reached a developer was a picture of the result rather than a description of one.

I defined the role-permission logic. Hosts, co-hosts and guests each operating under distinct rules, and I resolved the flow conflicts that surfaced in invitation routing between them.

I held the bar on scope. I pushed back, repeatedly, on feature requests that would have compromised the clarity of the core flow, arguing for user testing before committing dev resource to unvalidated assumptions. The bar I held was directive UX over feature breadth: guide someone to the correct next action rather than give them more to choose from.

I scoped the fundraiser sub-product end to end, including the dual payment routing, and designed its high-fidelity screens in Figma. The routing was specified before any of it was built.

Outcome

The app launched live with real community members. Reservations, guest lists and payments ran end to end, replacing a fully manual offline process with the first digital system for the venue, and the platform processed $60K+ in transactions within the first live event. Real money, real events, not a pilot.

Learning and reflection

Payment architecture is a product decision. Who holds money, when, and why determines compliance exposure. That belongs in the PRD, not left to whoever picks up the ticket.

Presenting options is not the same as making decisions. Working directly with a founding team taught me my job is to map the landscape clearly. They own the conclusion.

Arguing for research I was never able to run. I pushed for user testing and never had contact with a single member of the community. It made me better at reasoning from the structure of a flow, and it is still the first thing I would change: a decision defended on structure alone is a decision waiting for data to overturn it.

Process design is how you lead without authority. A distributed freelance team stays aligned only if every artifact is unambiguous enough to be worked from without real-time clarification. The specification was the product management.