If you’re in product design and development, you know there are a lot of ways to approach what you do. Every company has their own ethos that is shaped by what their product is, how they release new features, and the expectations of their customers.

When I first joined the Slack product team, I wasn’t exactly sure how I would apply the incremental, experiment-minded approach I’d embraced in my previous roles in an enterprise context. Lucky for me, I found a place where I could thrive. Slack has a distinct approach to product development and problem solving that is as central to my DNA as it is to that of the company.

Slack’s development philosophy, called “getting to the next hill”, revolves around two things. First, we involve our users in the whole development process from start to finish and beyond. Second, we make incremental, obviously valuable, changes. Our intention is to release them so seamlessly that our users don’t even notice them — they just feel that their work lives are simpler and more pleasant.

A Playful Beginning

To understand where this philosophy is rooted, it’s critical to understand Slack’s inception. The founding team was originally building out a video game called Glitch. (Drop some emojis in the comments if the memory of Glitch makes you smile!) Glitch was adored by many and some of it even lives on in Slack’s product today. It was not, however, a viable business.

The investors challenged Glitch’s founders to do something else with their investments (a true testament to the potential they saw in the team). The founding team looked at where there might be value in what they’d already been creating.

The revelation came in not what they were creating, but in how they were building it… together.

The team was distributed across cities and time zones. They logged on and off at different times of day, and conversations would often bleed into someone’s off-hours. They worked with large files and wanted to pass them quickly. If someone took time off, catching them up felt slow and clunky; things inevitably got lost in translation. Email was inefficient and the available chat protocol didn’t have features like persistent history and search.

So they built an internal communications tool. As a new team-need came up, they solved for it. The tool became essential to the way the team worked. The rest is history.

The immediate and huge demand for Slack across companies and industries propelled its development forward at rapid speed. The team received a lot of feedback on how to make this nascent tech solution better and more user-friendly. Slack invited its users into the process and they decided together what change would be the most valuable.

They broke down this massive mountain ahead of them and focused on one hill at a time.

Focusing on the Hill

My first project at Slack was to redesign the search experience. My team brainstormed a million possibilities of how to improve this function and make everyone’s lives easier. Those possibilities, though, had dependencies upon other features; they kept leading me down one path and then another until I was touching the edges of another product or features of another interface.

We pulled ourselves back and delivered a search experience that wasn’t perfect, but was clearly and obviously better — without redesigning all of Slack. That came later.

You have to define your parameters and design within them or you can talk yourself out of shipping anything. There’s always another thing to solve and another reason to delay your product release; you risk never delivering anything at all because you’ve walked yourselves into a corner and everything is in conflict. So you have to find a way to focus. One hill at a time.

As time goes on, limitations evolve and so do the needs of your users. Once you’ve “gotten to the next hill” you have a better vantage point. You can re-survey the land and figure out which next hill to climb with your new perspective.

Incorporating Customer Feedback

Really precise and nuanced feedback is central to our ability to make valuable, incremental changes. We build prototypes to feel out a direction, and then we test those prototypes out internally — a beautiful byproduct of being avid users of our own platform. Once we have something promising, we share potential feature changes with our customer advisory board, ambassadors, and champions.

Slack’s early adopters looked very much like Slack — they were small, dispersed tech companies that worked in a fast-paced environment. As we grew, we needed to incorporate more voices into the problem-solving process. Now we invite our users into Slack channels with developers, engineers, and customer experience representatives. This helps us get high-quality, high bandwidth feedback in real time so that we can get clarity, make changes, and hit the details just right.

These first conversations help us understand how a product feels to our users, something that’s imperative to us since Slack is a tool people work in all day every day. The metrics we’re looking for are often less tangible than something you can easily measure with an A/B test. Reaching a place of alignment with our users requires more intimate conversations about what they love and, of course, what they don’t. Once we’ve pleased our customer advisors, we release the feature to all of our users. Then we focus on getting to the next hill.

A New Normal, Feature by Feature

Every teeny tiny step of the way, Slack wants our users involved in the development and problem solving, especially as we enter this new normal of hybrid work. This constant feedback loop — whether that’s in direct development with us or the tweets our customer experience team picks up — is building a better Slack, feature by feature.

How do you break down your challenges so that you can focus on what’s in front of you?