Put the engineers in trade show booths and make them help with support calls
The conventional wisdom is that developers’ time is too valuable to waste on anything but product development.
Every programmer, engineer, and product developer I’ve ever met will heartily agree. They want to work on products. They want to develop new features. Trade shows? A colossal waste of time! That’s why we hire salespeople.
Pretty much anything other than product development is someone else’s job. Sales engineering? Gimme a break. Customer support? Ohmygod would you really waste a dev’s time telling clueless people to reboot? Quality testing? Are you effing kidding? Hire housewives in Bulgaria to make sure the UI doesn’t break.
True, true, true. If I were running Google or Oracle, I’d have big teams of product development, sales, support, marketing, QA, and everything else. Once a year I’d put them all in the same room, give them some beers, and order them to mingle. (They won’t, of course, but at least I’d be able to claim I tried.)
That’s why big companies suck.
The stovepipes of different responsibilities kind of work when you have a 20 year old product and an established market that won’t change. When nobody expects you to build a new feature, or even fix a critical bug in under a year. When it’s no longer about making the best product but maximizing profits.
But startups are different. And by being different, by being flexible, by building new products that people want and by delighting customers, we can make a difference. We can run rings around those big companies with their rigid departments and reporting structures.
And it starts with our most valuable resource — product developers. By putting them in front of customers, no matter how uncomfortable or a waste of resources that seems, we end up with products that meet actual needs, not what the sales team thinks the customer wants or what marketing says will sell.
What happens when we send a developer to a trade show and make her sit in the booth? The customer starts asking questions about how the product works and whether it has some feature he wants. The salesperson makes up the usual bullshit about AI or magic, or if he’s honest, says he’ll have someone call next week. (Of course, the only person who follows up is another salesperson who doesn’t know anything.)
The engineer listens to the customer and hopefully refrains from saying what’s she thinking — that this is the stupidest request she’s ever heard and she’s glad she doesn’t have to deal with customers every day. Finally, she asks the customer what they actually need to accomplish.
It turns out the product wasn’t designed to do what the customer wants because nobody who understands how to build the product ever talked to a real customer. So they built the product according to the PRD made by the product manager and marketing team.
Now that she understand what the customer really needs, she has an idea. One of the features designed for something else can be repurposed to fit the customer’s request. That evening, she skips the schmoozefest and goes back to her room to code up a prototype.
The next day, when she spots the customer in the exhibit hall, she brings him over to show him a demo. He’s thrilled. Finally, the customer thinks, someone actually listened to me! The sales team books a sale right there.
I saw this same story repeated every day at tradeshows and conferences in 5 different industries. The other booths had nothing but salespeople who didn’t understand what was and wasn’t possible. Had no way to know which feature requests would take a minor tweak of the code and which would require massive re-architecting. Every time I made the engineers talk to customers at trade shows, we ended up with a better product and new uses we’d never considered.
Customer demos, whether online or on-site are no different. Sure, the sales engineers know how to get the product up and running, and have tricks and scripts to make the process faster and easier. What is better, though, is when the engineering team sees exactly where and how the product is installed, and instead of hacks to get it work, rewrites the APIs and UI to make the process smoother.
I hear you thinking — the horror! Letting engineers rewrite the product? Design the UI? We’ll end up with a command line interface with a .txt file for instructions!
So, yeah, the final version needs to be created in collaboration with marketing and UI/UX, but instead of throwing a requirements document over the wall and ordering the engineering team to build it, it can now be a true collaboration where the engineering team provides input into how the product needs to work.
Customer support is no different. When I force the engineers to take support calls, within a day, the product gets rewritten to eliminate the cause of many of the calls. Sometimes it’s bugs, more often it’s a confusing UI or convoluted setup. There’s nothing like an annoyed engineer to make the product better. Support calls aren’t managed by a remote team at a call center, they’re eliminated by improving the product.
These are small issues that the marketing team never thinks about, the sales team never sees, but customers deal with daily. Fix them and you’ll have happier users.
And when there are bugs? Instead of taking 2 weeks to go through escalations, by having a developer take the call, asking the right questions, and replicating the problem, we often had a fix to the customer within an hour.
I used to think customers would get upset by bugs and annoyed that they were asked to help find the problem and test the fix. But it turned out that they appreciated the personal service and the prompt fix far more. We had the happiest customers ever. Add 3 months of free support as apology for the hassle, or send a box of cookies for $ 25 (or a bottle of whiskey if appropriate) as thanks for helping us find and fix our bug, and we had a friend for life.
The same is true for quality testing. The QA team is able to test the most likely things to go wrong, but it’s not the obvious things that usually go wrong — it’s the edge conditions. It’s the handoffs between modules or the kludges that were thrown in to add undocumented features.
If you want to find the problems that customers will eventually stumble upon, you have to challenge the people who know how the code works inside. Who know where the weak spots are. Who know which parts of the code were written by interns or the clueless coder who got fired. You have to make it a contest between engineers to see who can find the most bugs.
Of course, you don’t want your VP of Engineering spending her entire day on rote QA testing, but you do want her doing the last set of tests, trying to find something to break, before shipping a new release. The CEO, too, should do a final check. Just knowing that the people who sign their paychecks also sign off on releases will spur the team to review the code more carefully before checking it into production.
There is a trade-off, of course, of how much time you can dedicate to putting the engineering team into the field, talking to customers, going to trade shows, and answering support calls, instead of developing the product.
My rule of thumb was 20% of the work week was devoted to customer-focused activities. Less while they were preparing for a big release, more right after it came out and we wanted to catch any new problems quickly.
The engineers hated it. They complained it took them away from what they were good it. They said it wasn’t part of their job responsibilities. But they also had pride in our products, and despite the grumbling, understood that our attention to customer needs was what set us apart from the big guys. It’s what gave us the best products with the highest customer satisfaction. It’s one of the keys that made us successful.
As startup founders, it’s easy to hire a bunch of developers, hand them a requirements document and tell them to go off and build it. It’s easy to hire a bunch of sales guys, give them a product spec and tell them to go sell it. And it’s easy to hire product managers, UI/UX specialists, and marketing experts to generate fictional users and journeys.
But if we really want to be successful, we have to connect the people developing the product to the people using it so they can build something users truly need and love.
At SüprDüpr, they’re developing a teleporter to revolutionize transportation. But have they asked users to find out if they’re willing to step inside the contraption? Will their demonstration teleporting an elephant be enough to overcome people’s fears? Find out in the unique award-winning startup mystery novel, To Kill a Unicorn.
