customer success

How I Moved My Medium Over to

Screen Shot 2016-12-29 at 3.40.56 PM.png
Richard Pryor in the brilliant film, Moving.

I recently decided to part ways with Blogger and Medium.

Blogger has been good to me for many years but it is clearly an un/under-maintained product that I would not be surprised to see shut down any day now. Similarly, while I like some of Medium’s tools, the closed ecosystem and the inability to edit HTML has always bothered me as a person who has been editing her own HTML since GeoCities days. So I’ve had a long overdue TODO to create my own blog.

After interacting with so many magical Automatticians at SupConf, I finally sat down and created this website. It was a fairly simple process and the Happiness Engineers (despite that unfortunate title) were super helpful when I hit weird snags (like the glaring red band at the top of the screen warning me that I needed to Verify something or other). Then came the time to move over my Blogger and Medium blogs and consolidate my longer form digital ruminations.

I searched Google for instructions on the Blogger import and it went over without a hitch.

This is the glaring red band, btw…I was later informed there was nothing I could actually “FIX.” I just had to wait.

So onwards to the Medium import I went.

Failed Medium Import Attempt #1: The DIY

The first instructions I attempted were here.  I was able to easily get the Medium ZIP export, but when I tried to get RSS Importer referenced there, it was nowhere to be found in Happiness Engineer Mariah informed me,

“(You) may have seen something referring to, which is quite different from”

She then went on to tell me that I should see a Medium importer in the list of options. However, I did not. After a long pause, she came back to the chat saying, “There’s a reasonable explanation for that… looks like we can do it for you. ;)”

Failed Medium Import Attempt #2: The 24 Hour Turnaround

Mariah then asked me to upload the Medium ZIP to my WP Media Library but I continued to get the error: “This file type is not allowed. Please try another.” So thinking that the ZIP file format was the problem, I went in and unzipped it with the intent of uploading the .html and image files I thought I’d find there. What I found made me awfully glad I checked.

It turned out that the Medium export was for nearly EVERY character I’d ever typed into Medium.

In addition to what I considered to be “my” blog, it also exported all  the posts I’d written for my company blog, as well as every comment I’d left on everyone else’s blog. Interesting in terms of a data dump but definitely not something I wanted to be vacuumed up and spit out onto my shiny new WP blog.

So once I saw what was in that ZIP, I did a clean up to include only the .html files for the posts that I wanted on my new blog. Once again, I attempted to upload my files to the Media Library and once again I got “This file type is not allowed. Please try another.” When I advised  Mariah of this she asked me to upload everything into a Google Drive folder and send her the link. I did so and she told me I should see the new posts on my blog in 24 hours.

I dutifully waited 24 hours — refreshing every once in a while in case maybe it happened even fast than that. After over 24 hours, I logged back in and reached out to the Happiness Crew.

The Successful Medium Import aka The Longer Slog


The new HE, Chris, confirmed that the import had indeed failed. I told him that I could go in and edit the .rss as well. He requested that I do so and then send the updated Google Drive folder over to I did so and also dropped the link in the chat channel where HE Kristen told me she’d pass it along.

After two days, I’d heard nothing so I wrote to inquire on the matter.

Screen Shot 2016-12-29 at 4.14.41 PM.png

I received a response from HE Richard telling me that the developers were still looking into my import and they couldn’t give an exact time-frame. Two days after that, I did receive a request to rate the quality of service I’d received from Chris. I didn’t know what to say. My issue had not been resolved and that wasn’t one of the three options. So I didn’t click anything.


After seven days of waiting (and seriously considering just copy-pasting the posts into the blog), I went to my blog and noticed a weird post there that I hadn’t created. Upon further investigation, I realized that the import had occurred but I’d not been notified. I wrote HE Richard and told him so, and also asked for more details


I received a response from my old pal HE Chris telling me,

“We had to do a lot of manual work on our end to make it import, so it wouldn’t be something that a user would be able to replicate.”

So it turns out the steps to import Medium blogs to are:

  1. Export your ZIP from Medium.
  2. Edit your RSS and HTML files.
  3. Upload those files to a sharable drive like Google Drive or Dropbox.
  4. Email with a link to that shared drive.
  5. Wait
  6. Nag
  7. Wait

Hope this helps someone avoid some grief.

conferences customer success

My SupConf Experience – Part I

Screen Shot 2016-12-06 at 4.30.35 PM.png

I joined the Support Driven community last year after searching around for groups and newsletters catering to people working in tech support. In the time since I initially signed up, the amazing newsletter and Slack group have come to be an invaluable part of my life and professional development. When I am confused or need a guidance I drop a note in to my peers, who are ever at the ready to answer questions. When I am frustrated, they commiserate with me and drop in appropriately empathetic emojis and GIFS. When I have a big win, they whoop and drop celebratory GIFS.

So last year, when  founder/community manager Scott Tran and his team announced that they were pulling together a new Support Driven conference to be called SupConf, I bravely put together my first ever conference CFP and shipped it off. While I was unfortunately not selected and was ultimately unable to attend, my proposal got me seriously thinking about starting to try and speak at conferences, and after I saw the pictures and read the Slack chatter post-SupConf SF I was resolved to make it to the next one. I think I remarked in the Slack chat that if felt like every one had gone to band camp but me.

So when it was announced that the next SupConf was to be right here in NYC, I got back on the horse, pulled together some better proposals (with the help of some amazing women in tech!) and resubmitted……This time I got in!

While I was beyond excited to get the acceptance email. I was also a bit nervous. This was going to be a room full of hundreds of my peers — people I admired and looked up to. People I really liked in the virtual space and was hoping to connect with IRL.  What could I say? How could I remember it all? And most importantly, how could I avoid being boring or outright embarrassing?

Luckily, Scott and the rest of Support Driven team were already on the case. They had pulled together a speaker development program that set out clear deadlines and concrete requirements, and they gave every speaker an experienced mentor who would hold their hand through the process. I was partnered with the wonderful Pat East (now of GitHub) who was a constant source of encouragement, challenging questions, and (of course) support. I was also able to draw on the expertise of people in the community like Automattic Happiness Engineer Andrew Spittle as well as public speaking expert (and Andrew’s fellow Automattician) Luca Sartoni. My fellow SupConf NYC speakers also shared numerous helpful talks, blogposts, and book titles.

I ended up spending hours upon hours learning as much as I could about the art and science of public speaking (see my resource list at the end of this post), as well as practicing every chance I got. As I went along I began to be so grateful to have been selected to speak not only because I was able to begin to develop myself as a public speaker but also because this time-boxed assignment gave me an opportunity to think and write (and corner unwitting friends and family into conversations) about the topic I’d chosen: responsible time management. I’d long wanted to write a blog post about this topic (as a follow-up to my blogpost on how to quit) and now here I was writing a talk! And being so richly assisted in the process!

So how’d it turn out? Well, in the next post, I am going to tell you about the conference and the actual speaking experience, but for now, here is my list of helpful new speaker resources:



Conference Talks/Videos

customer success

An Ode to The Mall or Towards A Customer Experience for Humans

My name is Camille and I am the world’s most reluctant online shopper. I am a working wife and mom and time to shop can run short, so I Amazon when I must… and I must much of the time. However, whenever I find myself with more than a few minutes on my hands, I love to steal away and browse in a boutique or better yet walk the floors of a big box store. And though I live in New York and have been deprived of the privilege for many a year, no digital experience will ever in a million years match the pure (OK mostly guilty) pleasure of going to the mall.

Yes, I know that malls can be huge and unsightly corporate behemoths that tend to decimate smaller, local businesses and negatively impact the environment with their sprawling parking lots and bulky footprints, but on the other hand the modern mall is a pristine palace of convenience and an egalitarian urban bazaar for our times. It has food and clothes and appliances and sometimes even entertainment. The mall is for young and old. The monied and the poor. The left and the right. Yes, there is truly something — at least one thing — for everyone at the mall! Oh shopping mall, why do I love thee? Let me count the reasons!


How many times have you gone into a mall or big box store for one thing and come out with multiple bags? Sale signs beckon from the window, you need shoes to go with that skirt you just bought, you just want to peek in and check one other little thing….and you’re hooked. Even the best online shops with the fancy schmanciest algorithms cannot do that. While suggestions are fun, they don’t come close to stumbling upon something amazing and being able to get it now.

Instant gratification

If I see something I like at the mall, I can take it and buy it today. No waiting around for some delivery person or dealing with piles of cardboard boxes. The thing you want is in your hand moments after you decided you wanted it. While large online retailers have the benefit of being able to hold a lot more stock than a brick and mortar store, they also have to deal with processing returns because the tiny 350 X 350 image of those jeans didn’t accurately represent what they looked like in person or searching for missing items OR something was lost or damaged in shipping.


A ramp in a mall in Rio de Janeiro, Brasil

For better or worse, the mall is for everybody. Unlike fancy Manhattan boutiques where shop assistants size you up for purchasing power the moment you walk in the door, mall shops invite. If you have the ability to move your body across the threshold, then you are their ideal shopper. Malls are also in many cases shiny new buildings that are required to adhere to accessibility guidelines. While malls are equipped with ramps and lifts, many online retailers still fail to meet even basic levels of site accessibility like clear text and headers.


A recent display in the Flatbush Avenue — Brooklyn College Target store

If you visit your local mall you are certain to be served by a clerk who speaks the local language and dialect and is familiar with the area. While the hugest of the online retailers can certainly provide language localised sites, many smaller web shops struggle to offer their shops in more than one language and can rarely provide customer support in every customer’s timezone. If we don’t speak the languages that the site is offered in, we can see the merchandise and likely even purchase but we are uninformed and underserved, 2nd class shoppers.

A clerk in a mall shop can not only welcome you, chat with you, guide you in and through the store, but can also help you locate other local goods and services. They know the area and can refer you to related shops.

In addition, one branch of an international store has the unique opportunity to provide location specific items. At a recent visit to a Brooklyn Target, I found a large display of New York specific swag. Special limited edition and geographically significant merchandise can be a draw to an otherwise subpar shop or restaurant.


Big greasy pretzels, gooey cinnamon buns that beckon to me from the parking lot, and hot dogs….on sticks! Boy, do you know how to treat a lady, shopping mall. You understand that all that deal hunting means that I am probably going to get a little peckish and want food that isn’t entirely fit for human consumption.

While I don’t (necessarily) believe that online retailers should offer fast food, understanding shoppers as humans is so important. So many times, I’ve been multitasking and online shopping and had a transaction time out because I wandered off or had to go to the restroom. Most mall shops will hold things for you until you get back. Heck, many big box stores even have a layaway policy so you can put an item to the side and come back when you get your money right. A quick Google revealed that even Amazon didn’t have a layaway program.

I understand there are myriad security and business concerns with how long we let sessions run and actually holding physical items for users, but retailers will only benefit by figuring it out. Shopping in the real world is not a straight line, and retailers win when online shopping encourages the same sort of access, speed, courtesy, and service that physical shopping engenders.

So with all that physical shops have going for themselves, what’s an online retailer to do? Just give up and shut down? Of course not, we need them too. However, I would suggest the following:

  • Embrace/ create accessible online shops and platforms
    If you are a smaller online retailer, look into what it will take to make your website more accessible and localised. More on web accessibility standards here ( If you cannot afford the investment, look into sellers’ platforms that can do the work for you but let you maintain your branding. If you are a platform builder, offer accessible platforms that allow sellers to offer unique and localised experiences to potential customers.
  • Build (better) retail into places where people are already browsing
    I spend far too much of my time on Pinterest pinning clothes that and outfits that I like but the path from finding something I want to actually trying to get it has been thus far unsuccessful. Social platforms are certainly trying to hack retail as it is crucial to their revenue strategy, but for some reason they can’t get it right. tries to implement this for Instagram but it is too confusing and high friction.
  • Do brick and mortar whenever you can (but call in the experts!)
    I recently read that Amazon will be opening a few physical locations soon; even the web’s Everything Store has realized that there is value in meeting shoppers where they are. As a retailer, whenever possible, try to position your merchandise where people can touch, try, and buy it. Keep a list of physical retailers on your site and up to date. Do pop-ups until you can afford a physical location. And have excellent customer service and unique offerings that make the in-person experience something truly special and worth seeking out.
customer success

So We Quit Blue Apron (Again)

Image from here

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:

  1. The recipes were creative and introduced us to techniques and dishes we’d never prepared before.
  2. 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.
  3. Less time spent shopping.
  4. 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.

I’m never going back.

Gonna miss that freekeh though.

customer success

Eyes Wide Widened: My ‘Evolving View’ of Developers on Support

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.

customer success

More Will Be Revealed OR Thoughts On Engaging the Less-Engaging Customer

More Will Be Revealed OR Thoughts On Engaging the Less-Engaging Customer

From this XKCD comic

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.

Be Introspective
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.

customer success

Everybody Has One: Dealing With User Feedback

(originally posted on my Blogger blog)

“A mystic isn’t a special kind of person. Every person is a special kind of mystic.” — Brother David Stendl-Rast

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.

Much the same could be said of the work you do and the products you build. The hope for those of us who work in the technology space is that what we make will be more than the sum of a reasonably sturdy database, many lines of code, a handful of API calls, and the latest Javascript framework hanging out front smiling it’s biggest freakiest smile at the world. You hope you’re building something that will matter, that will be used and loved and help people accomplish what they couldn’t accomplish before… or as quickly…or as elegantly. As creators, we, of, course need to get past the ugly MVP phase and we want to be responsive to feedback from our users so we can continue to course correct all throughout the product cycle. For that reason, how we take in that feedback is no trivial matter. In fact, if done without care and process it can have monstrous consequences.

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.

Together we can keep these visions alive!!