ZoneJam is a product we built internally at Hivekind. We built it to address a need in the market: the lack of a simple tool to suggest meeting times for groups of people spread across time zones.
We kicked off development of ZoneJam by rapidly validating our assumptions about the market opportunity: an exercise we call Product Discovery. Once we had a reasonable indication from the market and our first Figma prototype (both produced by the exercise), we moved on to building ZoneJam’s first version, scoped as a Minimum Viable Product (MVP). With our MVP in hand, we brought ZoneJam to market through a planned and coordinated product launch.
Initial idea: Simple tool to help scheduling across time zones
Frustrations around schedule coordination had existed within Hivekind for some time. Since we are a remote-first agency that works with clients in different time zones, Hivekinders regularly find themselves scheduling calls that must accommodate attendees in several different locations worldwide. The process for doing this was cumbersome. We tended to stitch together the use of multiple tools, taking the best bits from each and working around their limitations.
We captured this sentiment as the following summary, written to inspire the possible development of a Hivekind-built product:
With this initial idea in mind, we asked one of our dedicated software teams to pursue making it a reality.
Product discovery: Validating assumptions about the opportunity
When you have an idea for a product, it’s easy to convince yourself that you’re onto a winner. But all too often some element of your plan will be off. One false assumption can be enough to cause your product to fail, and the sooner you learn this the better. Discovering such a thing early might help you pivot towards a winning plan while you still can, whereas learning it late might end up being an expensive mistake that you cannot recover from.
We started development of ZoneJam by conducting a Product Discovery. A Product Discovery helps us test our assumptions. It provides the information necessary to decide whether to pursue building the product for real. In this case, it helped us understand how our new product might perform in the market before we actually built it.
The process we followed when carrying out our Product Discovery was:
- Learn and understand. In which we sought to understand the situations, pain points and needs of our customers.
- Define and decide. We defined the problem we're trying to solve and chose an ambitious but manageable piece of the problem to target.
- Ideate and prioritize. We brainstormed and sketched out a number of possible solutions, then prioritized a set of features to build.
- Prototype and test. We built a realistic prototype and tested it with target users.
Learn and understand
Given that ZoneJam was born out of Hivekind’s own experiences, we used internal user interviewing as a natural starting point for our research. We used scenario-based questions to delve into the application’s utility, intuitiveness, and overall user experience. To further enhance our understanding, we expanded user interviewing externally, conducting interviews with global testers from Germany, India, and the United States. This diversity offered a broader range of perspectives, encompassing varying cultural contexts and usage habits. We talked to users about the various tools they currently use and the problems they encounter with these tools. Our primary objective was to gain insights into customers' situations, needs, and pain points when it comes to scheduling meetings across time zones.
Define and decide
From the Learn and Understand step, we learned that our target users wanted:
- A solution that worked well on mobile.
- To be able to save their contacts’ details, for convenient repeated use of the product.
- To select multiple time slots then share their selection with meeting attendees.
We defined the problem we intended to solve as follows:
Remote teams struggle with scheduling meetings across multiple time zones, due to the lack of effective tools that provide simple and intuitive interfaces for finding and suggesting suitable meeting times for all participants. In particular, there is a lack of tools that work well in both a mobile and desktop setting, that can be personalized without sign-up, and make it easy to select multiple time-slots.
Ideate and prioritize
With a solid grasp of the problem in hand, we moved on to considering several possible solutions.
To achieve this, we began by examining existing solutions. WorldTimeBuddy.com, for instance, offered a horizontal timeline. However, this design didn’t translate well to mobile devices, which are predominantly used for vertical scrolling. TimeAndDate.com, on the other hand, presented a vertical timetable, but the leftmost column displayed UTC time and date, which often wasn’t relevant to users when deciding on a meeting slot. This took up valuable space on the left side of the table, offering minimal value to users. However, we liked how TimeAndDate.com displayed the hours with a traffic light color scheme, indicating the most common available hours to unavailable hours, as it is easy for users to have a quick glance and determine which slot works for everyone across the row of the table.
We tried a number of different timeline layouts, each inspired by our own ideas and the best parts of similar tools already in the market.
Once we had a number of possible solutions sketched out, we chose the one that we felt would be best suited to solving the problem.
We went with a vertical timeline, that provided a clear visual representation of availability across all meeting attendee. We utilized color codes to indicate the status of each time slot - green for convenient (within typical office hours), yellow for caution (in the early morning or evening), and red (likely when the person would be sleeping). Our assumption was that this traffic light system would allow users to quickly glance at the timetable and immediately identify the time slots that are most likely to work for everyone.
We also decided to include a “profiles” feature. This would allow the user to save details of meeting attendees in user profiles in the app. The assumption around this feature was that users who regularly schedule meetings would be able to find the people who they regularly schedule with, rather than have to enter all their details every time.
Prototype and test
We built a high fidelity prototype of the product in Figma.
We then used the prototype to conduct user testing. We performed this user testing by asking candidate users to use the prototype to solve several pre-defined tasks. We recorded how well they were able to complete these tasks. Generally speaking, we were looking for convenient and enjoyable completion as an indication that our prototype was performing well, and users getting stuck or becoming frustrated as an indication that something was wrong.
We sourced users in several ways:
- We asked Hivekinders unfamiliar with the project to participate.
- We asked coffee drinkers at a local coffee shop (filled with professionals grabbing their daily caffeine fix) for a few minutes of their time.
- We sourced external tested using an online user testing service.
We went through a few iterations of testing at this step, refining our prototype each time until we found a strong indication that our product was useful to participants.
At this point, we had reached the end of our Product Discovery. We had positive indication from target users that we had a viable solution, and a prototype ready to be turned into a real product. We decided to implement and moved onto building an MVP.
Minimum viable product: the first version
With our prototype in hand, building the application began. Given the scope of the MVP and other priorities competing for our attention, we gave ourselves a three month window in which to complete the first version and launch.
We followed an iterative development approach and used Scrum to manage our team. Our sprints were two weeks in duration, which gave us about six sprints to complete the launch.
The first tactic we applied to achieve this was to focus on implementing core user flows, using a ready-to-go component library to do so. This allowed us to get the product to a working state quickly, without having to worry about component implementation. We chose Material UI as our component library, as it supports a wide range of features and is backed by a large community of users and contributors.
Our first sprint saw us start work on user flows right away, without much focus on implementing the hi-fi look and feel present in the prototype. As time progressed, we incorporated more and more UI component work into our sprints, essentially fleshing out the intended experience as we neared the end of our time window.
We quickly had a working (albeit ugly) version of the product ready. We dogfooded this early version internally at Hivekind, having our development teams use it to find suitable times to meet with each other and with our clients. This provided a nice way for us to get early user feedback, providing immediate insights into the product’s usability and efficacy within a live operational context.
Concurrent design and development cycles
The insights gained from early internal dogfooding were used to further refine our design, even though implementation. We adopted a methodology of concurrent design and development sprints to facilitate a rapid feedback loop during all user testing phases. Just because implementation has begun doesn’t mean you cannot continue to learn and improve your plan.
Serverless architecture approach
A business concern had come up during the Product Discovery. It was around operating cost. We intended ZoneJam to be free to users and ad free. This meant it had no monetization strategy. Indeed, the value it would bring to us would be to make people aware of our company. If ZoneJam’s adoption took off, would we be stuck with a large hosting bill, the cost of which we wouldn’t be able to afford or justify?
To get around this problem, we decided to make hosting ZoneJam as cost effective as possible. We decided to implement it with a serverless architecture, and to place as much of the application in client-side, frontend code.
By making ZoneJam an almost exclusively frontend app, we could leverage CDN distribution to deliver the app to users at low cost, even at high scale. What little server-side functionality that was need was executed in stateless compute containers. These containers are event-triggered, ephemeral, and fully managed by a third party. This approach led to very low operational costs, and also reduced the amount of maintenance the app needed.
Time zone modeling challenge
A significant challenge that came up was the incorporation of time zones into the application. This was a critical aspect of the project, as the primary aim of ZoneJam was to simplify scheduling across various time zones for remote teams. The complexity of this task was compounded by the fact that time zones are not static; they can change due to factors such as daylight saving and changes in local laws.
To address this challenge, we conducted research and discovered Time Zone Database, an industry-standard open-source library maintained by the Internet Assigned Numbers Authority (IANA). Time Zone Database provides comprehensive time zone data and is regularly updated to reflect changes in time zone rules around the world. By using this we’d ensure that ZoneJam would always provide accurate scheduling information, and would also allow the team to focus on building the core features of ZoneJam without getting bogged down in the intricacies of global time zone management.
Team communication during the implementation phase
As a remote team working with other remote teams, we placed importance on effective written communication. A central document served as the main source of project information, encompassing:
- A board of all materials created during design sprints.
- A project roadmap, product backlog, sprint roadmap, and sprint board.
- Our chosen communication methods: a dedicated Slack channel for all stakeholders.
- Links to all other relevant documents.
The documents and communication channels were continuously updated, ensuring that anyone with a question could refer to them for comprehensive, up-to-date information. We prioritized complete transparency in our interactions with everyone involved.
With particular attention placed on good planning, we were able to complete our MVP scope within our six-sprint timeframe. We now had our first version and were ready to take it to market through a product launch.
Launch and impact: Taking ZoneJam to market
To launch ZoneJam, we collaborated with Hivekind’s Marketing team.
First, we created a homepage for the product. This landing page explained ZoneJam’s benefits and how to use it. It also contained content optimized for search engines, allowing ZoneJam to be picked up by Google and other providers.
Next, we planned a big-bang launch on Product Hunt. We used our knowledge of the platform to gain traction during the 24-hour period after we posted there. We were able to get listed as the 11th most popular product that day, generating hundreds of visitors during that time.
With a working product created and launched, this is where we left our development of ZoneJam. The launch itself helped us gain further feedback from users and inspired us to create a backlog of work that we may choose to pursue in the future.
We continue to use ZoneJam internally at Hivekind to find times for people spread across multiple time zones to meet. Perhaps you might find it useful for your scheduling needs too.
