2023 Research Summary + Proposed Initiatives

1. Context

 

⚙

Scheduling is a means to an end. What people want is the end result - the meeting. Anything in between is just friction. - somewhere from mww notion

Background

Web3 communities are inherently decentralized. Because of this, the scheduling needs differ from the typical centralized, corporate environment most people are familiar with.

Individuals in Web3 communities may include (but not limited to):

• Cross-org worker

• Solopreneur

For this feature, we’ll focus on Cross-org workers.

(See all personas here.)

 

Problem Statement (Assumptions)

The unique environment of Web3 creates more hurdles to collaborate in 3 ways:

 

1. No single, synchronized calendar for teams
Many Web3 individuals are involved in multiple organizations concurrently, each with their own domains and communication platforms. This makes scheduling meetings with accurate availability across various organizations cumbersome and manual.

2. Dynamic availability without core hours
With multiple commitments, the weekly availability of individuals changes often. With various levels of commitments, there are no standard 9-5 or core hours, nor a designated period where one can expect responses from each other when scheduling.

3. Delayed responses due to inherent asynchronicity
Remote collaboration with individuals in various time zones often involves asynchronous collaboration. Direct responses quickly become prolonged back-and-forths and potential delays in decision-making. Additionally, manual timezone calculations often result in errors and frustration.

 

A 2024 Bet

MeetWithWallet aims to resolve these pain points and elevate the collaboration experience for our target users. So far, we have released the following features:

• 1:1 meeting (shared calendar link)

• One-off meetings (From dashboard)

• One-off meetings (Discord bot)

These features established an essential foundation to provide basic scheduling needs, and are critical in building more advanced and complex features.

 

In 2024, we are making a big bet to elevate our product’s scheduling ability in a group setting.

Why?

Group meeting (3 or more) is the most used setting when collaborating, but has the most friction because it requires every attendee’s availability to align.

if our bet is right, we may see a large increase in adoption and growth.

2. Research

Selected methods

To validate our assumptions, we conducted research using 2 methods.

1. Competitor analysis
Takeaways

2. User interviews

User interviews

🔑

Research objective: To understand and identify specific pain points people in Web3 encounter when scheduling meetings with others.

Interview 1: Daniel Ospina (RnDAO & TogetherCrew)

Interview 2: TBD

 

Highlighted insights

The first column lists consolidated pain points we identified through current & prior research.

The second column lists the insights extracted from the pain points.

Pain Point	Insight
Awaiting and chasing participants for responses	No visibility into others’ availability
Unable to auto-add all available slots with one click (have to manually select each one)	Redundant/repetitive work
When a new meeting is scheduled, calendar availability doesn’t become unavailable	Shared availability unreliable
No calendar groups for established teams and trusted members, which requires organizers to repeatedly add same participants when scheduling	Redundant/repetitive work
Participants’ calendars not up-to-date, creating conflicts and double-booking situations	Shared availability unreliable
Only 1 calendar integration; not enough to capture all scheduled events across all platforms	No visibility into others’ availability
Difficulty reaching non-discord users (cross platforms)	No visibility into others’ availability
Lack of recurring meeting option	Redundant/repetitive work

See all the compiled pain points here.

 

Synthesized insights

Pain points are synthesized into 3 key insights:

 

1. Little or no visibility
Organizers have little or no visibility into participants’ availability, which creates unnecessary waiting time or added effort to chase people down for responses.

2. Shared availability unreliable
Even when availabilities are provided, they could be inaccurate or unreliable (e.g. unavailable time shows as available), resulting in conflicts, no-shows, and wasted time.

3. Repetitive work & back-and-forths
Organizers face repetitive work when scheduling group meetings (e.g. manually inputting each participant’s contact, filling out all empty times, etc). This introduces additional barriers and friction to collaboration.

 

Opportunity statements

All insights allude to one thing - control.

📌

It’s more challenging to schedule meetings in Web3 because there is less control. So we want to provide more control to organizers:

 

1. Provide more visibility
We want to provide more visibility into others’ availability for the organizers when they schedule. The more they see, the more confident organizers are, making the task of scheduling meetings more efficient.
 

2. Minimize back-and-forths
Because there is likely limited visibility into others’ availability, we want to minimize back and forth when they schedule.bThe less time they spend on aligning, the quicker and easier it is for them to meet.

 

Both are about providing more control to the organizers, either it’s having more visibility or spending less time.

 

 

3. Proposed initiatives

The proposed initiatives are meant to outline the general direction only. The features listed are meant to give us rough ideas on what we can build.

 

Initiative 1. Team management

This initiative aims to provide more control for organizers by giving more visibility into the availability of participants.

 

Proposed features (but not limited to):

• Create team(s) - can add members to a team with minimum contact info/identifier.
the contact info shouldn’t be added by the user creating the team but instead, it’s in the invitees’ master account and disclosed when invitees accept the invite (for now we keep this super basic but here’s where the TogetherCrew identity module can come in)

• Assign Admin(s) - admins can manage teams, and view the availabilities of all members (based on their connected calendars/set availability).

• Fetch availability - organizers can fetch the availabilities of their team members through their connected calendars to know a time that fits well for all.

• Select/deselect members from a team.

 

🪴

Summary. This initiative emphasizes an experience that requires initial effort from organizers, similar to conventional contact management features, but the focus is on empowering organizers with enhanced visibility so they can confidently schedule calls with participants from various organizations simultaneously.

 

Initiative 2. Send pre-selected availability

This initiative aims to provide more control for organizers in a low-trust environment by minimizing back and forth when scheduling meetings.

 

Proposed features (but not limited to):

• Create a meeting poll with pre-selected availability.

• Participants can select multiple times based on given time slots.
participant time slots (including organizer’s) are autofilled if they have a connected calendars
if no connected calendar, nudge participants to connect calendar

• Time zone adjustment for both organizers and participants.

• Various ways to send/publish meeting poll.

• Various ways to conclude/schedule a meeting based on results (based on x number of results, countdown clock, auto-schedule, etc).

 

🪴

Summary. This initiative prioritizes an experience where organizers, rather than attempting to confirm everyone's availability, choose their own available times and send them to participants for a single-round response. This approach minimizes back-and-forth interactions to a single exchange.

 

4. Next steps

From here, we can start ideating on the design. I propose we do it in a design workshop setting, and all core contributors should participate in this. 2 deliverables that could help us advance during the workshop would be:

Journey mapping

1. For both initiatives, we can map out a simple user journey with a given persona and scenario (e.g. cross-org worker trying to schedule 2 meetings with 2 organizations).

2. From this, we can identify MVP features we should build for the initiative to be viable, and what features can be put on backlog.

 

MVP Wireframing

1. With the given context, we can start wireframing out the flows (and screens) required for each initiative.

2. From here, we can start reviewing and iterating on what features to include or not for MVP.

3. Simultaneously, we can better understand any technical constraints, times, and phases of these developments, etc.

4. We can start creating simple prototypes and get them tested.