Organizations

Seamlessly bringing scientific associations’ events and data into one workspace, empowering Fourwaves to enter new markets and significantly reduce churn.

In a nutshell

Final Solution

How we got there

User Problems

Event organizers used our platform to create and manage their events, but despite being from the same association, there was no comprehensive structure to consolidate all the events, participants, and associated data. This led to a number of problems.

The main goal was to introduce & leverage the concept of Organizations to enable our clients to recreate the structure of their associations within the app, thus improving user communication, satisfaction and retention. This was also going to serve a robust foundation for the features we were planning to add later.

Siloed Events

This was problematic for large conferences, where event organizers changed from year to year.

Disconnected Users & Permissions

Members of an association had no way to connect outside specific event contexts.

Missing Data & Reports

The lack of aggregated data made it difficult for admins to get an overview of all their activities.

Business Problems

Internally, we also faced a number of issues preventing us from scaling gracefully :

"Unintentional" Churn

Some larger associations weren’t even aware of the platform used for previous editions of a recurring event.

Operational Fog

Internally, we lacked basic insights, making it difficult to build our roadmap, or to simply reach out and provide support.

Capped Growth

Our ability to meet the broader needs of our larger clients was significantly limited.

Objective

Introduce & leverage the concept of Organizations to enable our clients to recreate the structure of their associations within the app, thus improving user communication, satisfaction and retention.

Given how tiny a startup were, gathering solid metrics was a challenge. I still pushed for a definition of success, and after careful consideration, we decided to mesure improved stickiness by a combinaison of two factors we had clear data on : a churn reduction by at least 5% + an augmentation of referrals by at least 20%.

Preliminary Survey

We began by sending out a survey to gauge initial interest and recruit a few organizers for more detailed interviews. Additionally, we suggested the possibility of transitioning to a yearly subscription model.

Many event organizers felt responsible for selecting the platform for their events, covering the associated costs through registration fees. However, they believed it would be more efficient if their association managed this process at a higher level, and they were ready to advocate for this shift to their heads of association.

Interviews

I followed up a round of interviews with event organizers from 5 associations, all from very different backgrounds. I wanted to validate the current issues with the lack of a centralized hub, as well as the kind of insights that would be most beneficial if they had one. The following points stood out :

No "super admins" with full inherited rights meant lots of hacks to stay on top of things. Existing roles felt unbalanced, and came out as either overly permissive or too restrictive.

Organizers manually linked their Stripe account to   each event. This method led to frequent errors and raised security concerns, and it was critical that we address this for large associations.

Organizers noted that they relied heavily on emails for communicating about Fourwaves activities, resulting in frequent information loss.

Conceptualization

A few years ago, our CEO and CTO began developing an initial concept for an Organization, but the initiative was never fully realized. The core components, such as Events and Users, were already coded, allowing us to start testing quickly. I leveraged this foundation to outline the backbone of an Organization, which we then used to prioritize and refine our efforts.

Architecture & Navigation

I started ideating on information architecture, and we tested out this first iteration with a few users. We ended up reshuffling a lot of elements, and adding the bank account creation.

Roles & Permissions

From my experience at Poka, I knew that user roles and permissions could make or break a product. They require a delicate balance—neither too many nor too few—while ensuring they work together seamlessly.

As we added a new layer of admins at the organization level, we had to carefully consider how our legacy system would be managed, as well as the impact on pricing and availability as we transitioned to yearly subscription plans.

While many users appreciated the new permissions model, some found it too granular. Ultimately, we decided to keep things simple: alongside the new Super Admin role, we introduced the heavily requested Event Viewer role, which would ease the transition.

Legacy Management

The biggest challenge of this project was ensuring that the transition to Organizations were as seamless as possible. I split the process into 3 phases :

Introduction : along with the marketing, sales and CS teams, we would introduce the concept and prepare current clients to the change. We also had to think about how we would include the concept of Organization in the self-serve onboarding flow of our freemium without adding too much overhead.

Introduction : along with the marketing, sales and CS teams, we would introduce the concept and prepare current clients to the change.

Migration: we would strongly encourage the creation of Organizations by event organizers so that they can import their orphan events into it and invite their colleagues to join. Events could still be accessed from their usual location, from within the User Dashboard, as well as from the new Organization/Admin section.

Migration : we would strongly encourage the creation of Organizations by event organizers so that they can import their orphan events into it and invite their colleagues to join.

Full Rollout : all orphan legacy events would become unavailable, and event organization would be removed from the User Dashboard to take place only from within Organizations.

This also entailed managing user permissions with good defaults. The question was : who could actually create an organization, and what would happen to other organizers, program chairs, etc.?

This also entailed managing user permissions with good defaults, and define who could actually create an organization, and what would happen to other organizers, program chairs, etc.?

Triggers & Entry points

We also gave a lot of thought on all entry points to the creation of an organization, as well as all actions related to an event. For instance, it was possible for an organizer to clone an event. With the rollout of Organizations, should we allow the duplication of an orphan event, thus creating more orphans? Should we disable the feature for those events, or transform it into a new trigger for organization creation? We decided on the later since it helped the user achieve our desired outcome, and led to less confusion.

I also recommended that we prevented event creation for users that didn't belong to any organizations. We used the same principle as for clones : it triggered the introductory splash screen to Organizations to encourage creation.

And lastly, we included a dismissible banner on the home page (User Dashboard) to explain the upcoming changes and inform users that eventually, orphan events would be made inaccessible.

Navigation & Organizations Access Points

The challenge here was to clearly differentiate between the needs of various personas. The User Dashboard needed to remain the primary entry point for participants, who made up over 90% of our user base. However, since participants could eventually become event organizers, we also needed to provide a clear and intuitive path for them to transition into an admin role.

Mobile Considerations

We never intended to develop native mobile apps, but we consistently prioritized full responsiveness across all sections. Since Organizers often needed to refer to their events while they were happening, we made sure that even data-heavy sections were minimally usable on mobile devices.

Final Thoughts

In the end, a few components were left out. We focused on building the true backbone of an organization, which consisted in Events, Admins and ultimately, we also prioritized Bank Accounts. We decided to work on a participants/members list on a future iteration.

We also decided that we needed more research done on the Data & Reporting section, but we decided to include a placeholder in the menu, to spark interest and conversations, and build anticipation and excitement around the topic.

In parallel, we were also holding a conversation about having a better self-serve motion on purchases. We were considering moving from an event-based pricing model to and organization-based yearly subscription, so we decided to include a placeholder for that future section as well.

Takeaways

The project has been completed and released with a few clients in Beta mode, a last-minute decision made by our CTO and CEO.

This project took quite some time, and given that we were just one team juggling a few smaller projects along the way, it felt a bit inevitable. Afterward, I thought about whether we could have phased it differently to embrace a more iterative approach, but considering the context, the size of the team, and the breaking changes we were making to our codebase, I think we did quite well.

It's still too early after release for numbers, but initial feedback from our CSMs indicates that the new feature has greatly simplified onboarding and follow-up, made it easier to reach the right users in a timely manner, and shows great potential for scaling up some accounts.

Back to all projects

In a nutshell

How we got there