As a developer-focused product, many of our conversations with users start in our support channel, where anyone using Stormpath — whether or not they pay us — can ask questions about our API, or get help with an integration. For free.

However, developer support is more than that. As a startup building a new market, support isn’t just for putting out fires as quickly as possible. It’s a critical channel to learn what our API users want and need. I like to think of support as the front porch of our company, the place where we can meet our users, have conversations, and bring people from inside the house out for a chat.

This virtual front porch has helped us find our Product Market Fit, through deep conversations with users of all kinds, from small companies with new projects, to large companies with legacy migration plans. User management encompasses many concerns, and sometimes it’s easier to reach out with questions, and we learn as much from the high-touch support process as our users do.

As an engineer at Stormpath, I joined the company because I was really excited about the product and what it provides to developers. Having built user management on my own, time and time again, I’m eager to work on a re-usable solution that developers would like. As we have grown, I have been pulled into a lot of conversations in our support channel.

To my surprise, support isn’t just a technical answering machine. It’s a critical tool for growing a company.

Technical Support In a Small Company

I won’t lie, it’s difficult to achieve this level of developer support at a smaller company – our load grew over 30% last quarter. But it’s working so well that I’ve had fellow developers come to me at conferences, and thank me for an interaction that we had on support!

As a growing company, we’ve managed to pull off the growth with some light process and an organizational structure that works.

Support In A Seed-Series Startup

In the early days of Stormpath, everyone was a support engineer. The business team handled the “front line” – or first touch of support. Anything they couldn’t answer involved an engineer, who rotated through on a schedule. This gave everyone on the engineering team a clear view of what our very first users and customers were doing with our product, and closed the loop between engineering and the API user when we were debugging.

As our support demand grew, this rotation was also very draining for the engineering team, and slowed down their work on the core product. After raising our Series A funding, we expanded the team and mostly moved the core engineering off the support channel, except in cases where a customer needed them directly.

Front-Line Support

Not every case requires an engineer, but all cases require someone who knows the Stormpath product well. This is where our front line comes in, they are the first responders who can answer most questions about our SDKs and APIs quickly.

This role requires great relationships across the company, as well as technical know how in the technologies our users prefer. Our front line overlaps with our marketing and business teams, as many support questions come from teams evaluating Stormpath. The front line is also the air traffic controller for involving technical teammates for more in-depth responses, connecting customers with specialist engineers. Since we support so many libraries, each of which has a different owner, this air traffic control is critical.

The customer really wins in this situation, because they get to have an engaged conversation with a real person who can help them understand where Stormpath fits into their architecture. If the conversation is more technical, it’s just button click to bring an engineer into the conversation. With such a small gap between teams, everyone gets their questions answered quickly.

Startup Support Technology – Zendesk

We moved very early to Zendesk to manage support, and for the most part, it’s been a fantastic primary tool for us. It connects to jira so we can track feedback to issues, to our alerting tools so we know immediately if an enterprise customer creates a ticket, and to salesforce where we have a comprehensive view of the user across systems. It also allows us to loop people — either on our customer team or on our own — into the conversation quickly. And it allows us to centralize conversations about issues, and track them cleanly over time.

Why no IRC? A lot of companies use Slack or an IRC channel as a room anyone can drop into for help. While we love this in theory – open doors for developers! – it made it actually made it harder to connect both ends of the conversation – Stormpath engineers and the users. It was extra work for our team to follow a thread and drive user feedback into issues on the product roadmap. It doesn’t connect as easily to other systems, or archive as well, and its hard to staff such that a developer has a reliably good experience.

Plus, we often have someone in support chat, which tracks to user tickets on the backend so we can make synchronous conversations between two people, a broader asynchronous conversation amongst a team, if that’s what the issue requires. And we occasionally use a large customers’ Slack channel to make their lives easier.

We also increasingly use GitHub issue tracking, which I discuss more below.

Issue Triage

At any point in time, users at all stages of application development may hit us up on support. Some are working on an urgent project that has to go out soon, and others are building proof-of-concept apps as part of a longer project evaluation.

Because we have open conversations with our users, it’s easy for us to ask what their production time-line looks like, and offer workarounds if there is a blocking issue. We have a basic formula which we use for prioritizing, and it uses the following elements:

  • Is the issue impacting the performance of our public API?
  • Is the user in an urgent situation (like a product launch)?
  • What subscription tier is the user on? We support developers with free Stormpath accounts, but paying customers get a higher prios and Enterprise customers have support agreements.
  • The time since the last response by the customer.

In the end we strive to help everyone who knocks on our door, and this matrix helps us triage in a way that keeps conversations moving smoothly through our system.

Our Product Manager Prioritizes The Big Things

For users asking for new features or running into a product limitation, our PM will communicate directly with them to understand the issue. In parallel, the PM will work with the engineering and business teams to understand where this request fits into the roadmap and what the priority may be. And because we practice Kanban at Stormpath, we can change quickly in response to customer input and engineering bandwidth.

This transparency of process is really valuable to our customers, as they can plan with us.

Developer Visibility – Using GitHub and Waffle

Because I’m a maintainer of our public JavaScript libraries on Github, I’m usually working with feature requests and bug fixes that are reported on GitHub. In practice, this means that my team treats Github as part of our support channel. This high degree of visibility makes it easier for developers to find existing issues and workarounds, and comment on feature requests and limitations.

We use a Waffle Board to visualize our Github workload and follow a Kanban process. We’ve been doing this for almost four months and we are really loving it, you can see what my team board looks like by clicking here.

Pair Programming With Customers

Yep, we do that! Sometimes it’s easier said than typed, and a screenshare is worth a thousand email replies. If we get stuck with a customer, we will offer a screenshare to dig in and find the issue. This is a necessary reality these days because so many new software projects are an amalgamation of SaaS products, and there could be a problematic interaction between products that you just won’t find otherwise.

Customers leave these sessions with a feeling that we got their back, even if they run into something really sticky.

Support Benefits Me

I really do love doing support, and I’m not going to lie, that surprises me. But it benefits me and other Stormpath engineers in so many ways: I understand better how our users work with the libraries I build. I feel like I’m helping people and making their lives easier, which feels good. I get to collaborate with a wide range of engineers. And I know my work not only impacts Stormpath, it also impacts the user, their team and business.

It’s About Culture

For support to work, it’s very important that everone who touches the support channel has an attitude of cooperation. Stormpath’s mission is to help developers build amazing things by building a platform that developers will love and trust, and at the top of the list of our company values, it reads “Deliver convenience above all.” We have a great support culture because it an integral part of our broader company culture. We tend to it with care because we can learn so much about our users and what they are trying to achieve with Stormpath.

If you’re building a startup and thinking about support, I hope these lessons are helpful to your team. If this conversation is exciting to you, we have roles available on our core engineering team, and our customer success team! Please check out our jobs page.

As ever, if you need support you can create a ticket on our support channel or email us on [email protected].

Happy coding!

-robert out