Define the feature

The first step was to define the feature based on customer feedback. Of course, to accurately do this, as Geda explained, we need to dig deeper beyond “I need a Slack integration.” So we talked to our customers to get additional insights.

These insights gave us a better sense of what our customers really needed and how to build our solution. But we still needed to get more clarity about how the feature would operate, so we continued to engage them to see how teams would use this feature.

Would only product managers or other team member use it?

Would this be active only in internal Slacks or in community ones as well?

Do we need to tag messages sent to productboard based on various characteristics, such as user?

After getting these questions answered, we wrote our feature brief.

Create a mockup to make the idea real

Based on these learnings, we created an InVision mockup and circulated it internally. This serves 2 goals:

Get quick internal feedback

Align everyone on the feature

Our mockup

This step was so helpful because it let me know that I had missed a couple of use cases when I showed it other people on my team. Since it was a mockup, I was able to iterate it and recheck those use cases quickly.

It also aligns everyone on the feature so everyone understands what’s coming. Ultimately the mockup, along with the feature brief, is a communication tool that allows the product and engineering teams to collaborate more effectively.

Create a working prototype for internal validation

After validating the mockup, we built a working prototype within a few days! From a technical perspective, it really helped us learn more about the API and better understand best practices for handling things like metadata within Slack. One of the main benefits of building the prototype is to get feedback from our customer-facing teams since they’re intimately aware of customer sentiment and can predict some of their feedback or objections based on their relationships with them.

Our working prototype

Beta test for external validation

After validating the feature internally, it was time to test it with some customers! When Geda wrote about the Continuous Discovery Process, she said it’s important to make sure you keep all your feedback consolidated in one location. A huge benefit of this is that you can quickly find the customers that requested this feature to include them in a beta test.

We were also able to use our Slack community channel to test our beta. Our engineers participated in the Slack channel and were able to resolve bugs within an hour. Since we were doing these fixes live with customers, the process was completely transparent, and we updated customers immediately. The feedback loop was insanely short.

Our beta test integration

Launch and celebrate!

Using a tight process to turn feedback into a product with our internal teams and customers always in the loop, we were able to launch our Slack integration in 20 days. If we hadn’t kept close contact with our customers, identified actual needs instead of user requests, and kept our feedback in a central location, we probably wouldn’t have been able to launch it so quickly to wonderful reviews!

One of the important things we always make sure to do when we launch a new feature is to celebrate it. A lot of work and thought always goes into these initiatives, and it’s always important to make sure that everyone gets to celebrate when things go well. It keeps the energy and momentum going because remember, the work doesn’t stop here. The next step is diving back into customer feedback to understand how we can continue to make our Slack integration work better!