I see now that you only accept remote in the US. It would be useful to add that to the heading of your post, but I don't think you can edit it anymore.
As a PM that has started my career in Support/Success... I don't think I could ever advocate a strict two-request limit.
Customers (and customer teams) are a non-stop firehose of feature requests. It's important for the product team to hear all these requests, mostly so they can be understood. It's tedious work, but I do it with the intention of looking for patterns and having a pulse on the customers. You might be surprised by what you find, especially how many feature requests are actually different solutions to 1 larger problem.
My team does this using ProductBoard (https://www.productboard.com/) to synthesize all incoming feature requests on a weekly basis. We sit for 30 minutes as a team to go through direct requests, lost sales opps, etc.. This weekly work pays dividends when it comes time to prioritize features for the next quarter/year, etc.
Customer teams can feel empowered when they are given the tools/opportunity to prioritize things on their own, but the huge downside is that they feel silenced on a large majority of things they can't tell you (i.e. the "lower" priority" requests). This can really eat away at the morale of customer teams that feel they can't share their customer stories with you. When they hear feature requests from customers that they know are low-priority, it feels horrible to tell a customer it won't even be looked at by Product (it's even worse to lie).
I'd recommend a system where all feedback is shared, but only 2-4 feature requests are "voted" for officially by each customer-facing team.
Agreed that discipline around being reactionary is important.
I work with maintaining both a customer-facing website and documents (instructions, order forms, etc.). I have learned many times that a change based on a single issue can result in trading one problem for another. Allowing for trends to develop will help better define the best solution and help the most people. Defining a trend can be objective, but three occurrences in close proximity typically does it for me.
Totally agree with the “yes and” approach of firehose plus top two - I haven’t had a chance to update the post yet, but responded to similar feedback here: https://news.ycombinator.com/item?id=21971011
Cool! Another weird thing I've noticed when feature requests are capped for customer teams, is that customer teams will "game" the system.
At scale, customer facing ICs will do things to benefit them personally. It's not a bad thing, it's just human. Sales people do what they need to get quota, Support want to keep their ticket backlog down and CSAT high, etc.
If you receive all customer facing feedback, you can make the final prioritization call on your own. If requests have been filtered too much before they reach you, the priority must be taken with a grain of salt.
I totally agree with that sentiment, but I find it hard to swallow coming from Intercom.
Even as their customer, I find that they don't like to solve any problem that doesn't fit within their 'philosophy'. I've submitted countless feature requests to no avail, and clearly they've left their customer facing teams high & dry. I feel bad for their support staff and success teams that have been completely disjointed from product teams.
Intercom is my go-to example of a product that tried to re-invent the wheel, but only came up with half of a wheel. They need to finish it. They need to help customers solve the problems they are experiencing, which continue to exist because some missing features don't fit the 'Intercom philosophy'.
Generally speaking for any product team, just make sure you've completed your due diligence of making sure a problem is in fact rare and small. You'll often be surprised at what you uncover.
As an aside, I think companies should take "problem requests" not feature requests. A feature requests implies a solution, and letting your customers be your product designer leads to generally messy and poorly designed products.
So rather than submitting "I'd like the app to do Y", it would be amazing if customers instead submitted "I'm trying to solve problem X and having trouble." Maybe Y is a good solution for X, but maybe Z is too and Z wasn't asked for even though it might be what you need.
Features always need to be put in the context of the problem(s) they are solving. If a product team is implementing customer feature requests in an open-loop they are doing it wrong. The product designer's job is to synthesize multiple requests, find the root causes of the problems and come up with a compact composable design that knocks out multiple FRs at one time. Simply implementing FRs gets one into a wall of buttons.
Taking only 'requests' leads to a whole range of potential problems:
- Feature bloat with random one-off buttons and gizmos
- Product teams getting in the habit of ignoring requests if they know that most don't quite fit
- Really complex products (both for customers and internal teams to understand/troubleshoot)
- Unclear roadmaps
- Wasted time. For example, I had a request to build a notification-silencer for specific executives at a company. I recommended that the executive set up email filters instead
I once implemented a GetSatisfaction/UserVoice-esque feedback widget. The most useful feedback we received came in when we worded the widget with text like, "What problem would you like us to solve for you?"
It got slightly less responses than a generic, "Feedback form" label, but the quality of responses was much higher.
Sometimes a product team think they know what their customers want and are tunnel-visioned with their 'wheel' too much to see the forest through the trees. Also, it's not uncommon that product teams prioritize feature requests from their larger accounts over smaller ones.
Feel free to check out Re:amaze [0] (I'm a co-founder). Our philosophy and product is driven solely by customer requests - not looking at what others do and just trying to fill a competitive feature checklist. If there's something you need that you don't have right now that we can solve, we'd be absolutely happy to discuss. We leave no customer request stone unturned.
We're starting to look at our 2018 roadmap and the first thing we are doing is looking at feature requests by our customers (both big and small, we don't discriminate) and plan around solving our customers' pain points. In fact we do that every week as well, albeit at a smaller scale.
On the issue of disjointed teams, I really do think it's extremely important for the product team, engineering team and everyone in a company to be involved with customer support and actually answer customer support conversations. That's the only way (aside from being a customer directly) that the company as a whole can get behind the customer and understand their pain points. That's in fact how we do things at Re:amaze. While that might be shunned at and not too feasible at larger companies, there's still a ton of room for a sliver of that to happen.
Totally agree! I work on a completely different product in a different market (Stockfolio, a stock and crypto investment app: https://stockfolioapp.com) but I've found exactly the same thing to apply.
Once you have a working product in a market you know exists, the most important features will frequently pop up; people will reach out to you. You can then use all that feedback to build out a great product.
My list is too long to share, but let me give you a very simple example.
On most chat platforms, the widget displays an "mail" button or something similar that allows the visitor to send the transcript to themselves for reference later on.
Intercom does not have this, and agents don't the ability to quickly send transcripts either. Our team literally has to copy/paste the transcript into a new Zendesk ticket to send it.
Intercom's philosophy dictates that a 'conversation' is an ongoing thing that happens anywhere: in-app if the user is in session or via email once the user's browser session your website has stopped.
Their philosophy ignores the very clear pattern of visitors treating the intercom widget like a "normal" chat widget (which many have come to expect).
The 2 ways to perceive this are:
- Adding this feature adds value for me and I should pay for it
- Adding this feature bring Intercom to parity with customer expectations, and should be included in the price. Not having it is an unnecessary blocker.
If your not using Docker as a deployment tool and want every deployed instance to be the same then you are SOL. Which is a shame, as there are other uses, but they are hampered by the lack of a couple of features that have had open tickets for a long time.
I'm afraid I don't understand what deficiency or scenario you're describing here. Does it have something to do with ensuring old containers are stopped?
Hi there! Support manager here. I've been leading support teams for years, led support QA teams, built troubleshooting processes and worked very closely with dev teams. A lot of what I wanted to bring up doesn't apply so much to solo dev's, but I want to vouch for non-devs and anyone that might start working on team.
Support brains and developer brains are actually not that different. I see on HN way too often that developers need space and time to think, but other types of people don't. This is myth that needs to be dispelled and everyone should contribute to uphold boundaries that work for everyone.
Trust that absolutely I want you to have 'flow' time - it's important that you both be and feel productive. Good code from you is good code for me and for the user.
What breaks flow is context switching, which is literally baked into the job description for your average support role. Agents often need to answer questions about multiple/complex products, and who knows if they have access to high quality documentation or internal tools.
When something breaks for a customer, agents need to find creative solutions or escalate the issue up do the dev teams. You bet that if there's another call waiting or 20 more emails in the queue, they're not spending a lot of quality time on getting things done right. The bug they submit won't be thorough, and developers won't want to touch those bugs. The workaround they give won't be well explained, and the user won't know how to manage once the call is over. These things wouldn't happen if agents had their 'flow' time too.
I would love to give customers all the time they deserve, but obviously there are limitations to how many agents you can hire to make that happen. When a customer team gets burnout from high support volume, it's rarely the volume alone that makes agents hurt. It's the volume AND context switching. 50 phone calls about different things will leave you a zombie by the end of the day.
It's totally OK that a support person's time is variable like this, but it's dangerous when the pairing developers time is untouchable. Pro tip: make ground rules for what developers might be "on-call" or have office hours, have rotating schedules for which developers need to help support teams, have dedicated places where agents can escalate engineering tasks without physically bothering someone.
Of course, there are so many factors that effect this: how many engineers and support people there are, what kind of issues need to be worked on, what are the priorities for support hours or shipping new code.
At the end of the day, just know that we're all people on one team (albeit with very different daily responsibilities). Respect each other's time and needs, and the rest will fall into place.
Thanks for your thoughtful reply, but I think there are a couple of points that you may have missed in my original post.
> Support brains and developer brains are actually not that different.
Agreed. I wasn't talking about intelligence or analytical skills per se, but rather the 'mode' that you think in when in either situation.
When developing code, my mind is racing ahead and planning out things that are far beyond what I am working on. In essence it is multi tasking, and juggling several tasks and ideas at the same time. I am 'ahead of the aircraft', to use pilot speak, and I am constantly trying to anticipate problems that may occur and critical tasks that I know I will have to complete. Complete with all this is jumping around between several editor, terminal, browser, emulator windows etc.
However, when doing support, I have to be completely and utterly present with the person on the other end of the support call. I can no longer 'free wheel' and distract myself with other tasks. I have to display full empathy with the customer, and ensure that I am accurately picturing in my mind what they are trying to say.
If the customer is a slow talker, or non technical, then I have to kick in extra energy to make doubly sure I am being effective in providing the best possible support experience.
My analogy above about race car driving and knitting is not outside the mark. Both are skilled tasks, but they both require a completely different mode of thinking and presence of mind to be able to execute to the best of your ability.
"At the end of the day, just know that we're all people on one team (albeit with very different daily responsibilities). Respect each other's time and needs, and the rest will fall into place."
I do a lot of helpdesk. I've found out most of the time there is a huge difference in information availability between support desk and the rest of the company. Support people spend a ton of time and frustration finding out what the hell a client is talking about, who promised them things and where or what the hell the service level agreement is.
I made a lot of (account) managers very very angry by stating well written documentation and procedures should available to the entire support team. It should be a milestone of EVERY project or else there is NO finished project. People should not be held responsible because of lack of supplied information. Especially when they've asked for it a gazillion times.
This is one of the reason these teams hate each other so much in big companies.
It’s support’s job to focus on one thing at a time, meanwhile it’s a coder’s job to try and keep dozens of things in mind at a time. Context switching IS hard regardless, but like you said, one of the roles has it baked into the job description.
The crux here is that Programmer committed to X work done by the end of the week, and Support is effectively subtracting their time to accomplish X. This is a managerial problem, and not an easy one, because it’s not predictable.
My estimate, if you’re a programmer working 40h/wk on a live product, 8h of coding is a good week. Expect the majority of your time to be spent planning, reviewing, and supporting. If you’re sacrificing one of those to get more concentrated coding time, make sure that is communicated. YMMV.
In any case, if you don’t have managerial support to get engineer resources to fix problems, then it’s not support - it’s therapy. Sometimes that’s the best you can do.
I would hardly say it's supports job to focus on one thing at at time.
Most people that reach out to support are calling about a specific question or problem. Yes therapy calls do happen. They're not terribly common, but you'll hear about them because they are funny/egregious examples.
When a customer calls about their 1 thing, I can definitely look up the 1 answer or do the 1 fix for them. This is bad support though.
A good support team will listen to that customer, understand what they're needs are and fix that thing while make sure they are set up for success in the future. This means I'm checking different account/user statuses, feature usage, and billing history. I dot his while talking to them, but never letting them know I do this.
If I can understand their 1 question AND know who they are holistically, I can set them up for success and prevent more support tickets down the road.
If you've ever had a user or a profile sent to you in a bad/extreme state, you can bet that a series of 1-off support solutions could have lent to that.
Maybe other support organizations are different or maybe I am busier than normal, but the concept of one thing at a time is foreign to me.
To outline today:
Left comments on ~15 net new cases to jump start the troubleshooting by the technicians assigned to them
Help led a morning meeting reviewing cases where people are stuck
Researched whether an old (7y) version of the software had a piece of functionality
Made comments helping ~5 different technicians globally on their cases
Helped a colleague craft a SQL query to help replicate an issue then talked over strategy
Logged into a colleagues VM where they had an install problem
Had a call with the pre-sales brass about trends in the support organization
2 walk ups:
- Intermittent reload issue when triggering things via API
- How to setup a reverse proxy with IIS
Assigned cases for initial responses to meet our contractual obligations
- Left 5-10 public facing comments to meet SLA to assist the team
Emailed some devs about whether a customer can run using the latest version of the database which underpins our software
Responded to 3-4 different issues in the Slack for our Consultants on-site with customers
Came up with a PowerShell script to work around a bug for another tech at the behest of our Escalations folks who walked up
Caught up on a case that I'll be covering for next week which has Executive VP visibility (ultimately making things right after the initial tech botched a system)
Personal cases:
- Install problem on a server with FIPS
-- Then get thrown under the bus on a customer facing email about the further issues
-- After bypassing that there was a user rights assignment problem; emailed some devs about why we require it / work-arounds for a locked down government server
- Reload of data problem due to the permissions for the service account
-- On the call discussed:
--- Architecting for high availability
--- Long-term maintenance activity to ensure stability
- Reviewed 2GB of logs for an intermittent issue
- Worked on reproducing a client side bug
- Called / left voicemails / sent emails for 3 customers trying to get a remote session scheduled
- Alleged security vulnerability. Called / emailed the customer asking for more clarity; stood up servers to reproduce and researched how to capture the data needed to confirm
All while constantly monitoring email / 3 slack instances / 1 Microsoft team instance / my queue for fires to put out
In some sense, that's a slew of single things, but it's uncommon for me not to be moving onto the next task as I am winding down the previous one. Nor is the work-flow all in the same vein.
Wow what an incredibly insightful comment! As someone who has worked in support, dev and management I’ve developed practices to mitigate the issues you’ve mentioned - namely rotating devs “on duty” availabe for support tasks and have a dedicated channels for communication where people are not left “talking to the hand” - their words :). But I have never actually thought of it in such a holostic way. Would definitely use it in the future when I’m designing or fixing a company process :)
> Support brains and developer brains are actually not that different.
Others have already commented on this sentence, but I would like to add that the real problem is context switching. For instance, because I know I take too much time switching contexts on my mind, I always have to plan accordingly, like reducing the number of different tasks everyday, or plan some time between very different tasks..
> Support brains and developer brains are actually not that different. I see on HN way too often that developers need space and time to think, but other types of people don't. This is myth that needs to be dispelled and everyone should contribute to uphold boundaries that work for everyone.
I disagree completely. When I am working on a complex problem (just yesterday I was writing a code for non trivial distributed program involving web sockets and multiple channels of communication between several parties), I really need let's say an hour (but it could be more) to "load" the current work in progress implementation into an in-memory model in my head so I can reason about it and continue development. When I have to break this process and deal with something else it completely wastes my time and I have to start from scratch.
This might not apply if I am currently working on some CRUD or other stuff which doesn't require much mental capacity, during those days I can switch in between different tasks easily. But on those other days when I am doing an actual development work involving algorithms and networking I really don't want to be disturbed because I will lose the plot and waste a lot of time.
> Trust that absolutely I want you to have 'flow' time - it's important that you both be and feel productive. Good code from you is good code for me and for the user.
What breaks flow is context switching, which is literally baked into the job description for your average support role. Agents often need to answer questions about multiple/complex products, and who knows if they have access to high quality documentation or internal tools.
In most companies there is actually a separation between development and support. I think it's rare (perhaps in startups) to have support people just be able to come and start chatting to developers or engineers. The usual process is you have to go through the development manager and he/she decides how to further delegate the work. Developers are probably in a sprint already working on features and don't have time for some ad hoc unrelated work. For that there would be a separate "on call" team which would rotate couple of developers in for 2-4 week stints or so and these would not work on any new development but would be available for fixing urgent bugs.
> It's totally OK that a support person's time is variable like this, but it's dangerous when the pairing developers time is untouchable. Pro tip: make ground rules for what developers might be "on-call" or have office hours, have rotating schedules for which developers need to help support teams, have dedicated places where agents can escalate engineering tasks without physically bothering someone.
I agree with this. But I would be careful with too much of rotating as if you just keep moving around engineers from projects they are working on to do different work, projects will get super delayed. Usually if I own a project and work on something, there is only 3-4 people who are familiar enough with the domain to be able to work on this. New developers will need couple of weeks of on boarding time. If you start rotating developers around you will waste huge amount of time as new devs need to be brought up on speed to projects and then they will leave in 2 months so you have to do it again.
You're right, I've seen the type of Orgs in SF where 15-18/hr is the base wage and it's not healthy (for the organization or the people who are working there).
For the most part, I've seen that the type of Orgs with those support wages are likely just trying to throw bodies at support volume. $16/hr for another human to answer X amount of tickets with a Y% satisfaction over Z amount of time. Their customer base is probably B2C or B2B with a large SMB base.
The model is bound to fail, particularly for communication reasons. The type of Org that employs this position is also likely to not have the product feedback loops that connect Support (reactive) with the Product/Eng teams (proactive...hopeuflly). This means product is not addressing bugs quickly or fixing usability issues that support agents frequently work around and explain to frustrated users. It also means they likely don't have adequate internal tooling to solve problems in real-time.
It's a form of technical debt that is REALLY hard to measure - I believe this is because there's too much focus on "standard" support metrics like NPS, FRT, # of touches... Yes these are important, but they are surface level stats for maintaining a basic, "good" support experience. Great support experiences require tighter integration with other teams with better data.
There's no one right answer, but likely a spectrum of options that need to be analyzed for which works best for you.
- Have an international customer base? Maybe outsourcing could be a great option to keep costs low and cover more timezones
- Not interested in outsourcing? Stay in the US and build a new office with talent outside the Bay Area (check out Lyft's Nashville office)
- Do you absolutely need Support to be in HQ? Make the commitment to higher wages and staying lean and effective, not just as a Support team but as 1 company together.
I would also draw a distinction between B2B businesses with Customer Success needs and B2C businesses. Perhaps I should modify the blog post to reflect the assumption that this is basic question-answering support, rather than technical support.
Great layout and design, but honestly how is this much different than Soundcloud? The little things like the history and play queue feature are great, but what would make me want to prefer this to SC, in which I've already curated a big list of people/labels/etc to follow and give me new music all the time? In comparison, this might broaden my horizon every once in a while, but also runs the risk of giving me a lot of tracks I'm not interested in. I think it's going to be important that in the future the user is given some more control and selectivity (in addition to some more social components). Good work.
Thanks checking it out and for your comments! So I definitely don't see this as really replacing Soundclound (also considering that only SC songs are supported ATM so its a subset of whats available on SC). Like you said lots of people out there use SC and have a nice stream of music based on the artists/labels/whatever they follow. This is more for aimmed at discovery and solve a pain point that I had and I don't think the trending sections for EDM in SC is that good.
While I normally use the usual SC/Spotify to listen to things I already know about, there wasn't a good way for me of finding new and perhaps lesser known remixes/artists/tracks. I normally checked a number of blogs manually and that became a hassle. Especially when you can't "play through" the songs on a blog in sequential order because it stops after each song. So I'm aggregating the postings from a number of blogs and other sources together so I can just check one source, play the newest songs, and save the ones I like.
I think you hit the spot when you said broaden [your] horizon, thats definitely one of the key points. The goal is that the feed in The Daily Drop is more varied than your personal SC stream so hopefully you find some new artists/tracks to follow/favorite. And you're also right, I myself also run into songs I just don't like and that I just skip. When building it I tried to add the features that I wanted and what it ended up being was a different features from services that I liked but didn't have in one app (aggregation from Hypem, queue/history from Spotify, shuffle from Spotify/SC, remixes found on SC vs 'mainstream' on Spotify, etc.).
The social and control components are definitely coming in the future when I have the time that will hopefully make it a more compelling product. As well as other genre within the music. (I'm a big hip hop fan too!)
That's great. Yeah, I just wanted to bring forward that I use a pretty slim criteria for when I'm deciding to unfollow an account on SC. Essentially, if that account is not posting or reposting any tracks that I'm interested in for a while, I unfollow them.
So I would hate to see this to you at a larger scale... "Well, Daily Drop isn't posting anything I'm interested in anymore, so I just won't use it". Having more control and options would very much help protect against this. Best of luck!
Definitely +1 on the "view all notes" options. Knowing full well that Ghostnote was intended for people like me that don't necessarily use structure for note-taking and need the context, I don't want to find my self in a position of not being able to find an important note because I'm not looking at that file/URL at that moment.
Great platform. Used this religiously while in college at Davis. Luckily, there was an active community of people updating the pages, which allowed the Wiki to essentially replace Yelp for looking up business info.
That Daviswiki allows for the accumulation of institutional knowledge from the student's perspective is just one of the things that makes it such a valuable resource. I learned so much more about the history and culture of the town and the university than I ever could have using sterile/stale facebook pages or univeristy websites.
