The goal for any company is to get customers and keep them forever. No, really, it’s that simple. Here’s how all the different departments in a startup like the brand team, lead gen, sales and customer service are involved in creating this long lasting Bradgelina class relationship.
Let’s break this up into the four stages:
Before you talk to someone you have to be personable. Lets think about what makes someone attractive. A good sense of humor. Or tone. Dressing well with the right color palette. The right choice of font. Doing awesome experiential things that people are dying to share. Being authentic without trying too hard.
These are things that will make people feel better in your company. This is is the role of branding. So people know you and like who you are even before you speak to them.
The role of the brand team is to get this right.
Dating (Lead Gen)
Once people like who you are, or what you stand for, you move the next stage of courting.
"Hey remember we met at that industry event with Malcolm Gladwell keynote. I had a great time. Did you?"
This is where you exchange emails and text messages. And of course the follow up with what service you have to offer. You have to be careful not to be annoying.
Is your webinar boring? Make it fun. Are you publishing white papers just to tick a box? Avoid falling into that trap. Do useful things. like a personalized note or video. Keep an eye on the jargon. Dry notes or lead gen emails that sound templated and corporate are a real turn off.
It’s the part of the lead gen team to get the dating part right. Do this well and you will be well prepped to move on to the next stage which is asking the prospect to move in with you.
Sh!tting bricks? You should be.
Asking someone to move in with you is fraught with the fear of rejection. An example of asking someone to move in is getting committment for a pilot. For example a company with 5000 employees may start off of one of it’s 300 seat divisions with your product and see how it goes. This is a great opportunity to check each other out with defenses lowered.
Now here’s the danger. Sometimes companies like to move straight to sales. Which is the cold call. The prospect doesn’t know who you are, but you are asking them to move in with you. This may result in a slap in the face. In some lucky instances, it may result in a one night stand. If you are really popular with a really well known brand, you might be able to skip a lot of the lead gen and get to the sales.
But rarely does it lead to a long term commitment.
Marriage (Customer Service)
This is the really hard part. Now that the dating and the honeymoon phase is over you have to get to the day to day stuff of keeping each other happy and fulfilled in the relationship. There are chores that need to get done. Things that need to get fixed. Why aren’t you responding to my calls about my sync and share issue? Why isn’t the sales engineer responding? You used to call me everyday while we were in lead gen. Are you seeing someone else?
While this stage can feel like a lot of hard work, there’s a flip side where it can be a lot of fun. You have to find new ways to engage with each other. Ask how they are doing? Just out of the blue. fix a problem before it happens.
Sometimes things don’t work out and that ok. A prospect may find another suitor. As long as you have a good personality and are very true and authentic to yourself, you will bounce back and build a lasting cycle of happiness.
Vinit is Creative Director at startup Box.com. He’s is currently working on making Box a great suitor for all of you sexy eligible customers.
Will you feel threatened if a competitor clones your product?
When the folks at Pinterest were asked if they were worried about ‘me-too’ products like Pinspire, they didn’t think much of it. Great brands know that the wannabes like the Samwar Brothers can dress like them and behave like them but customers prefer an original. It’s not unlike worrying if your girlfriend will leave you if someone tries to copy your sense of humor. It aint gonna work.
If a competing startup gets negative press, do you exhibit restrained jubilation?
Small people discuss people. Average people discuss events. Big people discuss ideas. The same applies to startups. If people are gossiping about your competitors, and if it gives you some joy because you feel it’s going to sabotage their chance of success, then you have a very fragile brand. Riding on other people’s failures versus your own strengths is a sign of trouble.
When a competing startup matches your SaaS pricing, will you feel compelled to cut yours?
It’s easy to get caught up in the race to the bottom. The hard part is keeping your prices high through better service and really caring about your customers. That’s a part of branding.
If people ask why you started your company, will you instinctively say ” to get rich”?
While most startup founders have a reason to start their company (mostly to solve a problem they had), some are enamored by thoughts of money flowing in. The promise of cashing out to Google and IPOs. Starting a company to get rich doesn’t inspire co-founders, employees or customers. And certainly doesn’t help with branding.
Branding isn’t about getting a good haircut and wearing nicer clothes. It’s knowing why you are building your product, having a clear well defined mission that users can believe in, building a strong internal culture that you can properly reveal to the world outside your company. Do it and your customer will never leave you for another rich handsome suitor.
Recently I started learning how to write snippets of Ruby code just to see what the fuss was all about. By around lesson 12, I began to understand the strange work habits of coders.
Some coders, like writers, prefer to work alone. They write a draft. They figure out how to improve the draft. They seek help from a few forums but largely, they work in private embracing the struggle.
However, there’s another set—coders who work as a group. Let’s call it “social coding”.
How it works
When a coder writes a block of code (the source code), he places it in a code repository. He’s now the author. The source code is similar to the first draft of an essay. Other coders are allowed to ‘fork’ the repository (download the source code) and play with it. They will notify the author if they believe they’ve made an improvement. Which could mean using a new command (using better words) or refactoring the code (rewriting a paragraph with fewer words). If the author likes what he sees, he will merge the code into his source code.
The author always has the last say on what goes in. He can reject a contribution for any reason.
Sharing is Hard
Now, writers, unlike coders, can be possessive and territorial. Few writers would want other writers mucking around with their prose. Which is precisely why I struggled with coding. Part of the process in the code tutorials (Learn Ruby the Hard Wayby Zed Shaw) requires that you share your code online. I don’t mind a couple of people looking at my code. But just about anyone? I don’t know if I feel secure enough for that sort of thing.
Coders don’t have that problem. They let go. That’s just how they were raised. Weird.
“I think developers are comfortable with sharing since most developers know they’re not the best coders,” says James De Jesus, director of creative development at AKQA. “They approach it with a mindset that things can always be improved, which makes sharing easier since they believe that the badass developer they follow on Twitter might take a look and refactor bits for them.”
While collaborative coding is helpful, it’s also a humbling process.
“Lots of times, the sharing is preceded by apologies about how poorly the code is structured and how hard it is to read,” says James.
But by allowing others to fork their repository, the code gets better and tested for bugs and efficiency. The author also gets to deploy a project in half the time.
Despite the collaborative spirit, developers don’t always want to share the spotlight and are often trying to carve out names for themselves online. Some developers I spoke to said they too, like writers, have an ego about their work. They’ve just learned how to lay aside their ego in favor of seeing their work see the light of day faster. You can’t argue this process has helped put certain web technologies ahead of proprietary closed-source ones. Will it work with writing?
When other coders started forking my repository, I felt uneasy. Then I reminded myself that copywriters were just raised differently. We want to be the lone rangers. We don’t want ten people working on our document. How will anyone know who wrote it? How will we get our next job?
But what if I said, “Okay, I am going to let go. Let’s just see what happens.”
I’d like you to join me in a writing experiment.
RULES (that take inspiration from the world of coding):
Any writer has the permission to pick up this unfinished essay and modify it.
If you make a change, add a comment with a hash tag.
If I like the change you’ve made, I will update it on my original document and list you as a contributor. If I don’t, then you shouldn’t feel bad.
I thought about tracking changes on a word doc but it would quickly begin to look messy. To help with version control (another coder quirk) the essay can be edited on Yammer if you are an AKQA employee.
Let’s see how this essay turns out after a few weeks.
What success looks like:
1. The essay gets better.
2. It gets completed faster than I originally intended.
3. We don’t have arguments over who did what.
This section was added after I stopped accepting contributions during the final week. Which may explain the slip shod writing.
Success was based on three parameters.
Did the essay get better than I originally intended?
Yes. Not only did the prose improve, new ideas were added which enriched the original material.
Did it get completed faster than I originally intended?
No. My goal was three weeks. It took six. Shame. The mistake was I didn’t set a date of publication. Also writers aren’t used to a preposterous idea like collaborative writing. So why would anyone contribute? Contribution trickled in slowly.
Did we argue over who did what?
No. The final tally—Contributors:8 Merged: 5
I didn’t receive any complaints about the way I used contributions. I modified a few I pieces before merging but that was part of the deal, wasn’t it? If you feel treated unfairly, please let me know.
The purpose of the experiment was to test if drawing upon the writing experience of multiple writers could enrich a thought. But who qualifies as a writer? The typewriter turned everyone a writer. Just like Instagram turned everyone a photographer. And Rottentomatoes turned everyone into a movie critic. I sent this out to the AKQA Writers group. But engaged the coders as well. I think as long as the contributor’s pool is well defined, it’s okay to get feedback from non-professional writers. Most people will contribute only if they feel they can improve upon an idea.
Some contributions obviously won’t be right. Since this isn’t a Wikipedia-like exercise, where people insert facts, the onus of structuring an argument (quality assurance) is on the author. The author must keep an eye on tone, voice and clarity of the overall thought.
This type of coder inspired process may work for long copy writing. Essays, press releases, blog posts where there’s space for building an argument. Perhaps someone needs to build a proper github for collaborative writing. Although I don’t think the challenge is building a new app. Right now our writer insecurities may prevent us from embracing the practice in the first place. I’m not even sure if I’m ready. But again, this is the sort of ending that can be improved.
Contributors (Thanks for playing)
James de Jesus
Creative people hate left brain activities. We hate accounting, law, coding, proofreading. As a result the left brain gets atrophied. We fumble around with our calculators when we have to split the restaurant bill. To prevent this, I’ve started some left brain exercises. Since this is the year of code, I decided to learn Ruby.
Most of the code tutorials assume that you have rudimentary knowledge of coding. Even when coders try to explain something they will quickly jump into technical terms like variables and commands.This is typical of engineers. I know because I have an engineering degree (although I wouldn’t call myself an engineer)
As writer, I’m going to break down the learning process in a way a reader can understand. It wont make you a coder but it will help demystify the process.
To get a glimpse into my progress you can follow my github profile: https://github.com/vinitpatil/Learn-Ruby-the-Hard-Way
This series will be called ‘On Coding’ and will be updated weekly.
The Task: Finish this essay and upload it to my blog within 24 hours.
The hard part about doing stuff is getting started. So for this task I make it as easy as possible to get started.
One night prior, I login to my Tumblr account and start a new draft. But I only write the title ‘How I Beat Procrastination’ and stop. I DO NOT shut down the laptop before going to bed. Simply flip down the screen. Put it to sleep. This is important because logging in is annoying. If I forget my password, I may drop the task and do something else like check out the new single topic blog on Tumblr ‘Gyros of the Day’ or ‘Feminist Ryan Gosling’ or…,well lets not get distracted here.
Next morning, when I flip open the laptop, I see the draft page prompting me to begin typing. Five minutes later, I’m done.
I do a quick proof read. Change the title. Hit submit. It’s been 12 hours.
I’ve noticed sometimes people like to talk circles around a problem so they can avoid coming up with a solution.
"F*ck! My email is outta control!
We love to blame email for all our time management screw ups.
We even tried shutting it off for a few hours a day. But that just antagonized the beast even more. And we had to keep checking up on it to make sure things weren’t REALLY getting out of control.
But lets think about what escalated email’s negative energy in the first place. When email was first introduced into our lives as a pup, there were no rules, no discipline. We made up etiquette as we thought fit, to suit ourselves not the recipients. As a result, email got confused.
Email got infused with a lot of repressed unstable energy.
But the good news is, email can be rehabilitated by creating boundaries. Not only for the sender but also for the recipient.
Chris Anderson has taken the first step. It’s going to be a work-in-progress, but let’s get started by signing this charter:
Once we do that email will be calm-submissive and love us back. From the metaphor in this post, you may have guessed that I’m reading Cesar Millan’s Dog Whisperer. If you have a dog, read it. It may just help us solve our email issues.
An employee at Google was frustrated with meeting rooms getting double booked. So he hacked together a device that hung outside meeting rooms and displayed the name and times of meetings througout the day. It updated wirelessly through the online meeting software. Another employee designed and modded a cover for the device.
Cool product launched!
A couple of nerds at Skype
This creative enthusiasm is now reflected in the way engineering workspaces are designed. It’s not dark cubicle farms anymore. They’re bright and airy. With pebble shaped beanie bags. And spiral slides! It’s blowing my mind.
A nerd at Google, Zurich
Ten years ago I would have never imagined these places could be run by engineering nerds.
I know, because I am an engineer by training. I decided to switch careers because I wanted a less rational, more creative day job. Advertising seemed like the right choice. But if I had to do it all over, I’d really have to think about…Wait. What?! Slides? Damn! I’m in!