Support Driven Development

Martin H. Normark
Apr 10, 2015 · 3 min read

“I’ve learned more about our product and our customers in the last two days, than I did the entire last year” — me, back in 2009 after doing customer support for two days.

I keep reading in blog posts that very few companies actually know their customers extremely well.

The only reason I did customer support for two days, was because our dedicated support person called in sick and there was no one else to do it. I wasn’t the founder or anything, just a frontend developer.

It very quickly occurred to me that the feeling of our product actually working was an illusion we were stuck in on the inside. We knew our way around the product so we did things just right and just as expected every single time.

We had testers, but they make sure the implementation works, they don’t question if the implementation aligns with the goals of our customers.

It was clear to me that many of the challenges our customers faced would be relatively simple to solve, we just didn’t know about them. At least the engineering team didn’t know about them.

We were shielded.

I remember my early days at the startup as very chaotic. We once had an ongoing issue that restarted the web app at random times, several times a day. Our support guy phones us up and yelled “it just happened again”, and smack down the phone to hang up.

It was unfiltered. We knew something was wrong, and we were working our ass off to find and resolve the issue.

I was regularly called upon by our lead designer to have a look at what I made and was told “I don’t get it. I don’t understand. Where do I begin?”. He wasn’t rude, but he was clear. It was uncomfortable, but it made me feel alive. I was learning.

What had caused this unfiltered feedback to suddenly disappear? I know it wasn’t our customers. Of course they still complained, but something must have changed within the company that caused this feedback to drop dead.

After a (of that time) rather large funding round, the new investors required to hiring of a so called “professional CEO”, one with previous #bigco experience.

That quickly lead to new hiring to the senior management team which aligned with how big companies were structured. We wanted to act big, even on the inside.

It caused the company to be very divided. 25 people, and 5 departments the engineering team being the largest.

At big companies, they do a lot to protect their employees and make a safe and secure environment for them to work. That’s fine if you’re a big company.

But for a pre-profit small company with a product that wasn’t really working as expected, let alone aligned with customer’s need? Toxic!

Instead of giving me and the other engineers unfiltered feedback, the support people solved the customers’ problem by doing it for them. “Send me the files, and I’ll upload them and publish the campaign”.

We thought the product was working, but it was our support staff who was working for our customers.

So much for a safe and secure environment — it was nice to work there, but it sure didn’t result in a great product.

Product Hacking

Building, editing and shipping

Martin H. Normark

Written by

I’m @MartinHN on Twitter. Product and UX Developer. iOS and Web.

Product Hacking

Building, editing and shipping

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade