In this monologue, Noah Desai Weiss explains how Slack’s product review workflow has transformed over time. Initially, the entire product team gathered in a single room for live, one‑to‑many presentations of releases. As the organization grew, reviews were reorganized around functional pillars (enterprise, audiovisual, self‑service, etc.), with each pillar handling smaller‑scale feature reviews and acting as the quality gate. The current process emphasizes extensive pre‑work: strategy documents are shared as pre‑reads, designers create narrated screen‑share clips, and prototype links are distributed so reviewers can explore the product on their own time. Reviews are framed as collaborative coworking sessions rather than adversarial executive rubrics, aiming for consensus and rapid decision‑making while still surfacing critical “one‑way‑door” choices. After meetings, follow‑up actions and discussions continue in Slack, creating a repeatable, efficient feedback loop.
Chapters
It's definitely evolved over the years, obviously. I think when I joined, it was like the whole product team, we'd all just get together in a room and just go through, hear the open releases and all sit around one table. I mean, that was kind of how it started. Fast forward to now, there's pillars for the enterprise organization or for all of our new audiovisual products or the self-service business and so forth. Those pillars wind up doing reviews internally for more of the smaller scale feature development or refinement or experiments. That's very empowering. And the leads for those pillars then wind up playing the role of kind of the executive backstop or the person who's pushing the quality bar. For our own product reviews, what we typically do now is we do a lot of actually kind of pre-work and pre-reading. So let's say if we're reviewing a strategy doc, that'll always be something that's shared ahead as a pre-read. If we're reviewing a design, we'll often have people wind up sharing like a clip, which is a recording in Slack where you can narrate over a screen share. So you actually have the designer walk through, hey, here's this flow that we're going to be reviewing. Let me explain the why behind it. And honestly, as someone who's going to be in the review, it's an amazing experience where you just play a couple of these, you lean back, you have your coffee, watch it on your time when it's going to be for you. And then everyone comes into the meeting with all of the feedback, all of the questions already there. So you're not wasting that time in the meeting with a one-to-many presentations. And then if it's a prototype, ideally people share a link to the demo build and you can actually play with it yourself. And that's the same kind of experience. And then the product reviews, again, going back to vibe, I really prefer for reviews not to feel like this is the team versus the execs. And the ideal that happens is that you get just like carte blanche approval for everything. And it's all about checkboxes and rubber stamps and everything else. And it winds up being a very kind of contentious kind of vibe. To me, it's a group of people who bring different perspectives, who are working together to figure out What is the best path to take to delight our customers? And so I don't know if we always succeed at this, but I think as much as possible, we try to have these reviews feel more like coworking sessions where it's the leads from the team, it's the leads from our product development organization. We're jamming together. Obviously, sometimes there are key decisions that we have to make. Sometimes those are things that we have to make when people don't all agree, and we'll make sure we cover those before the meeting ends. But more than anything, it's usually this very collaborative working session where we try to give guidance, fodder, and feedback to the team and make sure that any critical one-way door decision is unblocked. And then we do all the follow-ups in Slack after that and rinse and repeat.
