For that exact reason I've had a weekly "emails and chill" date with a supporter. Brought coffee for both of us. I flicked through incoming support emails for 30-40 minutes....
Then it is a product development priority to pick something else, just as you wouldn't pick a bug tracker, version control system, or language runtime that wasn't affordable to let every developer use.
It really depends. The per seat cost for ZenDesk is pretty low; if you have an efficient process, it can be a lot of effort for them. My work's support people are very efficient, so we were processing tons of tickets and bogging down their infra. We ended up building our own ticketing to get the performance we need.
On the topic of reading support email; I think it's important that developers regularly have tickets escalated to them, and regularly hear about the trending issues; but that doesn't mean they need to spend a day in the queue. Processing support email is a skill that needs training and practice to do well; it's not something an engineer can do once a month or a few times a year with good results. Of course, this may depend on the scale of your support queue and of your team; there's a big difference in a few emails per developer per day and thousands per day.
"My work's support people are very efficient, so we were processing tons of tickets and bogging down their infra"
That kind of says it all... There should be no reason support tickets should bog down their infrastructure. We're not talking about millions of real-time transactions here, even in the most popular consumer products. I should expect perfection because it's simply the most trivial product you can build, technology-wise.
Our product www.fwdeveryone.com is designed for this, if anyone is interested. We make it easy to share specific threads within private repositories for your business for these kinds of use cases.
Cost is one issue. Another is that these tools are designed mainly for triaging conversation volume and aren't really designed for PMs, salesfolks, or engineers to extract what they need from historical conversations.
Companies that want to get every team engaged with customer feedback can:
(1) Invest in their own data extraction and pipeline to push conversational info into cross-team dashboard.
(2) Perform or outsource a bunch of research and report on "voice-of-customer" to the rest of the org.
(3) Use active feedback reporting tools like ProductBoard or NomNom to organize (one kind of) customer feedback.
(4) Try passive conversation analysis from new tools like frame.ai (that's me!) or scopeAI
I once joined our support team to talk with one of our clients (I'd written a new bit of functionality and they wanted me there in case they would ask technical questions). It was one of the most eye-opening experiences ever. Our client talk about their clients abusing our software in ways that we as a development team had never even thought about.
EDIT:
On the other hand, I don't think it should be done to create a sense of urgency for developers. They are not going to work better if they also have to worry about each and every emotion that's being displayed in support emails like the example in the article. That's just creating a sense of responsibility in your company by appealing to emotions and guilt.
> Could you elaborate on the kinds of abuse you saw?
In a very broad sense, sure. I don't want this account to be traceable to where I work now, so some details will be changed or omitted while keeping the kind of abuse the same.
We make a website where our clients can make timeslots available to the general public. The length of a timeslot is dependent on how many people the person booking slot intends to bring, as well as some other factors. Whether a person can book at a certain time therefore (partially) depends on how many people they tell our clients they'll bring.
We also made it so that the booker can change how many people will be coming along (for example because of sickness), or, if they are delayed, by how much, so our clients can more fully use all of their available resources.
However, how bookers were often using it, is by saying they'd come alone (if you have a very short timeslot, there's a better chance it's still available), and then change the number of people to how many were actually coming along. Or they'd just book a slot at the start of the day, and then delay it until they were placed on the time they actually intended to come. In both of these cases, they were abusing features which were genuinely needed for the product to work to their own advantage. It was slightly naive of us as developers not to take this sort of behaviour into account.
Every so often (rarely but say once a year or so), we bring some members of dev team along on an install. Its always very very eye-opening for developers to see what 'problems' look like in the field.
Further, something devs miss about installs is the lack of infrastructure you have to deal with (on a new build-out for example). So saying 'Just download latest version X and install on each of the clients' will take 5x longer than it does in comfy office environment since it means: (a) Go to hotel or tether phone and download 1GB file over 3G, (b) Put on USB stick, (c) go to each client, disable all USB restrictions and install new software, re-enable all restrictions (d) do all this while power is being turned off / on because electricians are still working.
That would require developers to think of users as people instead of cattle, and then they might have to accept that the decisions they made because "developer time is worth more than user time" have an actual real-world cost on actual real-world people.
In my experience, such time pressure comes from management, not the developers themselves. This is evidenced by the painstaking effort a dev will go to to make their ultimate experience on a side project.
In other words, users are often sidelined by new feature requests (for other users) rather than a selfish conservation of time by developers.
The priority game is as yet unsolved, unless you can point me to contrary evidence (which I would be eternally grateful for).
Yes, but open source developers are in their vast majority unpaid volunteers gifting their labor to other users, so these users can either accept the gift as it is or not accept and move on. They are not entitled to other people's work and time for free.
To an extent this is true, in the sense that one must consider the opportunity cost. When working on feature A or fixing bug B, I cannot be working on feature X or fixing bug Y. Also, some features might require a disproportionate amount of developer time compared to the time the user saves.
Just the other day I dismissed a feature request from a user which would have saved that user an hour or so doing a particular task. The problem was that it would have taken me over a week to implement and test (it required complex changes), and the user only had to do this task once a month at most. So for now, I couldn't justify the development time vs user time benefit.
That being said, my primary motivation is to enable users, letting them be more efficient and doing things they otherwise couldn't. I love adding features which allows users to spend minutes rather than hours doing a task, or even entirely automating the process. But I must be mindful of the opportunity cost.
Fully agreed. I'll go a bit further: Everyone, especially engineers and PMs, should once in a while actually reply to support emails. As CTO of my previous company, I still found time for large amounts of customer support, and so did one of my cofounders.
It's definitely important IMO for key people to be in contact with the userbase. Get a better look at what people are asking for, feel more directly responsible for both CS failures and successes, etc. And it overall increases the quality of support (rather than put people in CS who have no idea what's going on aside from the script they follow).
Key quote from the article:
> My experience with everyone reading support emails is, that everyone feel an increased responsibility and a sense of urgency to eliminate whatever emails hits your support inbox.
I am always sad when I see people who think doing customer support is beneath them. It's a red flag, IMO.
Even if they do not reply, they should read every support email that comes in for the product/feature they worked/are working on. It is the best way to put themselves in the shoes of the user, and make better software.
I know someone will respond that they don't have time read all of the support emails, but my response would be that getting so many support emails is itself a data point.
While reading the article, I got a feeling that reading support emails is only one step away from answering support emails - and here you are, suggesting just that.
I've seen further steps down this road - if there are engineers already answering support emails, then why do we need support people at all. After all, engineers have better knowledge of technical details and can make changes themselves. No need for intermediaries.
I understand the reasons for having engineers read (or maybe even sometimes answer) support emails, but still I'd be extremely wary of again working for a company that walks this path.
The reason lower-tier support personnel are employed is because someone reasoned that the engineers' time is too valuable. If 90 % of incoming support requests will be escalated to developers, it makes little sense to have extra people whose main task is to create SAP tickets or press "forward" in Outlook.
Another extra perk of making devs handle the support is that they also have the chance to fix the underlying problem. Remember that for an engineer, fixing broken software is always less of a burden than correspondence with customers.
For our on-prem enterprise software, we have two levels before a ticket reaches the dev team. Level one handles RTFM-type answers, and asks for log files (and then provide RTFM answers or engage a dev). Level two handles demos, implementation and architecture guidance, and reproducing more complex bugs. Dev handles the most complex issues that trickle down, and backup when staffing is short (mainly only around holiday weekends).
> Remember that for an engineer, fixing broken software is always less of a burden than correspondence with customers.
Don’t be so sure. Just because you’ve identified the issue or a good fix doesn’t mean the ticket won’t go in the backlog to die a slow death before you’re allowed to fix it.
> While reading the article, I got a feeling that reading support emails is only one step away from answering support emails - and here you are, suggesting just that.
I didn’t get that impression. The article mentioned reading these emails for 30m a week. Going from there to doing tech support yourself as a CTO is...
It seems to me that a CTO doing tech support either understand something I really don’t, or really fails to understand something I do. Superficially, it sounds like the sort of low-level digging around you get from engineers that got the CTO title but never got comfortable with the transition.
Obviously I wouldn't recommend people do full time support if it's not their role, and the larger a company gets the less practical it is especially in the executive roles.
But the attitude displayed in some of the replies is exactly what I'm talking about when I say some people think support is beneath them.
I'd like to add, shadow your customers a year after deploying your product. Engineers often blame the user, but users often end up using peculiar workflows to get around ui issues in your app, specific bugs, or other issues. Also if the user doesn't understand part of your product a year later, you probably should be improving that experience Either within the app or externally by improving documentation and providing training.
After some burn in time, is it really the user who is doing something dumb?
Pay for level 1 positions is indeed not great, but the money is pretty good in companies that value support enough to do it in-house and once you've learned enough to be senior/backline to a whole crew of juniors.
I do agree that the pay does not necessarily reflect the fact that the job is often harder than mere software development: you're basically debugging other people's software in realtime, often while angry people yell at you.
> You stay fresh, learning other people's ideas all the time. This contributes to longevity.
I recently moved from a dev/support combo role to more of a support one, and this really stands out to me. I'm supporting a half dozen solutions currently, and each one consists of a pile of different flavours of the month. I'm learning a ton of new technology to support the solutions, much more so than if I'd stayed on any one dev team.
I built my whole company around this idea. For years, I was the front line support - IMO, its the best thing you can do to improve not only your product but your approach to life. That and having kids.
One thing I always liked to do now is imagine the person who's angry or annoying me is just a 2 or 3 year old. It's much more fun and takes the edge off the situation whatever it might be...
By all means make e.g. Zendesk tickets available on a Slack channel, so people can dip their toes in and see how things are looking.
Don't spam everyone with every support email. You need a ticketing system at least to coordinate work, and prioritization and assignment to get workflow. Don't spam everyone with new tickets in the ticketing system either.
Having a rota of developers who either work directly with support, or on diagnosing and addressing issues that have come from support, is also a good idea I think. Problem areas will filter through from this.
Having all developers always interruptible by support will just slow things down. Interruptions from support often blow away half a day or more worth of development time, from context switching, checking out specific branches etc.
This is one of my favorite things about Amazon's support system. Support has direct access to PMs, developers, customer facing solutions architects and all of these orgs have close connections to the customers as a result. While not everyone has access to the support cases, customer sentiment is conveyed as part of this process and features or bug fixes are quickly roadmapped as a result of customer pain.
The fact that there's someone at the other end of the support channel who actively cares and understands the problem and the customer's voice is being conveyed company wide creates a better experience for everyone.
I have reported and watched maybe half a dozen bugs get fixed on Amazon, starting in 2003 I think. Never even experienced a reply from any other company when trying to report problems over the years.
I think a handful of companies are getting more proactive with security reporting, but everyone still treats the quality of their services and front line support system as an afterthought.
The customers are testers, especially in "break early, break often" scenarios. I wouldn't call them testers to their face, but... operationally, they're part of the loop. Treat them as such. If you're not going to pay for much testing up front, at least treat the real testers (customers/endusers) as part of a process, not as part of a problem.
If, when I reported an issue, and it was determined not to be PEBKAC... loop me in on updates, or followup with questions. I'm happy to try to reproduce issues, or give more details, or whatnot. I'm a user/customer - I want the product/service, and I want it to be better.
Yeah, it's honestly disheartening, but it's great seeing Amazon realize the value that support can play. Even looking at the hiring requirements for some of the positions can give you some insight into why it works as well -- support teams which require it have strict development requirements, and consequently the support engineers
1) know the problem space and can infer what you're trying to do
2) know what it feels like to be blocked by something completely out of your control and feel like you're writing into the aether
It would be great for companies as a whole to start realizing the value that you can bring to your existing customers through this experience, and to recognize that this is another face of your company.
> This is one of my favorite things about Amazon's support system. Support has direct access to PMs, developers, customer facing solutions architects and all of these orgs have close connections to the customers as a result.
This only works if they know how to convey the relevant issues to the right developers properly.
I had some large files on my Amazon Drive (the consumer product) which could never be downloaded via the desktop app, web browser, odrive, or rclone. I had to endure multiple instances of support going through the flowchart, and some promises of conveying my issue to the engineering team only to be met with disappointment.
I never managed to recover those files in the end.
> This only works if they know how to convey the relevant issues to the right developers properly.
100% this. I don't know that it was like this across the company, but the way customer-facing issues were escalated to my group was pretty awful and almost always mishandled. Customer tickets landing in the same queues as host/service auto-generated tickets, bad handoffs and prioritization, devs with no support experience asking for way too much information from non-technical people just trying to use the service. I suppose the first-line support org is to blame in part. Though it wasn't one of the hotter products they offer, it was definitely old enough and nearly foundational to have warranted several more subject matter experts on the support side. Seeing them tout themselves as one of the most customer-centric companies out there was flabbergasting when it came to that org.
Where I work dev team also does the L3 support: we have L1 who can change the password, reboot the computer, we have L2, who know the basics of our app and its surroundings, but if an issue is not obvious to them - here we come!
Who says the ability to "reboot the computer" is avail to the user? (ie. remote RDC connection or a locked down retail POS terminal).
Also, the "real purpose" of L1 tech is to categorize and prioritize incoming calls for further L2 / L3 processing. Knowing "who" needs to handle the call next, and its priority, is usually critical to getting real problems resolved timely.
As a user experience designer the first thing I ask for is access to any and all data available, including support chat system and access to support folks so I can quickly gauge the general level of issues being experienced. It’s just one way to identify possible issues, far in advance of jumping to make any UI changes.
Bill could be all nice, calm, and helpful because he is not sitting there every day taking calls from end users having to actually work according to some metrics and deal with aggravation.
I get a kick out of stories like that but I would wonder about this:
>Bill Gates is being taken on a guided tour of the product support department's new office building, and during his visit, he asks one of the people manning the phones, "Mind if I take this call?"
In particular "Mind if I take this call?".
Mind?
The entire idea of the head of a corporation (such as Microsoft in particular) asking permission in that way as if the employee who works for him would have some reason to object or be offended. As if he is butting in front of him in the line at a store or taking his last 10 minutes on a jetski.
In a certain context it can also be considered patronizing.
Let's imagine someone is doing heavy labor and digging ditches. More appropriate to just say 'let me do that for you'. Rather than 'mind if I do that for you'.
Bill must know it's not a great job to take support calls constantly and deal with the aggravation. No doubt that there are people (like with any job) that like the job and are fine with it. But those are most likely not people that Bill associates with, is friends with, or respects. The contrast between the parties is where the 'patronizing' comes in.
Another example is a Physician in a hospital. If someone is cleaning bed pans and the Physicians says 'let me do that for you' it means one thing. If they say 'mind if I do that for you' it means another thing.
Or it's showing genuine respect for your employee's job, autonomy and skillset, and implicitly acknowledging that you probably aren't going to do as good a job as they would.
"Mind if I take this call?" could easily be met with "would you mind taking the one afterwards? I know who's dialling in and we're just wrapping up a long-running issue"
It's not the employee's desk. It is Microsoft's desk (and Bill is defacto Microsoft) He wasn't in the employee's house. He is using the desk that Microsoft provided for him. He is not 'another guy doing tech support asking to sit in and do a job'.
Unless it is a part of the company culture you signed on for, relationships between employees and employers are never black and white, "We bought this desk and phone, so we reserve the right to come over and just snag it out of your hands whenever we want"
I'm going to be annoyed if a coworker swipes company gear I need to do my job effectively, or gets a headset I'm using all sweaty. And my desk certainly has personal effects which do not belong to the company - which could be anything from family pictures to keyboards to extra monitors.
Maybe there's no reason for the employee to object or get offended, but that also means there's no harm in asking permission since the answer will be yes. And there's harm in not asking permission, even though the answer will be yes. You have a couple of choices:
You can treat your employees like peers to get along with and respect. Even if it's more optical illusion than reality, this can make for happier - and thus more productive - employees.
You can treat your employees like minions to boss around. Not exactly the most motivating of environments for your employees. They could try and make their unappreciative boss a little happier... or they could browse facebook a bit more. And maybe steal a few pens to stick it to the man. Maybe not a big deal for a once-off interaction, but even that sets an example for your managers and their not so once-off interactions with their "minions"...
At Amazon, our team did a day of shadowing tech support calls and it was extremely illuminating. You think you've designed your product to work a certain way, but your message may not be communicated very well to your customers. If it's possible, I would try to get on a support call or support a customer to gain that empathy to really understand what challenges people using your products are having.
A few weeks ago I tried to make a complaint to the national mail service, because they decided the pickup point closest to me was about half an hour from my house, rather than the pickup point that was literally around the corner.
They had an online complaint form, but you were only able to use it on workdays between 0900 and 1600.
They promised feedback within a couple of hours. Even so, I see no reason to limit it in this manner, just tell them you'll to to get back the same day or the first workday...
Oh yeah, that's ridiculous (they won't be getting back to you in a couple of hours after 4 pm). I'm sure it's a result of a institutional momentum, and nothing to do with actually capabilities.
> Now its impossible to email many companies I find. You click on "Contact" and get Twitter, Instagram, Facebook... but not email :(
I did the website for a nonprofit I set up recently.
From past experience leaving a catchall "contact" email address around, we decided to omit a public email address this time because we didn't want it to be harvested and subscribed to random newsletters.
This is why we regularly take developers to customers. It is eye-opening to see on-site that your mobile app with tiny but well-designed buttons doesn't work for registering container positions when the user is in a shaky 90 metric tons weighing machine, handling 30 metric ton containers.
We write software for container terminal and other logistical actors, and seeing the software being used by real users is so incredibly important when designing new screens and workflows, it's baffling to me that developers aren't taken on-site more often.
I think that's valuable, but depends on the organization. At a company I worked at engineering used to go on customer visits, but the "customers" were the executives and managers who make buying decisions and put forth requirements. However, these were not the folks who actually used the product. Their opinion was important (gotta sell it) but it was NOTHING like what we saw in support.
The the few times end users were there, they clearly did not give their honest opinion in front of their bosses. And really even folks giving feedback who use a product are poor at doing son.
But support is where the rubber hits the road and folks actually encounter real issues that they can't solve on their own and create real pain points that will come up.
In my example there were still a lot of issues we'd take back to engineering and they'd say something that amounted to "but they said they don't use it that way" and it was a real chore to get engineering to understand the difference between what an executive asks for / some of the requirements they were given, and what the real user does / needs / asks for. Understandably engineering resources were sometimes irked by this, and support often took the hit politically because of it. It was one of the reasons I got out of support despite getting along with the engineering teams really well.
Yeah, absolutely, we see that all the time as well. We have the benefit that usually we only have to do sales at the executive level, and for everything else we deal with the operations people, which means that if we go for an on-site visit we usually won't meet higher management than operational team leads.
We learned that what executives say and what operation does is not the same thing, which is why we sell our software we say: "We'll fix your problems, but be warned: we won't do it your way", and as long as that expectation is maintained we have very happy customers.
Is this a question of redesigning your visits to incorporate your real stakeholders? There are many companies with management and workers at polar opposites like this. I've seen this tackled by proposing that you offer some on-site support sessions and bring support and engineering along for the event.
Focus on making management at the company feel like they are doing something for their deployment and get more forthright feedback because they can't be in as much control. Establish some direct follow ups, if needed, to primarily tackle the support issues, but ensure the folks who were on-site are part of that conversation. Present a summary of the event back, including action items which you take from the event alongside their pet problems/requests.
I remember back in my sys-admin days, when a vendor would come in, we would 'kidnap' the devs/engineers and keep them in our office, while he C-levels/Directors spent time 'discussing business'.
At the same time we were giving the devs/engineers a taste of what the requirements should REALLY be, or what the problems REALLY were. That gave them a far better idea of what our pain-points were.
It happened that devs/engineers, while in the presence of theirs and the customers' C-levels/Directors, they only smiled, nodded and agreed, which is kinda dangerous as they were forced to agree on insane, intangible, and unfeasible requirements.
At a company I worked at engineering used to go on customer visits, but the "customers" were the executives and managers who make buying decisions and put forth requirements.
Developers should meet the customer organisation to talk to users. If you're not talking to users you're not getting the most useful feedback.
Where I work we often supply software to other software companies, and our UX team goes and visits their customers to get insights about how our products are used.
At the last company I worked at they brought glad handers to take care of the execs while I the "low level tech" went around to people's cubes and spent 2-3 days talking to them, understanding their requirements (usually with NO meetings, just 1-1 after talking with their managers and leads.)
This got me the best feedback I have ever gotten, and I regularly implemented fixes and changes that made the C-levels rave about the product (because their entire staff was so surprised at someone giving a shit.)
I was quite impressed by my head of product's subterfuge, she was incredibly talented.
At one previous employer, I got into some heat for being that "low level tech" that went directly to users' cubes and talking to them directly instead of waiting for stuff to filter up and then back down chains of command. The users were really excited to see some features they had needed for years finally implemented and all it cost them was buying a bored college intern lunch a couple times. The managers were so unhappy with me though for breaking protocol.
That job taught me a lot about what to avoid in a corporate culture, because of how dysfunctional that was that the more actual work I did the worse my reviews got and the more my managers seemed to hate/resent me being on the project. It was a situation I hope never to repeat in my career.
Yeah, going directly to the end user is almost certainly best. The amount of times you find people spend 2 hours of their days on what would be literally a 5 minute fix (my favourite being the select with a thousand options that wasn’t alphabetically sorted) is mind blowing.
And all that just to preserve some egos. Though to be fair, in some cases users do request crazy stuff, you just shouldn’t listen to them and look at what they actually do.
I love finding those high impact, straightforward changes! I support dozens of spreadsheets at work and am the person people call when one breaks.
* Conditional formatting cut a 2 hour weekly job down to under 5 minutes.
* The intern, who was hacking away and learning VBA, spent around 20 hours and was able to automate 4 hours per day of manually retyping info between Oracle and a couple spreadsheets. Would have been about 2 hours if he knew VBA going in, but he learned a ton.
* 2 hours standardizing a spreadsheet format and making a custom macro to shift values by x rows and y columns turned a monthly 2 hour, tedious update task into 2 minutes.
I feel like there are a couple of obvious problems that exist:
- Knowing that such a person exists
- Knowing that the fix is simple
- Knowing that they will have time to look at a thing quickly
I'm a person who will answer any question on any topic if asked, and help anyone with anything if I have the ability to do so. That's because I enjoy doing stuff in general and my long projects aren't meaningfully going to suffer. Counterpoint, the only people pestering me on this are friends / close colleagues and it wouldn't scale.
I reckon that the net benefit of being willing to do that to the company is positive, but honestly I'd do it anyway because sometimes 2 hours hacking on a powershell script is a welcome distraction!
Similar to the "users request crazy stuff", managers of users request crazy stuff based on what they think their users need. Stuff that goes up and down two very different reporting chains (up the users' then back down yours) is almost always going to be some weird telephone game crazily divorced from reality.
"How is the user actually using this software?" is sometimes a weirdly hard question to answer correctly in reporting chains.
Then when those reporting chains get siloed due to budgets and in-fighting and over-complicated "change management procedures" (due to often over-zealous risk aversion, maybe to avoid losing budgets), it's far too easy to find yourself not developing for the actual users but for some ideal "manager-user" that doesn't actually use the app day-to-day (or maybe even at all) and instead believes the map is the territory. (Those that think the issue tracker about the app is the status of the usage of the app, or worse that PowerPoint screenshot demos of the app are all that matters and tells them everything about how the app functions.)
I work at a company where most of our contracts are for larger enterprise businesses and, as a result, we have a training component to our launches.
As much as possible we try to bring a person from Product (dev + design + PM) to be involved in the launch project. The benefit here is that the product team gets direct access to the users. And they get "early access" to the challenges our customers face: in the early days of using a new product, the issues shine very bright compared to later when the users have found a suitable workaround. This has and will certainly continue to be essential to building empathy between the people who build the product and those who use it.
I've worked on several projects where the actual needs would get distorted between the customers and the developers in a perverse game of telephone. Each producer or manager feeling the need to reinterpret as they saw fit.
My most recent job the head of the company had a great comment. One of the first things he told me "Our end users are not smart, no matter what anyone tells you. They can barely use a computer. Remember that."
I HATE that attitude. It may occasionally be right (depends on your product/intended use) but it was the catch all ‘do as I say’ excuse one of the executives used at a previous job.
Have a suggestion on how something could be done better? Your way is too complicated and our users are dumb as posts. So we can’t do it. It’s not worth even thinking about.
Of course if THEY want to do the complicated hard to understand thing, it will be fine.
Just one of MANY examples.
Why do the job if you have actual contempt for your users?
I mean, yes, in retail or the service industry, but it should be possible to find a job in IT where you can at least tolerate the end users (or just never see them altogether).
>Why do the job if you have actual contempt for your users?
It's not contempt, it's understanding who is at the end of the keyboard.
In this case our customers are fairly capable, but the software is really for their end customers who are in a niche industry that is AMAZINGLY behind the times in terms of technology, and the people they hire who actually end up doing a lot of interacting with the software are honestly barely high school grads and are surprisingly incapable / startled by anything out of a very specific routine.
Seconding MBCook here; I believe this advice is nonsense.
Truth is, most people are smart enough. If this is a product for internal use, then they might be also extremely motivated, as it happens when handling some piece of software becomes a key element of keeping a job.
Taking the approach of "our users are dumb" makes sense only when you're not thinking about providing value for those users, and instead you're worrying your product could make the wrong first impression (and probably not on users, but the managers), and thus not get bought. It's a valid priority for business, but it would serve everyone better if people were up-front about it.
I agree, if we assume they're going to try. It's not a perfect world and IMO most people really aren't trying / putting in the effort on the things we think they should. It's not fair, but if they're not going to try, they're still the person behind the keyboard.
> If your user interface is so simple that understanding it doesn’t take any effort at all, that’s a pretty great thing.
Nah, that's an indicator the software is most likely not very useful. Like in code, in user interfaces too there's both essential and accidental complexity. Plenty of the latter to improve on, but reducing essential complexity === reducing features === reducing utility of the software.
> I imagine the hypothetical lazy user thinking ‘I cannot figure out a way to convince my boss that I do not understand this UI...’
I imagine said lazy user asking the boss to buy a training course. If that software is so important for the company, a training course is both useful and cheaper than hiring someone who maybe can learn the software themselves in place of said lazy user. Training courses tend to provide ample opportunity to slack off too, so that's a double win for the lazy user :).
(That said, from personal observations of my wife's and mine, people seem to be split on that somewhat halfway - one half will jump at the opportunity to learn something new and progress at their workplace or in their career, the other half will roll their eyes and ask "why should I bother"? That latter group responds to "because it's that or your job" argument, though.
I've seen many a time where the customer interface contacts believed whatever bullshit that they were peddling internally, and the information we had was essentially completely wrong.
Vendors walk a fine line with these issues. You have to keep the bullshitters happy as they control the money, but you need to get shit done to keep the golden goose producing when sponsors get promoted/fired/held accountable.
> The the few times end users were there, they clearly did not give their honest opinion in front of their bosses. And really even folks giving feedback who use a product are poor at doing son.
Actually I worked over 2 years at a company developing in-house tools. For almost all tools/projects I talked directly to the end-users. 2 observations:
1) users become greedy when it comes to features (especially those users in supervisor/manager positions)
2) there's a tipping point with amount of desired features when users actually start preferring to use the newly developed software instead of a previous solutions
I think when you say users become "greedy" it's that they don't truly understand the depth of the problem they want to solve. It's not that they are in a true definition sense of "greedy", but ignorant about the cost vs benefit analysis. If if was explained to them it would take 20,000 man hours to solve their issue, and then it would put them out of a job, most of them would clam up.
I worked at a first-response call-center company where after each shift, they would go through the records that they processed that shift and manually count the number of high-priority incidents and various other metrics. They did this after each shift, taking about 15 minutes. For the last three years.
After my field visit I took it to the PO and we implemented these metrics in one sprint. With a single click they could print all import metrics about the last shift.
Sometimes when you automate this stuff away, you lose the value of manually reviewing the data. Just seeing a metric isn't the same as reading through the logs and seeing what actually happened.
I think one of the ways working at a startup benefited me the most was having to cover the support lines when our support guy was out. I got to interact directly with many customers and learn how they _really_ used the product, what was confusing, what wasn't, etc.
Once I got two developers to use their software on the live system. As a result, they fixed a few bugs which didn't appear on the dev systems as those were being run with much smaller data sets.
When normal users had to wait 20 seconds for a page, they didn't like it, but it was completely possible that the system just was that slow. But when the developers had to wait 20 seconds they used the time to look up what took so long and found minor bugs which caused the slowdown and fixed them right away.
As a result, the developers asked to be given more opportunities to work with the live system.
Agreed, as a developer, I'm often asking to see the production environment for the users I'm building for. Even if it's a new application it's usually replacing something existing and understanding that is huge.
We did this at Loom (W12) and it was one of the most powerful things we could have done as a team. Internal comms became much more streamlined as a result and it was usually apparent to everyone what we needed to work on next.
When simple (the internet bank) was first getting started, I was in their public beta. Support was handled by the developers. All the engineers had to do rotations on support.
As an engineer, I think I would hate that being a required part of the job. But also as an engineer who works in the banking/transaction processing industry, the support was damn amazing.
A ton of things about the company went downhill as they grew and especially after they were acquired, but the support turning completely crappy was the worst by far.
I started my career in technical support and looking back it was one of the greatest learning experiences.
The Support Team knows the product better than anyone in the company which is extremely valuable if/when you get promoted to another position within the company.
I did the same. Worked in support, moved on to web development. It teaches you so much about understanding and communicating with customers.
I had some conversations recently where I offered my opinion.
"I think this might be a bit complex for the given users who are using this."
"But they want all this information, we're doing it."
A few weeks later end customers are all confused and they're up in arms because they can't figure out how things work because the product threw the kitchen sink at them on one or two pages...
If a user is willing to message you, you can be sure many hundred other users are thinking/experiencing the same thing.
I remember support commenting that lots of users seemed concerned about security (messaging to ask if their files are kept after) and we were removing them, plus it was written in the privacy and terms page.
Finally we put in plain writing that we didn't keep any files, right on the landing page... 40% lift in conversions.
When I was at Square the design team would shadow support staff to learn about the kind of problems people are facing and more importantly how people talk about your products, i.e. what they call things, how they try to explain what's gone wrong, what they did to solve it or how they ended up with the problem to begin with.
It's the closest thing you can come to true realistic user-testing.
Agree 100%. The trouble is, you can't ask everyone to read everything, and it's not always affordable or even possible to give everyone access to the data. Our goal at frame.ai is to help you understand and act on your chats and emails -- everywhere they happen -- by drawing your attention to the conversations that warrant it.
Data are normalized and unified from sources including Zendesk, Intercom, Slack, and Service Cloud. Destinations include manual export, with triggered alert and warehouse sync under development.
In the middle is a layer of enrichment and search-based dashboard prototyping. Enrichment includes "sentiment moments" (wins, issues, risks), conversation cleanup via elastic tagging, and auto-tagging. You can see a peek at some of our research in this area at this blog post: https://blog.frame.ai/learning-more-with-less-1e618a5aa160
Importantly, there's no per-seat charge. We think everyone in the company who can have access should be able to explore customer conversations, visualize them, and export for further analysis and presentation.
I would presume most competent engineers have a pretty good grasp of what is or isn't working. If something doesn't, they probably knew about it already, or at least aren't surprised.
213 comments
[ 2.7 ms ] story [ 179 ms ] threadSimple CRUDs with non-complex infrastructure... that cost a boatload per client.
On the topic of reading support email; I think it's important that developers regularly have tickets escalated to them, and regularly hear about the trending issues; but that doesn't mean they need to spend a day in the queue. Processing support email is a skill that needs training and practice to do well; it's not something an engineer can do once a month or a few times a year with good results. Of course, this may depend on the scale of your support queue and of your team; there's a big difference in a few emails per developer per day and thousands per day.
That kind of says it all... There should be no reason support tickets should bog down their infrastructure. We're not talking about millions of real-time transactions here, even in the most popular consumer products. I should expect perfection because it's simply the most trivial product you can build, technology-wise.
Or use ScopeAI :) (Biased since I work there)
Companies that want to get every team engaged with customer feedback can: (1) Invest in their own data extraction and pipeline to push conversational info into cross-team dashboard. (2) Perform or outsource a bunch of research and report on "voice-of-customer" to the rest of the org. (3) Use active feedback reporting tools like ProductBoard or NomNom to organize (one kind of) customer feedback. (4) Try passive conversation analysis from new tools like frame.ai (that's me!) or scopeAI
https://support.freshdesk.com/support/solutions/articles/227...
EDIT:
On the other hand, I don't think it should be done to create a sense of urgency for developers. They are not going to work better if they also have to worry about each and every emotion that's being displayed in support emails like the example in the article. That's just creating a sense of responsibility in your company by appealing to emotions and guilt.
In a very broad sense, sure. I don't want this account to be traceable to where I work now, so some details will be changed or omitted while keeping the kind of abuse the same.
We make a website where our clients can make timeslots available to the general public. The length of a timeslot is dependent on how many people the person booking slot intends to bring, as well as some other factors. Whether a person can book at a certain time therefore (partially) depends on how many people they tell our clients they'll bring.
We also made it so that the booker can change how many people will be coming along (for example because of sickness), or, if they are delayed, by how much, so our clients can more fully use all of their available resources.
However, how bookers were often using it, is by saying they'd come alone (if you have a very short timeslot, there's a better chance it's still available), and then change the number of people to how many were actually coming along. Or they'd just book a slot at the start of the day, and then delay it until they were placed on the time they actually intended to come. In both of these cases, they were abusing features which were genuinely needed for the product to work to their own advantage. It was slightly naive of us as developers not to take this sort of behaviour into account.
Every so often (rarely but say once a year or so), we bring some members of dev team along on an install. Its always very very eye-opening for developers to see what 'problems' look like in the field.
Further, something devs miss about installs is the lack of infrastructure you have to deal with (on a new build-out for example). So saying 'Just download latest version X and install on each of the clients' will take 5x longer than it does in comfy office environment since it means: (a) Go to hotel or tether phone and download 1GB file over 3G, (b) Put on USB stick, (c) go to each client, disable all USB restrictions and install new software, re-enable all restrictions (d) do all this while power is being turned off / on because electricians are still working.
In other words, users are often sidelined by new feature requests (for other users) rather than a selfish conservation of time by developers.
The priority game is as yet unsolved, unless you can point me to contrary evidence (which I would be eternally grateful for).
In my experience, open source developers are just as bad, if not worse, when it comes to their treatment of users.
>> open source people, who don’t answer to managers, act similarly. Therefore, it seems unlikely to be due to managerial influence.
> well open source is a gift of labor, people shouldn’t look a gift horse in the mouth
What you say may be true, but also irrelevant to the discussion being had.
To an extent this is true, in the sense that one must consider the opportunity cost. When working on feature A or fixing bug B, I cannot be working on feature X or fixing bug Y. Also, some features might require a disproportionate amount of developer time compared to the time the user saves.
Just the other day I dismissed a feature request from a user which would have saved that user an hour or so doing a particular task. The problem was that it would have taken me over a week to implement and test (it required complex changes), and the user only had to do this task once a month at most. So for now, I couldn't justify the development time vs user time benefit.
That being said, my primary motivation is to enable users, letting them be more efficient and doing things they otherwise couldn't. I love adding features which allows users to spend minutes rather than hours doing a task, or even entirely automating the process. But I must be mindful of the opportunity cost.
It's definitely important IMO for key people to be in contact with the userbase. Get a better look at what people are asking for, feel more directly responsible for both CS failures and successes, etc. And it overall increases the quality of support (rather than put people in CS who have no idea what's going on aside from the script they follow).
Key quote from the article:
> My experience with everyone reading support emails is, that everyone feel an increased responsibility and a sense of urgency to eliminate whatever emails hits your support inbox.
I am always sad when I see people who think doing customer support is beneath them. It's a red flag, IMO.
I know someone will respond that they don't have time read all of the support emails, but my response would be that getting so many support emails is itself a data point.
I've seen further steps down this road - if there are engineers already answering support emails, then why do we need support people at all. After all, engineers have better knowledge of technical details and can make changes themselves. No need for intermediaries.
I understand the reasons for having engineers read (or maybe even sometimes answer) support emails, but still I'd be extremely wary of again working for a company that walks this path.
Another extra perk of making devs handle the support is that they also have the chance to fix the underlying problem. Remember that for an engineer, fixing broken software is always less of a burden than correspondence with customers.
Don’t be so sure. Just because you’ve identified the issue or a good fix doesn’t mean the ticket won’t go in the backlog to die a slow death before you’re allowed to fix it.
I didn’t get that impression. The article mentioned reading these emails for 30m a week. Going from there to doing tech support yourself as a CTO is...
It seems to me that a CTO doing tech support either understand something I really don’t, or really fails to understand something I do. Superficially, it sounds like the sort of low-level digging around you get from engineers that got the CTO title but never got comfortable with the transition.
But the attitude displayed in some of the replies is exactly what I'm talking about when I say some people think support is beneath them.
question also works for PMs / devs / co-founders / ...
After some burn in time, is it really the user who is doing something dumb?
- It's harder than development. Green fields are easier.
- It's pretty much a thankless job.
- You are sort of the janitors of the IT world. Not much respect.
+ The money can be pretty good. Because of the above, management usually rewards good support engineers.
+ You are welcomed by those who don't want to do support.
+ You stay fresh, learning other people's ideas all the time. This contributes to longevity.
All things considered, it's been a good career move for me. YMMV.
+ it's one of the easier routes to becoming a literal expert in how to deploy the software.
I do agree that the pay does not necessarily reflect the fact that the job is often harder than mere software development: you're basically debugging other people's software in realtime, often while angry people yell at you.
I recently moved from a dev/support combo role to more of a support one, and this really stands out to me. I'm supporting a half dozen solutions currently, and each one consists of a pile of different flavours of the month. I'm learning a ton of new technology to support the solutions, much more so than if I'd stayed on any one dev team.
Don't spam everyone with every support email. You need a ticketing system at least to coordinate work, and prioritization and assignment to get workflow. Don't spam everyone with new tickets in the ticketing system either.
Having a rota of developers who either work directly with support, or on diagnosing and addressing issues that have come from support, is also a good idea I think. Problem areas will filter through from this.
Having all developers always interruptible by support will just slow things down. Interruptions from support often blow away half a day or more worth of development time, from context switching, checking out specific branches etc.
The fact that there's someone at the other end of the support channel who actively cares and understands the problem and the customer's voice is being conveyed company wide creates a better experience for everyone.
I think a handful of companies are getting more proactive with security reporting, but everyone still treats the quality of their services and front line support system as an afterthought.
If, when I reported an issue, and it was determined not to be PEBKAC... loop me in on updates, or followup with questions. I'm happy to try to reproduce issues, or give more details, or whatnot. I'm a user/customer - I want the product/service, and I want it to be better.
It would be great for companies as a whole to start realizing the value that you can bring to your existing customers through this experience, and to recognize that this is another face of your company.
This only works if they know how to convey the relevant issues to the right developers properly.
I had some large files on my Amazon Drive (the consumer product) which could never be downloaded via the desktop app, web browser, odrive, or rclone. I had to endure multiple instances of support going through the flowchart, and some promises of conveying my issue to the engineering team only to be met with disappointment.
I never managed to recover those files in the end.
100% this. I don't know that it was like this across the company, but the way customer-facing issues were escalated to my group was pretty awful and almost always mishandled. Customer tickets landing in the same queues as host/service auto-generated tickets, bad handoffs and prioritization, devs with no support experience asking for way too much information from non-technical people just trying to use the service. I suppose the first-line support org is to blame in part. Though it wasn't one of the hotter products they offer, it was definitely old enough and nearly foundational to have warranted several more subject matter experts on the support side. Seeing them tout themselves as one of the most customer-centric companies out there was flabbergasting when it came to that org.
(Source, used to eat bananas)
Interesting story!
Also, the "real purpose" of L1 tech is to categorize and prioritize incoming calls for further L2 / L3 processing. Knowing "who" needs to handle the call next, and its priority, is usually critical to getting real problems resolved timely.
This is key. Support people is the ones that talk with customers, and know what's going on. Their experience is key.
In most companies this people is low-pay look-down people, gets tired quickly etc.
https://blogs.msdn.microsoft.com/oldnewthing/20091123-00/?p=...
I could imagine it if it was a grandma or grandpa (or similar, you get the idea)... but then she wouldn't know who Bill Gates was anyways.
>Bill Gates is being taken on a guided tour of the product support department's new office building, and during his visit, he asks one of the people manning the phones, "Mind if I take this call?"
In particular "Mind if I take this call?".
Mind?
The entire idea of the head of a corporation (such as Microsoft in particular) asking permission in that way as if the employee who works for him would have some reason to object or be offended. As if he is butting in front of him in the line at a store or taking his last 10 minutes on a jetski.
Let's imagine someone is doing heavy labor and digging ditches. More appropriate to just say 'let me do that for you'. Rather than 'mind if I do that for you'.
Bill must know it's not a great job to take support calls constantly and deal with the aggravation. No doubt that there are people (like with any job) that like the job and are fine with it. But those are most likely not people that Bill associates with, is friends with, or respects. The contrast between the parties is where the 'patronizing' comes in.
Another example is a Physician in a hospital. If someone is cleaning bed pans and the Physicians says 'let me do that for you' it means one thing. If they say 'mind if I do that for you' it means another thing.
"Mind if I take this call?" could easily be met with "would you mind taking the one afterwards? I know who's dialling in and we're just wrapping up a long-running issue"
"Mind if I..." would be a normal, polite thing to say in such a situation.
Basic human decency always enters the equation
Maybe there's no reason for the employee to object or get offended, but that also means there's no harm in asking permission since the answer will be yes. And there's harm in not asking permission, even though the answer will be yes. You have a couple of choices:
You can treat your employees like peers to get along with and respect. Even if it's more optical illusion than reality, this can make for happier - and thus more productive - employees.
You can treat your employees like minions to boss around. Not exactly the most motivating of environments for your employees. They could try and make their unappreciative boss a little happier... or they could browse facebook a bit more. And maybe steal a few pens to stick it to the man. Maybe not a big deal for a once-off interaction, but even that sets an example for your managers and their not so once-off interactions with their "minions"...
They had an online complaint form, but you were only able to use it on workdays between 0900 and 1600.
Was it an interactive form with immediate feedback? I'm trying to figure out a way to justify hours on a feedback form.
https://imgur.com/KYSOqUn
I did the website for a nonprofit I set up recently.
From past experience leaving a catchall "contact" email address around, we decided to omit a public email address this time because we didn't want it to be harvested and subscribed to random newsletters.
We write software for container terminal and other logistical actors, and seeing the software being used by real users is so incredibly important when designing new screens and workflows, it's baffling to me that developers aren't taken on-site more often.
The the few times end users were there, they clearly did not give their honest opinion in front of their bosses. And really even folks giving feedback who use a product are poor at doing son.
But support is where the rubber hits the road and folks actually encounter real issues that they can't solve on their own and create real pain points that will come up.
In my example there were still a lot of issues we'd take back to engineering and they'd say something that amounted to "but they said they don't use it that way" and it was a real chore to get engineering to understand the difference between what an executive asks for / some of the requirements they were given, and what the real user does / needs / asks for. Understandably engineering resources were sometimes irked by this, and support often took the hit politically because of it. It was one of the reasons I got out of support despite getting along with the engineering teams really well.
We learned that what executives say and what operation does is not the same thing, which is why we sell our software we say: "We'll fix your problems, but be warned: we won't do it your way", and as long as that expectation is maintained we have very happy customers.
Focus on making management at the company feel like they are doing something for their deployment and get more forthright feedback because they can't be in as much control. Establish some direct follow ups, if needed, to primarily tackle the support issues, but ensure the folks who were on-site are part of that conversation. Present a summary of the event back, including action items which you take from the event alongside their pet problems/requests.
At the same time we were giving the devs/engineers a taste of what the requirements should REALLY be, or what the problems REALLY were. That gave them a far better idea of what our pain-points were.
It happened that devs/engineers, while in the presence of theirs and the customers' C-levels/Directors, they only smiled, nodded and agreed, which is kinda dangerous as they were forced to agree on insane, intangible, and unfeasible requirements.
Developers should meet the customer organisation to talk to users. If you're not talking to users you're not getting the most useful feedback.
Where I work we often supply software to other software companies, and our UX team goes and visits their customers to get insights about how our products are used.
This got me the best feedback I have ever gotten, and I regularly implemented fixes and changes that made the C-levels rave about the product (because their entire staff was so surprised at someone giving a shit.)
I was quite impressed by my head of product's subterfuge, she was incredibly talented.
That job taught me a lot about what to avoid in a corporate culture, because of how dysfunctional that was that the more actual work I did the worse my reviews got and the more my managers seemed to hate/resent me being on the project. It was a situation I hope never to repeat in my career.
And all that just to preserve some egos. Though to be fair, in some cases users do request crazy stuff, you just shouldn’t listen to them and look at what they actually do.
* Conditional formatting cut a 2 hour weekly job down to under 5 minutes.
* The intern, who was hacking away and learning VBA, spent around 20 hours and was able to automate 4 hours per day of manually retyping info between Oracle and a couple spreadsheets. Would have been about 2 hours if he knew VBA going in, but he learned a ton.
* 2 hours standardizing a spreadsheet format and making a custom macro to shift values by x rows and y columns turned a monthly 2 hour, tedious update task into 2 minutes.
- Knowing that such a person exists - Knowing that the fix is simple - Knowing that they will have time to look at a thing quickly
I'm a person who will answer any question on any topic if asked, and help anyone with anything if I have the ability to do so. That's because I enjoy doing stuff in general and my long projects aren't meaningfully going to suffer. Counterpoint, the only people pestering me on this are friends / close colleagues and it wouldn't scale.
I reckon that the net benefit of being willing to do that to the company is positive, but honestly I'd do it anyway because sometimes 2 hours hacking on a powershell script is a welcome distraction!
"How is the user actually using this software?" is sometimes a weirdly hard question to answer correctly in reporting chains.
Then when those reporting chains get siloed due to budgets and in-fighting and over-complicated "change management procedures" (due to often over-zealous risk aversion, maybe to avoid losing budgets), it's far too easy to find yourself not developing for the actual users but for some ideal "manager-user" that doesn't actually use the app day-to-day (or maybe even at all) and instead believes the map is the territory. (Those that think the issue tracker about the app is the status of the usage of the app, or worse that PowerPoint screenshot demos of the app are all that matters and tells them everything about how the app functions.)
As much as possible we try to bring a person from Product (dev + design + PM) to be involved in the launch project. The benefit here is that the product team gets direct access to the users. And they get "early access" to the challenges our customers face: in the early days of using a new product, the issues shine very bright compared to later when the users have found a suitable workaround. This has and will certainly continue to be essential to building empathy between the people who build the product and those who use it.
He wasn't wrong ;)
Have a suggestion on how something could be done better? Your way is too complicated and our users are dumb as posts. So we can’t do it. It’s not worth even thinking about.
Of course if THEY want to do the complicated hard to understand thing, it will be fine.
Just one of MANY examples.
Why do the job if you have actual contempt for your users?
To... To get paid, isn't that obvious? Sometimes you have to do what you have to do.
It's not contempt, it's understanding who is at the end of the keyboard.
In this case our customers are fairly capable, but the software is really for their end customers who are in a niche industry that is AMAZINGLY behind the times in terms of technology, and the people they hire who actually end up doing a lot of interacting with the software are honestly barely high school grads and are surprisingly incapable / startled by anything out of a very specific routine.
Truth is, most people are smart enough. If this is a product for internal use, then they might be also extremely motivated, as it happens when handling some piece of software becomes a key element of keeping a job.
Taking the approach of "our users are dumb" makes sense only when you're not thinking about providing value for those users, and instead you're worrying your product could make the wrong first impression (and probably not on users, but the managers), and thus not get bought. It's a valid priority for business, but it would serve everyone better if people were up-front about it.
I agree, if we assume they're going to try. It's not a perfect world and IMO most people really aren't trying / putting in the effort on the things we think they should. It's not fair, but if they're not going to try, they're still the person behind the keyboard.
That's a managerial problem not a technical one, so any technical solution like dumbing down the user interface will almost certainly fail.
I imagine the hypothetical lazy user thinking ‘I cannot figure out a way to convince my boss that I do not understand this UI...’
Nah, that's an indicator the software is most likely not very useful. Like in code, in user interfaces too there's both essential and accidental complexity. Plenty of the latter to improve on, but reducing essential complexity === reducing features === reducing utility of the software.
> I imagine the hypothetical lazy user thinking ‘I cannot figure out a way to convince my boss that I do not understand this UI...’
I imagine said lazy user asking the boss to buy a training course. If that software is so important for the company, a training course is both useful and cheaper than hiring someone who maybe can learn the software themselves in place of said lazy user. Training courses tend to provide ample opportunity to slack off too, so that's a double win for the lazy user :).
(That said, from personal observations of my wife's and mine, people seem to be split on that somewhat halfway - one half will jump at the opportunity to learn something new and progress at their workplace or in their career, the other half will roll their eyes and ask "why should I bother"? That latter group responds to "because it's that or your job" argument, though.
I've seen many a time where the customer interface contacts believed whatever bullshit that they were peddling internally, and the information we had was essentially completely wrong.
Vendors walk a fine line with these issues. You have to keep the bullshitters happy as they control the money, but you need to get shit done to keep the golden goose producing when sponsors get promoted/fired/held accountable.
Actually I worked over 2 years at a company developing in-house tools. For almost all tools/projects I talked directly to the end-users. 2 observations:
1) users become greedy when it comes to features (especially those users in supervisor/manager positions)
2) there's a tipping point with amount of desired features when users actually start preferring to use the newly developed software instead of a previous solutions
Also gives an immediate answer to all these "should we fail gracefully or crash loudly?" arguments.
Just a small failsafe to ensure nobody is nearby.
After my field visit I took it to the PO and we implemented these metrics in one sprint. With a single click they could print all import metrics about the last shift.
When normal users had to wait 20 seconds for a page, they didn't like it, but it was completely possible that the system just was that slow. But when the developers had to wait 20 seconds they used the time to look up what took so long and found minor bugs which caused the slowdown and fixed them right away.
As a result, the developers asked to be given more opportunities to work with the live system.
As an engineer, I think I would hate that being a required part of the job. But also as an engineer who works in the banking/transaction processing industry, the support was damn amazing.
A ton of things about the company went downhill as they grew and especially after they were acquired, but the support turning completely crappy was the worst by far.
The Support Team knows the product better than anyone in the company which is extremely valuable if/when you get promoted to another position within the company.
I had some conversations recently where I offered my opinion.
"I think this might be a bit complex for the given users who are using this."
"But they want all this information, we're doing it."
A few weeks later end customers are all confused and they're up in arms because they can't figure out how things work because the product threw the kitchen sink at them on one or two pages...
I remember support commenting that lots of users seemed concerned about security (messaging to ask if their files are kept after) and we were removing them, plus it was written in the privacy and terms page.
Finally we put in plain writing that we didn't keep any files, right on the landing page... 40% lift in conversions.
Support is a better signal than exit surveys.
It's the closest thing you can come to true realistic user-testing.
Data are normalized and unified from sources including Zendesk, Intercom, Slack, and Service Cloud. Destinations include manual export, with triggered alert and warehouse sync under development.
In the middle is a layer of enrichment and search-based dashboard prototyping. Enrichment includes "sentiment moments" (wins, issues, risks), conversation cleanup via elastic tagging, and auto-tagging. You can see a peek at some of our research in this area at this blog post: https://blog.frame.ai/learning-more-with-less-1e618a5aa160
Importantly, there's no per-seat charge. We think everyone in the company who can have access should be able to explore customer conversations, visualize them, and export for further analysis and presentation.