My journey with Blue Apron started like that of so many other people: with a free box of food from friends. We liked it immediately for many reasons:
The recipes were creative and introduced us to techniques and dishes we’d never prepared before.
The ingredients were very fresh and interesting. While we live in a city with many exotic options, our neighborhood has exceedingly slim pickings in the grocery stores outside of basics and ingredients to make Caribbean food.
I unpacked my freekeh and scallops and black rice with utter glee.
Less timespent shopping.
Less emotional labour spent trying to figure out what in the world to cook. We don’t ever order food in and very rarely go to restaurants so every day requires that we cook something or have something cooked that we can warm up. When I first started with Blue Apron, I was a fairly new mom and so I was pretty exhausted with work and baby care, so being able to have everything I needed to make a meal was a real convenience.
Why We Quit The First Time
The first time I cancelled with Blue Apron, I didn’t really want to quit. My family had a change in our financial situation and Blue Apron felt a luxury we could no longer afford. It was with a heavy heart that I pressed the Cancel button and said goodbye to those handy little boxes. However, when our tides began to rise again I quickly and excitedly resumed our service, but things were not to be the same….
Why We Quit The Second Time
A lot seemed to have changed from my first excursion on the SS Blue Apron. The recipes started to feel repetitive and not worth the price. The packaging seemed to have ballooned (I don’t need a two sheeter about the history of lemons! Nor do I need a letter from the company every week or even a physical recipe printout. Just email it!) with so much of it being so incredibly not recyclable (despite their claims to the contrary). Meat packages arrived leaking blood all through the box and ingredients were curiously mislabelled or missing. My kitchen was scattered an increasingly overwhelming amount of tiny portions of basic ingredients that I actually already had on stock (vinegars, onions, garlic, soy sauce). But the worst part was that it seemed impossible to figure out how to give feedback on any of this.
Whereas in the past, I’d emailed customer service and received cheery answers, now I could not quite figure out how to reach anyone at all. I tweeted at them a few times and received no response. So I figured it was time to call it a day. But even canceling proved to be an ordeal. I had to click a button and then….WAIT for this.
I had sincerely hoped that I’d receive an email from someone on their customer success team asking me to give them another try or see if there was any issue I could resolve. Instead I received this ugly, generic email basically saying “Bye, Felicia”, as though I hadn’t spent thousands of dollars and referred countless friends to them. If there is a lesson in how NOT to treat customers, Blue Apron has aptly taught it to me. As a Customer Success Lead, I can at least be grateful to them for that.
Having had a bit of a traumatic experience at a previous job, I came to my position as Customer Success Lead with a firm opposition to having any of the developers on the team respond directly to customer feedback. My concerns about devs on support (also known as All Hands Support) were manifold but boiled down to three high-level worries:
My Three Main Reservations About Devs on Support
Communication Style: The guys on my team are all wonderful fellows but for the most part they don’t do a lot of customer-facing work. So I was naturally concerned that they would not be able to craft an email that hit the right balance of attentiveness and concern. Also, to be honest as a woman, we are (for better or worse) often trained to do this kind of emotional labor and to be protective about letting men do it.
Time Suck: The developers here at Clubhouse were hired for a myriad of reasons but chief among them was the fact that they could and would write code and accelerate the development of our product. I’ve seen developers at other organizations go down major rabbit holes dealing with (sometimes minor) support tickets and feared that could happen here.
Timeliness and follow through: I knew that even when my team did a great job communicating with users and managing their time, they still were likely to just let tickets fall through the cracks, since (again) support was not their primary responsibility. I’ve seen this work poorly with other — much larger — teams, and so I was naturally worried.
Why Devs on Support Has Been Worth It Anyway
Scale: We are a small but growing company and more people on support increases our ability to quickly and effectively service our ever-increasing user base. It also frees me up to do more, since my role as Customer Success Lead includes not only support but documentation, customer development, UX, sales/marketing, and product management.
Real-World Use Cases: Responding to tickets has exposed the developers to more people who actually use our software and their real-world concerns in a way that has often been more effective than me just telling them about it. Talking with users about challenges they encounter has definitely helped the devs make decisions about how best to implement certain features.
The Quick Fix: Assigning tickets about a particular feature to the person who built that feature means that you can oftentimes get a speedy fix for any bugs related to the feature. Directing real user feedback to the person who built it can also give them a get a better sense of how it is playing out “in the wild” — which parts work well, which are confusing/disliked.
Easier Access: Since the boss told everyone they would be responding to support tickets, everyone now just understands that support is part of their job here at Clubhouse. I no longer have to feel like I am “bugging” the developers by asking them to look at a support ticket-related issue. It’s not a bother, it’s something we are working on together.
How I Make Devs on Support Work For Us
Process: Before we onboarded all the devs onto support, I created a process doc and directed everyone to it. I also told them to feel free to ping me if they ever had any questions about how to respond to a ticket. At the start, many of them sent me draft responses to review just to make sure they were on the right track. 9 times out of 10 the responses were spot on, but I think that process made me much more comfortable “loosening the reins”.
Oversight and Ownership: As part of the above-mentioned process, I maintain the responsibility of assigning tickets. Every once in a while, an urgent ticket will come in and some one will grab it before I can assign it to them, but even then I go in and make sure it has been correctly categorized. I also keep an eye on responses and make sure tickets are closed in a timely manner.
Avoiding the Time Suck: Every once in a while, a dev *does* unfortunately go down the rabbit hole. A user asks for a feature that should be “easy” to implement or reports a bug that the developer can not replicate but is eager to diagnose and fix. Tickets go back and forth, time ticks away and it just feels like the wrong use of time. In these cases, I will talk to the developer to see if we can manage expectations by thanking the user for their feedback or bug report, creating a ticket in our internal Clubhouse (linked to the Zendesk ticket), and letting the user know we will get back to them when we have an update.
Engagement Guidance: I’ve found developers to have an enviable commitment to building and fixing, but oftentimes customer support is more about listening and learning (more on that here). In guiding developers on support, I will sometimes suggest that they ask more questions before they touch any code. Sometimes the user just wants to hear from us, find out what we’re thinking/planning, and better understand how our product works. Oftentimes, I will just take those kinds of tickets myself, but I think it’s important for the developers to pick up a few of those themselves and deepen their understanding of our user base.
Conclusion: It Works If You Work It
While this experience has opened my eyes, there are many ways it definitely could have gone awry and many situations in which it would have been slightly less than ideal. If we were an org that did KPIs or any time tracking, having devs on support might not have worked for us since they don’t always jump right on tickets and even when they do, they have a tendency to either sit on them for longer than I would or just forget to close them out. Also, if we had no documented process or if I failed to maintain ownership of all the tickets in our Zendesk, it might have been tough going. That said, we need to be mindful of a few things if we want this to continue to work for us.
Iterate and Educate: As our user base grows and our product changes, our documented support process will need to evolve. We will need to continue to train new developers on support about the process as well as potential rabbit holes. Bugs should be documented and triaged but not all bugs can be or even need to be fixed right away. It will be important to keep an eye on when and how bugs get tackled as things scale up.
Some Hands on Deck: Just because we have some developers on support doesn’t mean all of them need to be on board. We are strategic about who on the team is assigned to support, and I am strategic about when and to whom I assign tickets. I aim to strike a balance between effectively addressing our users’ concerns and making sure we can still devote the majority of our time to developing our product and our business. As we grow, I’m open to cycling team members on and off as necessary.
Try Not to Micro-Manage: Using the backchannel is useful when I want to give feedback or suggestions, but I like that our responses aren’t canned (for example, our Australian dev calls everyone “mate” in his responses). I want to make sure I continue to guide without stepping on anyone’s toes.
Having developers on support can absolutely work, but you have to be:
– strategic about who/how you assign
– prepared to manage/support the developers, and
– committed to owning (and iterating on) the process.
More Will Be Revealed OR Thoughts On Engaging the Less-Engaging Customer
I recently received a very blunt and critical email from a customer. He was unhappy about a marketing email we sent out and critical of the company in general. Now, as Customer Success Lead, I work at the intersection of customer support, user experience, and customer development with some sales and marketing responsibilities rolled up there too (because hey we’re a startup!), but despite my many hats, I’ve become much more accustomed to dealing with feature requests and suggestions (thoughts on that here ) and not as adept at taking outright criticism. Fortunately, I’m familiar enough with customer development methodology at this point to know that there is often more beneath the surface of a simple user comment or request. So in this case, I responded to the customer by:
1) Showing appreciation for the feedback
2) Revealing the assumptions that were at play internally when we created the marketing email (e.g. People hate receiving “salesy” marketing emails and would prefer informative ones instead)
3) Conveying what response we’d hoped to receive with the email (e.g. We were looking to start a larger a dialogue about the business/process of software development)
4) Asking what sort of emails/communication the user *does* like to receive from a company like ours.
Much to my surprise, the user responded rather quickly and with a markedly changed tone, offering considerably more constructive feedback. Despite the fact that he claimed to hate the email, I ultimately got the dialogue I was looking for!
As I settle into my position, I am experiencing ever more of these sorts of exchanges — ones with biting and “off the cuff” beginnings that eventually finish as thoughtful conversations, full of great and useful ideas. While certain customers can come off as blunt, cynical, or entitled upon first contact, those same customers can also (with further engagement) prove to be highly intelligent, creative, and thoughtful. Even after several years of working alongside software developers, project managers, and tech leads, I am still learning valuable lessons about how to engage and turn an unpleasant exchange if not into something pleasant than at least into something productive. Recent lessons include:
Meet Users Where They Are
Whenever possible, it is useful to thank the person for taking the time out of their day to reach out you. They could have kept their opinion to themselves and honestly many users do. So this could be the viewpoint of scores more who just couldn’t be bothered to write you.
Affirm the person’s opinion. That is what they think and they have a right to think that way. You just want to know, “OK. So, what else?”
Customer Success Not “Happiness”
As I mentioned in a previous post, while we are working to build solutions that serve an ever growing number of users, we don’t need to blindly accommodate or people-please. We will never make all the users happy and that shouldn’t be our goal.
What is your company doing? Are you accomplishing what you set out to accomplish or is this critique hitting a sore spot and reminding you of something you realize you need to fix/do/be? I find it is crucial to internally be honest about your company and your competitors, especially those who might be doing a better job than you at providing the same sort of product or service. It can also sometimes be beneficial to remind customers that you are aware of your competitors and know that Brand X does this better than we do at the moment.
Customer Success is not just about fixing the brokenness, it’s about learning what is still/already working…even if it is a competitor’s product or service or even a user’s hack.
It’s Not Me, It’s You
Sometimes people are grumpy or don’t know what they want or just want to vent. Listen politely, ask questions as you can, but don’t feel that you need to do or fix anything right away. While you are not there to be anyone’s therapist, if you *can* connect to the person and their frustrations you will gain valuable insight into the work and personal challenges some users may be facing.
Zero Tolerance For Abuse
All this having been said, it is important that your company not tolerate abuse. If a person is being offensive, hurtful, or threatening, you should have every right to walk away. While engaging the less-engaging among your user base can be useful it is not always useful.
Look at you. You magnificent thing. You are not just the sum of ears and nose and skin and bones and teeth…. You are an inspired being…at least on your best days. You have things that motivate you at work, at home, in the world. You have a vision for who you want to be to your friends, to your co-workers, to your family, and as a citizen in your physical and digital communities.
So I wanted to share a few tips on how to receive and respond to Product feedback.
First Of All, If It’s Broken Fix It
So they found a bug. Yes, these things happen to the best of us. This should go without saying but if something doesn’t work. Just fix it. The speed at which you fix it is up to you and your team but if something isn’t working the way you intended it to, then you should probably just fix it.
Beware of “People Said” or “Our Users Said”
How many people does it take to turn a feature request into a product requirement? 2? 50? 100? 1 if it the person is a really powerful and monied customer? It’s important to figure out that number and how you will weight and respond to feedback as well as the value of the feature. Implementing a feature or letting one really squeaky wheel get all the grease can make the whole effort run off the rails.Which people said what and when? How big of a deal is it really?
Have (And Continue To Iterate on) A Roadmap
What is the vision for your org? Your product? How and where is it articulated for your employees. Do your devs know what and where it is? Nevermind whether they care.
This vision for where you are trying to go and/or who (you hope) you are being and what (you hope) you are doing is hopefully clearly typed out somewhere and is given legs through your roadmap, which should be a living breathing document that all the team can access and have some input on.
While not set in stone (see: bug fixes, market forces, new! hotness!) that document should be your guide. Our intrepid devs should be allowed and even encouraged to tinker, but it is helpful to reiterate priorities. How does this align with what we’ve said we really want to do/ be doing? Revisiting that question is crucial, because you really don’t want to get hung up implementing something that you don’t wanna do but then feel you *have to* do because someone spent all weekend hacking on it and now it’s built and it looks like it works. Is this something you *really* want or need or is it just something that can exist in a feature branch and visited at a later date?
Your Backlog Is Not Your Roadmap
Oh, the backlog! Depending on how well your backlog is managed, it can either be Easy Street or a Boulevard of Broken Dreams. A jumble of half-formed ideas and rambling fever dreams. I can’t stress enough that your roadmap needs to be more than a shoving together of Stuff We Didn’t Do Yet but rather a cleared out path of Where We Want To Go. Your roadmap can certainly be stored in your project management tool but it is not just an export of The Undone.
Don’t Just Say Thank You
So you know better now. You aren’t going to just let your product be a plastic bag blowing in the wind of customer whims. You have a vision and you’re going to stand up for it! So how *do* you respond to product feedback/feature requests then? Do you dash them off with a one sentence email and a thank you? Well, I certainly hope not. In her excellent book, Lean Customer Development, Cindy Alvarez suggests asking users:
“ If you had (requested feature) today, how would that make your life better?”
I also like “Can you tell me more about how (highlighted issue) is a blocker for you?” as well as “How are you working around the lack of (requested feature)?” Product feedback and feature requests give us awareness of a potential issue. Asking a question like one of the above gives us understanding. Only after we have awareness and understanding should we feel equipped to chart a course of action. Springing into a flurry of whiteboarding and keytapping can be perilous without stepping back and truly finding out what the user is trying to accomplish and why.
Get Customer Success Feel like you don’t have the time or bandwidth to tackle the growing pile of feedback and feature requests? Well then I highly suggest you engage your customer success manager/ team! Don’t have a customer success person/team? Well then I highly recommend checking out this post from the excellent Support Driven blog to get your awareness and understanding of this crucial role at the intersection of product development, customer support, account management, and user experience.