How Postlight Built — Then Rebuilt — Dash

Postlight just released a new app, Dash for Slack. Dash gives teams an easy way to start a new Slack channel for a specific topic or conversation, set a deadline, and then archive the channel and share the outcome of the discussion when time’s up. Add Dash to your Slack workspace now–and read on to learn how Dash came to be.

When the cofounder of your company sends you a Slack message that reads, “Do you have a few minutes?”, you have to answer yes. In my many years of working with Rich Ziade, president of Postlight, I know a message like that means there’s something a bit wild (but worth listening to) ahead of me.

This time, we talked about how we work at Postlight, specifically how often Rich needs to grab a few people across various teams to get them to focus on a goal — quickly. It’s part of how we emphasize shipping. It makes sense; when you have a lot of smart people in the room, decisions naturally come together with a lot of back and forth and asynchronous chiming in as well. Because our team is distributed, we often rely on Slack for these conversations.

My brain searches for patterns, to understand how people are already using a tool — often to the point of breaking it — and codifying those cowpaths. For years, Postlight used Flowdock as our company chat app, because the team strongly preferred threaded conversations. We switched to Slack only after it introduced threads.

For years, I’ve observed our teams naturally gravitating to cordoning off deep conversations into threads. Hey team, we really needed to figure out how to solve this problem with the API, and we’re gonna do it over there → and there begins a thread of 50+ replies with multiple people going back and forth. These conversations weren’t happening in the project channel itself but in threads — or worse, starting in chat, breaking off into multiple threads, and ending with someone pleading: Can we just have a meeting?

Why was this happening? Isn’t Slack, as their marketing says, where work happens?

The problem with chat

When you look at how Slack and any IRC-esque application works, the problem is clear. The focus of chat is specific to the shared viewport of the entire room. Anything that makes the user scroll back into an unspecified time frame might as well be lost forever.

Sure, there are the completionists who go back and catch up on what happened in any given room to make sure they didn’t miss out on anything every time. But the majority of people are trying to figure out What are we doing now? and What do I need to think about today?. For that, a reverse-chronological stream of messages by (let’s be honest) too many people talking about too many things is one of the worst ways to get oriented.

Back when we were creating the marketing message for our first Slack app, SOTU, our CEO Paul Ford compared trying to drop into a Slack channel to see what’s going on to listening to an all-day, agenda-less conference call backwards. He’s not wrong!

Awhile back, Jeremy Mack and I had a conversation with Matt Haughey from Slack, who asked about how a remote-friendly company like Postlight uses Slack. A lot of the conversation centered around what Slack is good for and what it’s bad for. We talked about the /giphy integration and specifically about how Postlight had gradually began to use fewer reaction GIFs over time—an ironic phenomenon for a team that built a chat app called GIF Battle and prided itself on our meme reaction game.

The problem isn’t GIFs as a format but how they appear: GIFs are too tall. Slack is primarily text-based communication between multiple people creating lines of text in a window that rarely exceed 700 pixels. The real estate that a jokey meme GIF requires pushes people’s well thought-out prose out of view, and that feels, for lack of a better word, rude. Humans can really only process what’s in front of them, and the bounding box of the chat window viewport is a logical cut-off point. It’s why headhunters tell you to keep your résumé to one page and why designers tell you to keep the most important calls to action above the fold: The brain doesn’t like to scroll.

So why use Slack?

This isn’t to say that Slack is bad or incompatible with work. Far from it! Slack is the lifeblood of our communication at Postlight. It allows our internationally distributed team to come together over both work and water cooler conversations. But it functions best when you use it well, and Postlight’s usage patterns tell the story. We’re quick to create a thread to work out an issue, and that’s why I was really intrigued by a new challenge of improving that workflow. In most offices, you end up saying. “We need a meeting” and then play the game of calendar Tetris to find the right people available at the same time to talk about an issue in in-person. As a remote-focused team, we created similar patterns using Slack threads.

So the conversation Rich sparked immediately went to Postlight Labs. How do we create a full specification in short order to gather consensus on a new product? Jeremy and I booked a room, dragged in our trusty Jamboard and drew out the full lifecycle of the app of our dreams. We called it Project Huddle — as in sometimes you need to huddle up the team, then break and go do the work.

The flow came together quickly because it mapped to something we do already: When folks need to tackle a tough problem, they’ll give a brief question or topic and usually tack on a ? thread emoji to let people know. These threads take different shapes. Sometimes it’s a deep technical discussion between a few developers where they need to post code snippets back and forth; other times it’s a designer posting screens for feedback and posting quick iterations and assets; sometimes it’s just people wanting to talk about the latest episode of a TV show with appropriate spoiler warnings. It’s a polite and transparent way of letting everyone in a channel know: We’re gonna sidebar over there and we’re welcome to join us if you’d like.

So that’s where our heads were while we were building Project Huddle’s first version. Threads were a critical part of how Postlight communicated both in Slack and Flowdock, so why not keep concurrent and contextual conversations tied-together loosely through metadata? Trying to have two conversation topics in Slack channels happening at the same time is near impossible, and threads were how we were solving that problem.

We knew we needed to validate Huddle, so the immediate goal was to have Postlight dogfood it. We demoed it to product managers and talked the use cases we felt like made the most sense for Huddle, mostly oriented around needing to keep a channel abreast of a timely conversation but not take it over completely. With Huddle, you could start a thread, invite folks to it, let them manage it in a makeshift dashboard and then report back when that thread was resolved to the parent channel.

We felt great about the concept, and our teammates were using it and had positive feedback. But it became clear after a couple weeks: Huddle was dead on arrival.

What went wrong?

Part of why Huddle’s initial version didn’t work boiled down to the limitations of building in someone else’s sandbox. We had gone all in on using Slack’s Block Kit, which was brand new and support for it in threads was spotty. Some of this is was because Block Kit is new — we submitted quite a few bug reports and feature requests — but the bigger issue was threads in Slack have always felt and behaved liked a bolt-on feature. They’re hard to track if you have more than a few of them, and it’s easy to break a channel discussion into several discordant threads without even trying. You also can’t use non-Slack slash commands in them, making integrating with third party integrations (including Huddle itself) impossible. Even with our dashboard, Huddle threads were hard to find and remember what the point of any given thread was.

But the biggest reason why Huddle wasn’t as useful was threads themselves. Huddles could only exist in the context of another channel. Threads, and thus Huddles, are children of parent channels and could only include the people who are already in the channel. Adding new people, especially for private channels, was a huge hill to climb both conceptually and programmatically. A thread is really just an offshoot of a channel. What we needed was the Goldilocks solution: Something meatier and more pressing than a thread but more manageable and less permanent than a channel.

There’s another pattern of work that takes hold to solve this, one that is harder to see and model against: The DM group. As an admin, I get the weekly analytics reports from Slack about how the team is using our workspace, so I can see that a majority of the conversations in our Slack workspace happen in DMs.

But in practice, group DMs are a mess. You can’t add people to them after the conversation starts, you can’t share the conversation publicly if you need to and the names are all but indistinguishable in Slack’s sidebar. I’ve been guilty of messaging the wrong DM group because I couldn’t distinguish one from the other easily, much to my own embarrassment.

How did we end up here?

Our initial concept for Huddle was focused on solving just part of the issue: How do you make decisions more visible and motivate teams to make them against deadlines? But it didn’t address the bigger picture: How do you bring the right team together for every type of decision? Huddle worked for a specific kind of decision, but we needed to be aiming at a different vector. Many discussions, both on Slack and in meetings with people like Phil Johnson and Adam Pash who joined the project later in the process, caused us all to rethink if we were hitting our goals. Since we weren’t, we needed to have a tough conversation about what to do about that.

I had been against making a Slack app that created channels at the beginning because I really felt like most Slack workspaces suffer from a channel glut. But the advantage of Slack’s interface is channels–particularly active ones–are highly visible, something our Huddle dashboard of threads couldn’t be. By prepending the name of a channel with a special character — the dash that we ended up naming the product after — we gave users a low tech hack-y way of self-organizing channels.

Much like how Huddle threads were meant to be regarded as important but temporary, a newly-minted Dash channel needed to be both top of mind but set apart from the main channels because they were time-sensitive. These aren’t your normal channels, and you should be actively trying to get them resolved.

I’ll be honest: It wasn’t fun telling the team that what we built wasn’t cutting it, especially because I was the most steadfast about making threads work. But we were able to salvage a good majority of the underlying code to pivot toward creating channels instead of threads. That took a lot of the sting out of having to rethink every piece of the language and user flow, as well as having to talk to the whole company as to why the app was completely different just a few weeks later.

The first sketches for the app were made in late February and we launched in late May. In that time we went through 4 possible names, a number of tough product and user flow changes and dozens of test Dash channels to get the app to where it is today. It was a bumpy ride, but I’m proud of all the work our team did to stay nimble through every pivot.

What’s next

We’ve shown Dash to a number of people and the reactions have been positive. They can immediately think of uses for it in their own workspace. Most have been surprised that Slack doesn’t have a feature like this to quickly create channels already.

But the conversations all eventually turn to how humans usually end up taking the tools we use every day and bending them to work in the not-too-big, not-too-small spaces. Huddle threads had been a solution for some of that, but Dash channels do it even better. Sometimes you really just need to get people in a room. We made that part easier and added a bit of pressure by adding a deadline. And we also let people celebrate when a big task is done and clean up after themselves.

I’m excited to have even more people use Dash and give us more feedback on how to keep improving it. We built it to be used in ways we haven’t predicted yet, so let us know how Dash can work for you.

You can learn more about Dash and all the experiments coming out of Postlight Labs by visiting our Labs page. To keep up on all the goings on at Postlight (Labs and otherwise) be sure to subscribe to and sign up for Track Changes, our podcast and newsletter.

Matt Quintanilla is a Partner and Director of Product Design at Postlight. Say hello: hello@postlight.com.