Why we built Relay — our Slack app
Last week, the Knowtify team released a fun little product called Relay.
Relay is a Slack app that intelligently streams user activity from your product to Slack. It’s a great little app that allows you to manage user events coming from Segment, Stripe (or directly via our API) and selectively stream them to multiple Slack channels.
It’s a great way to keep your entire team in-touch and in-tune with your important user activity.
But…WHY did we build a Slack app?
As we were developing Relay, more than a few people asked why we were developing this separate Slack application — to live alongside our main product.
It was a very good question — one we asked ourselves several times before jumping into the work. Ultimately, we decided to go forward with the work.
I’m not saying we made the right decision (only time will tell), but I wanted share our thought process (and some early results) that might help frame some similar conversations happening around the ecosystem this very evening :)
The Initial Conversation
The initial conversation about Relay happened on a lazy Tuesday afternoon around the holiday, during one of our regular product meetings.
The topic of the day was some new functionality we had built for our main product.
The functionality allowed our customers to view a realtime (and filtered) stream of user activity coming from their product. of The functionality was good — we released an early version to some customers and they were liking it…and using it!
Which led to our first question…
Would this functionality be something that would be valuable for people beyond those using our product?
As we sat in our product meeting and looked at this functionality, trying to plan how to make it “production ready”, someone quietly said, as if as an afterthought,
“You know, I think entire teams would love to have this kind of transparency into user activity/engagement. Meaning — more than just the people using our product.”
And the room went silent. No one said anything for what was probably 5 seconds, but felt like 5 minutes. Clearly everyone was thinking the same thing.
Within any of our customer’s organizations, we have specific users using Knowtify. Generally 1–5 people.
But this new functionality was presenting information about user activity in a way that was unique and potentially valuable to more than just the people using Knowtify.
Someone else said,
“It’s true. I can definitely see every team wanting access to this — maybe for different reasons — but access none-the-less.”
Oh boy. It was true. Internally, we had all been using our new functionality for different reasons — but we were all using it.
We decided to leave the meeting and talk to the few users who were using it thus far. They seemed to agree with our assumption — some more strongly than others, but general agreement. We also shared the functionality with a few other companies in our network and the responses seemed pretty good.
So…that kind of answered our first question. Yes, this information — transparency into user engagement — was valuable across an organization. Beyond our current user base.
Which brought us to our 2nd question…
How can we make this happen? How can we give other members of our customers’ teams access to this information?
This brought us to the second big question.
If the information was valuable, how were those people outside our regular users going access it?
Well…we could ask them to login to our product. We could tell them that if they want access to this information, they would need to create user accounts and use our product.
Essentially, we could ask them to come to us.
“Well, that’s a good way of increasing users, right?”
In theory. But we knew this wasn’t realistic. We know that in any company, every group/team has their own set of tools and they simply don’t login to any products outside of that. Nor should they.
So…the other option was to bring this information to them.
Better approach. Definitely. But it led to the question — how do we do that? Or, in this case, where do we do that?
This question was about the best channel for delivering this information. It had to be a channel that entire teams or organizations were using.
The most obvious was, of course, email. We could try to figure out how to bring this data to entire teams via email. But there were issues with this —some of this data was valuable in real-time and, generally, it wasn’t nearly as valuable “summarized” into a package once a day. Email, while a ubiquitous platform, wasn’t the best channel for this data.
Which brought us to the next option. A place where teams were already congregating and collaborating. The platform that was quickly becoming the modern-day water cooler.
“What about Slack?”
The quiet voice asked. Yup. He was right.
Not only was Slack a place where teams were already collaborating, but it’s stream and channel structure was perfect for the type of user-engagement content we were sharing. Yes…not every team in the world is on Slack…but it sure feels like it’s getting close :)
So…that was decided. We had our platform. We were all in agreement that we would scope out a Knowtify app for Slack.
Well….not so fast. The next question came from a dark corner of the room…
Why don’t we break it out so any company could use it — not just our customers?
Again…the room went silent.
“Every software company needs to be in-tune with the engagement of their users. Why would we limit this to just people who signup for our main product?”
“Beeeecauuuuuse that would help us get more users?”
“Maybe. But probably not. There is a bigger market for this functionality — let’s call it Functionality A — than there is for Functionality A + Functionality B. We’d just be limiting the opportunity…”
Ok. Let’s do a quick prototype and see what this would take.
So, we Built a Prototype
And we used it ourselves — in our Slack account. And we were really into it. There were things we didn’t like — that we knew would be required functionality if we were to launch it as a product — but overall, we were pretty, pretty pleased.
We built a landing page. Put it out on a few channels. Got a decent amount of signups and some, again, qualitative affirmation that people wanted it and would use it.
So, we decided to built it. We decided to brand it and ‘productize’ it. We went for it. We dedicated a decent amount of time, but not a ton. Definitely a decent risk/reward ratio.
And we Launched it…
We got a version that we were happy with — one missing probably 35% of the functionality we would love to see it have, but we were happy enough to launch it.
“Let’s do it.”
Said the quiet, crazy voice from the shadows.
So we did. Of course, as a Slack app, we made Product Hunt and had a good day.
And we were off and running…
Should we have done it?
As I said earlier, it’s way too early to tell whether or not this was a smart decision. We had~300 companies signup in our our initial week and the good news is that 25% of those companies became active users (not all paid, but active). So…that kind of validates demand and whether we made it simple enough for a full self-serve use case.
At the same time, it has increased the lead flow for the main product by about 50% in its first week — which we consider a nice win.
AND less than 5% of the current Relay users came from our existing customer base — which validated the fact that interest for this product was wider than interest for both products. Another win for the shadowy voice.
Numbers aside, there are other factors we looked at when assessing our decision to build Relay.
First, it was a great exercise for the team. It brought us all together for a focused period of time to build something unique on a tight schedule. I think we learned and improved a lot of our product-processes while building Relay. I think we are a better product-building team because of this.
More importantly, as a company, we have the high-level goal of helping companies more easily drive better user engagement for their products. We believe that user engagement is the key metric for all software business of today…and tomorrow. Engagement is fundamental to all the things that drive the value of a software business — activation, retention, referral, growth, LTV, etc.
None of it happens without, first, user engagement.
And we built Relay because we realized that teams that are most in-tune with their users are the teams that build the best products and the best customer experiences. Relay is helping them achieve this goal.
If for no other reason, this makes us happy. So…should we have built it? Maybe, maybe not — but we’re happy we did. We’re happy that that Relay is a product that exists in the world…
Have questions/comments. We’d love to hear from you. Email us at email@example.com. Thanks!