This is the next part of an ongoing series about product culture. Make sure to check out the previous chapters on Airbnb and Stripe.
Slack Huddles
This morning Slack announced a set of new features intended to help teams stay connected in a post-pandemic world. Included in today’s launch is Slack Huddles, a lightweight, audio-first way to communicate inside a channel or direct message. Huddles addresses the need for fast, ambient, and informal discussions — spontaneous conversations that would happen in hallway encounters or at coworkers’ desks. These chats form the connective tissue of essential work, living somewhere between asynchronous messaging and synchronous meetings. It’s the stuff too urgent, trivial, or nuanced for a typed-out message, but not something that merits (or can wait for) a scheduled meeting. I encourage you to read Slack’s blog post to learn more about Huddles, video, voice, and screen-recording clips, and the other features1 included in today’s announcement.
For me, the launch was a perfect excuse to ask for a glimpse into Slack’s product culture. Slack’s VP of Product Noah Weiss and Senior Staff Product Designer Anna Niess were gracious enough to talk to me about Huddles and how product development works at the company. (Disclosure: I’m an investor in Slack through my time at GV and have worked with the company in various capacities since 2014.)
Ken Norton: Tell me the Slack Huddles origin story.
Noah Weiss: Teleport back in time to Memorial Day of last year. What everyone thought and hoped would be a short shutdown of physical offices was by then obviously — and very sadly for the world — something that would last a lot longer. It was evident in talking to our customers that every month that went by where we stayed in this fully remote world exponentially increased the odds that we would never “return to normal.”
There were some bright spots. Undoubtedly it created more flexibility in where and how people work. Remote work had the power to create more inclusive environments than those notorious in-person meetings that could feel like the Thunderdome. And despite the challenges of the pandemic, many people glimpsed how remote work has the potential for better work-life balance because of no commuting and flexible hours.
Anna Niess: But people were also spending more time in video meetings than ever before, and it was exhausting. Calendars were stacked with long, bloated meetings in hopes of staying connected and aligned. But all the personal connection was gone, it felt terribly inefficient, and it was hard to find time for the real work.
Noah: We were doing these pulse surveys every month of something like 10,000 knowledge workers. They told us that the number one thing that was suffering was a sense of belonging. Do you still feel connected to your team? Do you see how your work relates to the company and its mission? Increasingly, the answer was no.
And we were hearing from our customers that Slack was the closest thing they had to something that felt like a digital headquarters. So, one big starting question was how do you help recreate some of the serendipitous ad hoc conversations that used to happen in the office in a lightweight, impromptu, low-stress, unscheduled, organic way?
Another big question was how Slack could build new ways for teams to feel connected without so many meetings? Of course, it would have to be asynchronous because that’s the predominant way people use Slack. Were there ways to replace at least some of the meetings and processes with asynchronous alternatives that are more flexible, more time-zone friendly, more work-life balance friendly?
Anna: We built a prototype for the first prompt in about a week. I feel like Slack is probably the only work software that feels like a place where you can genuinely connect to other people. And that was important to me and something that I wanted to expand on. We knew we didn’t want to recreate a telephone or emulate the stuffiness and formality of a video meeting. The serendipity of ad hoc communication was important because that’s where Slack messaging has always excelled. It’s just those quick conversations that you have between formal meetings and deep work.
Our very first prototype was an instant hit inside Slack, and people immediately started using it. One of my favorite moments was connecting with people that I knew from the hallways of the New York office but that weren’t on my immediate team. I hadn’t heard their voice in five or six months. And suddenly, I could see them online, flip a switch and say, “Hey, what’s up!”
That felt so magical, just fantastic! We knew we were on to something, and then we were chipping away and building it over time and gradually expanding the scale of internal testing.
“Prototype the path,” one of Slack’s five product principles (Source: Slack Design blog)
Ken: How did you decide to go from internal testing to giving it to external users?
Noah: We kept seeing it snowball inside Slack. But at our customer scale, we can’t just build something that Slack employees love and then launch it to the world and hope it works. That’s especially true for the more social software that Anna and I and our teams have been working on. It only makes sense when you see how groups of people start using it together.
In early February, we started to bring in some larger enterprises from our customer advisory boards. These are stakeholders invested in our success, who like to co-create software with us. It was a nerve-wracking leap because even though we loved it internally, we know other companies can be very different from ours.
Anna: Different people use Slack in so many different ways that it’s impossible to know if you have the right design until they use it. You can’t know without learning and listening to people.
At the end of our pilot, we had more than 100,000 people testing it. But it started with only ten people. Every time we would polish it up a little bit, hear from people, refine the experience, do another build, and expand the audience. It was figuring out what sticks, what doesn’t and learning what the primary use cases were.
Data-informed, but not data-driven
Ken: You started the project with research showing that workers were losing a sense of belonging. I would suspect that wasn’t a traditional product metric on a dashboard somewhere ready for optimization. How do you measure that?
Noah: Those types of qualitative metrics are north stars for our product – but not something you can A/B test your way to improving. You measure your product’s impact by putting it into people’s hands, seeing how they use it, seeing how it makes them feel, and listening to the feedback they give you. There’s a saying at Slack that we’re data-informed but not data-driven. That stands in opposition to the cultures of companies like Google (where I worked), Facebook, or Amazon, where there’s a sense that you can empirically understand whether you built something that is at least good for the business.
Anna: Relying on qualitative feedback does take longer, but I will say that people are not hesitant to give us a ton of input because they spend hours and hours a day in Slack. It’s the central place they communicate with their team. Because of that intensity of use, building confidence in UI changes takes time. It’s not a place where you can just run an experiment and call the shot. Here it’s more of an art of listening and interpreting over time.
Noah: One of our core company values is humility. The way humility manifests on the product side is that we’re self-deprecating about our ability to predict what customers will want. Humility underscores everything that we do. We’re not overconfident in our ability to predict what customers want, and so we’re constantly eager to take the fastest path to learn what that is.
Anna: Many companies have product principles, but they genuinely drive every critique and review at Slack. One of these principles is to “prototype the path,” which we lived by while building huddles. It’s easy to find a team arguing about some point or another for way too long. So here we’re quick to say, “Hey, let’s just prototype it, see how it feels, put it in front of someone.”
Noah: Our mission is to make people’s working lives simpler, more pleasant, and more productive. Of course, measuring productivity has been the siren song of economists and sociologists for decades. Certainly, we’re not going to pretend like we’ve cracked measuring productivity in Slack. So, it’s important to remember why people are paying us. They’re not paying us to spend more time in Slack. They’re not paying us to send more messages in Slack. They’re not paying us to create more channels or send more reactions or upload more files. So that means most of the traditional in-product metrics you can directly measure are far removed from our mission.
Ultimately everything we do comes back around to that larger mission. How do new capabilities affect teams long-term: Do they stick around more? Do they roll it out to more of their company? And now, with Slack Connect, do they pull other companies that they work with into Slack? Do they love it? And do they tell their friends? (For that last question, Net Promoter Score – NPS – is one of our core metrics.)
This is the essence of our business, of course. I help lead our self-service business — the customer segment that has no direct sales support. It accounts for most of our paid customers and fuels our bottom-up enterprise growth. At the end of the day, these companies only buy Slack when teams of people love using it. When it makes them more productive and makes their working days more pleasant.
Slack CEO and co-founder Stewart Butterfield
From philosophical discussions to tasting the soup
Ken: You have a legendary product CEO in Stewart Butterfield. How does Stewart engage with a project like this?
Anna: He’s a product person, and he enjoys being a part of the process. He was involved at the beginning of the project because he wanted to be jamming with us, talking about the future, and helping shape the overall direction with us. And then he was deeply involved near the end because he cares about the quality of the experience.
Noah: This is an excellent case study for working successfully with a strong product CEO, and there are some valuable lessons here. Imagine a chart of the project lifecycle where the X-axis is time, from idea origination to final launch. The Y-axis is the depth of CEO involvement, from minimal to heavy. Anna is describing a U-shape, which is quite a good model for a successful project. The CEO is involved a lot at the beginning, less so during the middle, and heavily again near the end before launch.
Noah Weiss’s Model for Successful Product CEO Engagement
People often end up having their CEO engagement look like an inverted-U shape, which is the opposite of what you should do. Those projects usually don’t ship, to be honest.
Anti-pattern for Product CEO engagement (don’t do this)
After a coworker joined Slack from an enterprise company, I asked him what the most significant difference was. He said, “at my old job, you sold the vision to executives. But at Slack, you co-create the vision with Stewart.”
And so, at the very beginning, it’s all philosophical, right? That’s where Stewart loves to be involved.2 What are the principles behind our approach? What are the constraints and guard rails we want to use? How much do we care about, for example, being voice-primarily versus voice-only? Stewart loves to make useful software.
After the initial origination stage, you begin prototyping and executing against that co-created vision. Stewart has quite a refined palate and likes to come back near the end of the process to “taste the soup” with you. The finishing touches. The software equivalent to saying, “It could use some more fried onions on the top,” or “It’s a bit light on the salt.”
Anna: We’ll have highly detailed conversations with him about what color blue to use on a button or which icons we should be using. He cares about the details.
Noah: The blue button example is perfect to elaborate on because I worked at Google on search when the infamous “41 shades of blue” thing happened. At Google, the way you decided what color blue to use was you ran experiments, you measured CTR and CPM, and you picked the shade that performed best. That’s it, done. Here it’s more about understanding how much your users should be caring about the button at this moment as they’re trying to get the rest of their job done. That, in turn, helps you develop a point of view about the right level of prominence for the button. Is it too bright?
Anna: Here, it’s more of a nuanced conversation, “Is the blue distracting; is it too hot?”
Organizational fluidity
Ken: What does this all say about the product culture at Slack? How would you characterize it?
Anna: Slack’s product culture is fluid. Our roles and teams, and surface areas are very fluid. They kind of mesh into each other a lot. And there aren’t a lot of hard lines in our organization. Everyone does a little bit of everything. As a designer, I spend maybe 40% of my time doing product work. Noah spends a lot of his time doing design. The philosophy behind fluidity is that the world changes every day. So we need to adapt to our environment and make sure that we’re solving the most critical problems for our customers at any given time, regardless of job title.
So, whether that’s confronting a global pandemic and completely reshaping how everybody works or shifting team members around because someone is on parental leave. That’s the philosophy behind the fluidity of our organization.
Noah: That’s a big part of why it’s so much fun to build products at Slack, frankly! There’s much less rigidity. You get to play many different types of roles. We try to spend the minimal possible time on the product shaping or definition process. On the product management side, that means less time writing documents and internal influencing and the like. On the design side, it’s about how fast we can go from a design tool to living in a prototype that we can use with our own hands.
Ken: That fluidity and overlap of roles can sometimes melt away as a company grows and becomes specialized. I often heard at Google, for example, that designers wanted to do more product management work, but it wasn’t valued on the job ladder, which meant it wasn’t rewarded at promotion time. How has Slack maintained this as you’ve grown to more than 2,500 employees?
Anna: Here, it’s celebrated and is formally a part of our culture. We call it “flexing.” Flexing is being able to jump in and work on any problem and contribute in many ways. It’s celebrated in the organization. If you make something a part of your company values, it’s easier to maintain it as you grow.
Noah: When we look at even how we promote people, we evaluate them against three areas: first is craft, second is impact, and third is behavior — which is how do you live the values in your work? And that’s true of every role. In many other organizations, the definition of impact is situational. “Is this successful or not?” Okay, that’s the Product team’s problem. “Does this feel good?” That’s Design’s problem. “Does this work?” That’s Engineering’s problem. Here impact is more about the customer and the business, a sense of shared ownership for our work, more collectively.
Anna: Shared accountability!
What does Slack look for in a product manager?
Noah: I haven’t worked at Google for a decade now, but I remember with Google PM interviews, the slate was all PMs, and then there was that one engineer who was trying to assess whether the candidate kind of understands computer science.
Every Slack product manager I’ve ever hired has always interviewed with a design lead who took the candidate through an interactive design exercise. And conversely, almost every designer we’ve hired had a product manager in the interview slate who evaluated how the candidate focuses on the problems that matter for customers.
Anna: To build on what Noah said, I interview product managers at Slack a lot, and I have them do a design critique of a prototype flow or example feature. I want them to get into the details, to observe and notice little things and big things. I also want them to have a perspective, a firm opinion. Able to be pushed and prodded a little bit and to be critical of their viewpoint.
Noah: We hire PM generalists primarily. We occasionally look for domain knowledge, such as someone joining the enterprise security or developer platform team. On our team, we mostly have people with consumer experience.
We look for people who have an excellent understanding of product craft, or “product sense,” as we call it. People will debate on Twitter whether that exists, but I would say it means someone who can take a design thinking approach to build a product people love. Someone with an understanding of what underlies great products and who can apply them with a design partner.
We also emphasize execution and a bias for action. Sometimes you can measure things; sometimes, you can’t. So, do they get how to build software in this messier, more prototype-driven manner?
The last big thing we look for is product strategy. For a lot of other companies, strategy is an obsession with the market and their competitors. Here at Slack, we’re competitor-aware but customer-obsessed. So for us, product strategy is about whether this person can teleport into the future to get insights, ideas, and opportunities around unmet customer needs. And then work backward from those insights to inform what we should build in the present.
And then, obviously, all these characteristics have a behavioral overlay. Is the person someone who can take a humble approach to create room for everyone to help shape the product? Can they collaborate well cross-functionally to bring out the best from their teammates? Can they help their team perform smarter and more efficiently? And can they bring a playful spirit to how they work that they can also infuse into the product itself?
Does that sound like you? Slack has several openings in product management and product design in San Francisco, Denver, Vancouver, and remote.
Slack’s Product Principles:
1. Don’t make me think2. Be a great host3. Prototype the path4. Don’t reinvent the wheel5. Make bigger, bolder bets