Overview
Go Between is a small team of software engineers and product designers. At our core, we're builders, not marketers. This is why we originally built Marginal. We thought it would be cool to build something that encouraged remote teams to form better relationships with their coworkers through weekly discussions, so that's what we did. We knew finding customers would be hard, but sometimes you have to experience the pain yourself in order to truly understand it. And so, despite having what we believed to be a strong value proposition, increasing awareness and onboarding new customers proved extremely difficult. Shocking, right?
However, before laying Marginal to rest in the product graveyard, we've decided to explore what Marginal might look like as a Slack application. Slack is intriguing for two primary reasons. First, it comes with built-in distribution via the Slack Marketplace. As we've mentioned countless times, we're not marketers, and getting your product out there takes a lot of time and energy that we don't have. So our hope is that we can use the Slack Marketplace to get a few more eyeballs on Marginal. Secondly, Slack provides a more seamless onboarding experience than the web-based version we have today. Instead of forcing users to do things like create a new account, learn a new interface, or remember to visit yet another website, we can meet potential customers where they are with a simple slash command.
We don't plan on reducing consulting hours to support this project, so our appetite will be time-boxed to a single 6-week product cycle, with each of us contributing around 3-5 hours per week.
System Design
Before we get into the features we plan to support, let's quickly review the technical design for this application. Since we'll only have a few hours each week to work on this, we need a system that lets us move fast while also taking advantage of the functionality already developed in the Marginal web app. To balance these competing objectives, we'll use the Slack Ruby toolkit to stand up a new backend service, connecting to a database shared with the Marignal web app. The Slack Ruby toolkit will significantly speed up our development, avoiding the need for us to setup a lot of foundational Slack integration boilerplate. While using a shared underlying database maintains consistency in the content presented through either interface.
Onboarding
Users can add Marginal to Slack from the Slack Marketplace or by clicking a link on the Marginal website. Doing so will trigger a Slack authorization form that users must "Allow" in order to use the application. Clicking cancel will direct the user to the Marginal homepage for now.
When users click "Allow," Marginal will receive a verification code and use that to request an access token from Slack, which is stored in the Marginal database. The user is presented an OAuth completion message and a set of onboarding instructions in Slack.
Creating Sessions
Sessions represent the series of discussions between you and your team. It's a foundational object that manages things like the recurring day and time for the team's weekly discussions, the people participating in upcoming discussions, and topics being discussed.
A new Session is automatically created when the Marginal bot is added to a Slack channel. To support this, we’ll use Slack’s member_joined_channel
event to perform the following actions:
- Create a new Session in the shared Marginal database.
- Add Session participants by retrieving Slack members from the channel and creating session participant records for each user in the Marginal database.
- Post a “welcome” message to the channel with a prompt to schedule the first discussion.
Tightly coupling a Session to a Slack channel helps keep your weekly conversations organized and in a central place.
Scheduling Sessions
Users can select a day of the week and a time from the new session prompt. Once selected, we'll record the Session details in the database and prompt users in Slack to select a topic for their first discussion.
Picking Session Topics
Session topics represent the thing you and your team will discuss each week. When onboarding for the first time, users will have an option to select a topic from Marginal's existing library, or they can create a custom topic.
If users choose to create a custom topic, they will be presented with a modal asking for the following details:
Once completed, this information will be recorded in the database and your team will be ready for its first discussion. If a custom topic is selected, someone will need to create a new topic for the following week. This will be supported through a Slack command (e.g. /marginal add new discussion topic
) that users can type to open the custom topic modal.
If users don't want to do this each week, they can select a topic from Marginal's library, which contains a curated selection of weekly topics.
Adding Discussion Topics
Now that we have a Session, with a series of recurring discussions and some interesting topics to talk about, users need to start preparing. More specifically, they'll need to review the topic for the next discussion and add things they'd like to talk about with their coworkers.
Users can add comments and questions to a discussion using a slash command—something like /marginal add discussion topic
. As users add "talking points" to the next discussion, the Marginal bot will respond with an ephemeral message confirming that it was captured. If users wish to edit these talking points, they can do so using the web app.
Facilitating Discussions
The Marginal Slack bot will post a message in the channel announcing the start of a discussion. Additionally, Marginal will post a second message in the thread of the original announcement prompting someone to start a huddle or share a video link—since Slack doesn't provide an API for triggering huddles. As a reminder, everyone in the channel can add topics and join discussions.
Marginal will randomly select someone to kick off the discussion by sending an ephemeral message to the presenter with a list of their available topics. When a user selects a topic to present, the Marginal Bot will post a message to the discussion thread for everyone to see. While this is happening, non-presenting users will see a message letting them know the presenter is still choosing a topic. Once the presenter has finished discussing their topic, they can mark it complete, and the process should repeat for the next user in the discussion.
Out of Scope
- Programmatically launching Huddles: Automatically starting a huddle in the channel when a new discussion is about to begin would provide a pretty seamless experience. However, Slack does not have a Huddles API to support that.
- Automatic discussion topic prompts: If users create a custom discussion topic, they'll need to manually keep adding new ones each week. Automatically prompting users to add a new topic would be nice, but it's out of scope for this cycle.
- Discussion Reminders: To start, we only plan on notifying users the exact moment a discussion is scheduled to start. However, in future iterations, it would be nice to include some reminders much earlier.
- Public launch: Eventually, we'd like to launch the Marginal Slack app publicly. This would include things like making it available in the Slack marketplace (not just for us) and marketing the app on sites like Product Hunt. However, that's more than we can bite off in 6 weeks, so it will have to wait for another cycle.
- Website updates: Somewhat related, we'll eventually want to update the Marginal website with new content detailing how the Slack version works. However, that is out of scope for this cycle.
Risks and Rabbit Holes
Given the limited amount of time we've budgeted to work on this, it's important to highlight some of the risks and potential rabbit holes that we discovered during the discovery phase. Doing so helps keep us focused on the core functionality outlined in this pitch.
- Incorporating the Marginal web app data models into the Slack events service was a pretty tedious process and painful part of the discovery process. We had to fight between two different paradigms (Rails vs. the Slack Ruby Bot Server paradigm), and coordinating those two frameworks was challenging. Thankfully, most of this has been de-risked in discovery by using Rails' built-in configuration options to disable any functionality that we don't need. However, this is something to keep an eye on as we continue building out the Marginal Slack application.
- Understanding Slack patterns and API interactions. The Slack documentation is great, but there is a pretty steep learning curve with tons of functionality. We'll need to make sure we don't get too caught up in the flood of information.
- Based on some of the discovery we've done for this already, it looks like the Slack Ruby Bot Server framework we're using does not support handling modal submission events. Assuming we still want to use this framework, we may need to add support for this by contributing back to the open source project.
- Accidentally breaking the Marginal web experience. Obviously we will try not to do that, but it's technically possible.
Appendix
Helpful Slack resources and documentation for this project can be found below:
- Block Kit Builder (for testing/prototyping Block Kit UIs)
- Block Action Reference Docs
- Modals Documentation
- Slash Commands Documentation
- Web API Reference Docs
- Events Reference Docs
- Ephemeral (i.e. private to one user) Message Docs
- Message Threads Docs
- Slack Ruby Bot Server Internal API Request Handling Source. This is helpful when trying to figure out how a request/callback referenced in the Slack app docs translates into a component within the Slack Ruby Bot Server being invoked.
- Slack Ruby Client Web API Supported Operations Source. This is helpful when trying to figure out how to call a specific Slack Web API endpoint through the Ruby client.
Closing Thoughts
Reimagining Marginal as a Slack application represents an exciting opportunity for our team to breathe new life into a product we believe in. By leveraging Slack's built-in distribution and seamless user experience, we aim to overcome some of the biggest challenges we faced with Marginal's web-based version. Throughout this pitch, we've outlined the core features, system design, and our approach to executing this project within a tight time frame.
As we move forward, we'll share updates on our progress, lessons learned, and any unexpected twists along the way. If you have any questions, feedback, or ideas to share, we’d love to hear from you. Feel free to reach out or drop a comment. Building in the open is core to our values, and we welcome your input as we take Marginal into its next chapter. Stay tuned!