If you ever wanted to start your own tech company, and you wanted to get a taste for the “real deal”, then this is your book. It’s a no-B.S. business and entrepreneurship book from the founders of Basecamp about starting a company. Highly recommended.
Date Finished: 01/06/2013
Here’s a link to the Amazon page.
Having an enemy
Sometimes the best way to know what your app should be is to know what it shouldn’t be. Figure out your app’s enemy and you’ll shine a light on where you need to go.
One bonus you get from having an enemy is a very clear marketing message. People are stoked by conflict. And they also understand a product by comparing it to others. With a chosen enemy, you’re feeding people a story they want to hear. Not only will they understand your product better and faster, they’ll take sides. And that’s a sure-fire way to get attention and ignite passion.
The less your app is a chore to build, the better it will be. Keep it small and managable so you can actually enjoy the process. If your app doesn’t excite you, something’s wrong. If you’re only working on it in order to cash out, it will show. Likewise, if you feel passionately about your app, it will come through in the final product. People can read between the lines.
American business at this point is really about developing an idea, making it profitable, selling it while it’s profitable and then getting out or diversifying. It’s just about sucking everything up. My idea was: Enjoy baking, sell your bread, people like it, sell more. Keep the bakery going because you’re making good food and people are happy. –Ian MacKaye, member of Fugazi and co-owner of Dischord Records
A lot of small companies make the mistake of trying to act big. It’s as if they perceive their size as a weakness that needs to be covered up. Too bad. Being small can actually be a huge advantage, especially when it comes to communication.
Small companies enjoy fewer formalities, less bureaucracy, and more freedom. Smaller companies are closer to the customer by default. That means they can communicate in a more direct and personal way with customers. If you’re small, you can use familiar language instead of jargon. Your site and your product can have a human voice instead of sounding like a corporate drone. Being small means you can talk with your customers, not down to them.
There are also advantages to internal communications at small companies too. You can ditch formalities. There’s no need for arduous processes and multiple sign-offs on everything. Everyone in the process can speak openly and honestly. This unfettered flow of ideas is one of the big advantages of staying small.
The big idea
Explicitly define the one-point vision for your app. What does your app stand for? What’s it really all about?
Before you start designing or coding anything you need to know the purpose of your product – the vision. Think big. Why does it exist? What makes it different than other similar products?
This vision will guide your decisions and keep you on a consistent path. Whenever there’s a sticking point, ask, “Are we staying true to the vision?”
Your vision should be brief too. A sentence should be enough to get the idea across. Make the big decision about your vision upfront and all your future little decisions become much easier.
How often have you found yourself stuck on a single design or code element for a whole day? How often have you realized that the progress you made today wasn’t real progress? This happens when you focus on details too early in the process. There’s plenty of time to be a perfectionist. Just do it later.
Don’t worry about the size of your headline font in week one. You don’t need to nail that perfect shade of green in week two. You don’t need to move that “submit” button three pixels to the right in week three. Just get the stuff on the page for now. Then use it. Make sure it works. Later on you can adjust and perfect it.
Details reveal themselves as you use what you’re building. You’ll see what needs more attention. You’ll feel what’s missing. You’ll know which potholes to pave over because you’ll keep hitting them. That’s when you need to pay attention, not sooner.
Wasting time on problems you don’t have
People often spend too much time up front trying to solve problems they don’t even have yet. Don’t. Heck, we launched Basecamp without the ability to bill customers! Since the product billed in monthly cycles, we knew we had a 30-day gap to figure it out. We used that time to solve more urgent problems and then, after launch, we tackled billing. It worked out fine (and it forced us into a simple solution without unnecessary bells and whistles).
Don’t sweat stuff until you actually must. Don’t overbuild. Increase hardware and system software as necessary. If you’re slow for a week or two it’s not the end of the world. Just be honest: explain to your customers you’re experiencing some growing pains. They may not be thrilled but they’ll appreciate the candor.
Bottom Line: Make decisions just in time, when you have access to the real information you need. In the meanwhile, you’ll be able to lavish attention on the things that require immediate care.
Finding the core market
The customer is not always right. The truth is you have to sort out who’s right and who’s wrong for your app. The good news is that the internet makes finding the right people easier than ever.
Focusing on a core market also makes it much easier to spread the word about your software. Now that we have a tightly defined audience, we can advertise where they frequent online, publish articles they might find interesting, and generally build a community around our product.
In the beginning, make building a solid core product your priority instead of obsessing over scalability and server farms. Create a great app and then worry about what to do once it’s wildly successful. Otherwise you may waste energy, time, and money fixating on something that never even happens. Believe it or not, the bigger problem isn’t scaling, it’s getting to the point where you have to scale. Without the first problem you won’t have the second.
The best software has a vision. The best software takes sides. When someone uses software, they’re not just looking for features, they’re looking for an approach. They’re looking for a vision. Decide what your vision is and run with it.
And remember, if they don’t like your vision there are plenty of other visions out there for people. Don’t go chasing people you’ll never make happy.
Building half a product, not a half-ass product
Beware of the “everything but the kitchen sink” approach to web app development. Throw in every decent idea that comes along and you’ll just wind up with a half-assed version of your product. What you really want to do is build half a product that kicks ass.
Stick to what’s truly essential. Good ideas can be tabled. Take whatever you think your product should be and cut it in half. Pare features down until you’re left with only the most essential ones. Then do it again.
Start off with a lean, smart app and let it gain traction. Then you can start to add to the solid foundation you’ve built.
Making features hard to implement
Make each feature work hard to be implemented. Make each feature prove itself and show that it’s a survivor. It’s like “Fight Club.” You should only consider features if they’re willing to stand on the porch for three days waiting to be let in.
That’s why you start with no. Every new feature request that comes to us – or from us – meets a no. We listen but don’t act. The initial response is “not now.” If a request for a feature keeps coming back, that’s when we know it’s time to take a deeper look. Then, and only then, do we start considering the feature for real.
And what do you say to people who complain when you won’t adopt their feature idea? Remind them why they like the app in the first place. “You like it because we say no. You like it because it doesn’t do 100 other things. You like it because it doesn’t try to please everyone all the time.”
The price of new features
Even ifa feature makes it past the “no” stage, you still need to expose its hidden costs. For every new feature you need to…
- Say no.
- Force the feature to prove its value.
- If “no” again, end here. If “yes,” continue…
- Sketch the screen(s)/ui.
- Design the screen(s)/ui.
- Code it.
- Test, tweak, test, tweak, test, tweak, test, tweak…
- Check to see if help text needs to be modified.
- Update the product tour (if necessary).
- Update the marketing copy (if necessary).
- Update the terms of service (if necessary).
- Check to see if any promises were broken.
- Check to see if pricing structure is affected.
- Hold breath.
Building something you can manage
Don’t force conventions on people. Instead make your software general so everyone can find their own solution. Give people just enough to solve their own problems their own way. And then get out of the way. Do the best job you can with the root of the problem then step aside. People will find their own solutions and conventions within your general framework.
Forgeting feature requests
Customers want everything under the sun. They’ll avalanche you with feature requests. Just check out our product forums; The feature request category always trumps the others by a wide margin.
So what do you do with all these requests that pour in? Where do you store them? How do you manage them? You don’t. Just read them and then throw them away.
Yup, read them, throw them away, and forget them. It sounds blasphemous but the ones that are important will keep bubbling up anyway. Those are the only ones you need to remember. Those are the truly essential ones. Don’t worry about tracking and saving each request that comes in. Let your customers be your memory. If it’s really worth remembering, they’ll remind you until you can’t forget.
Asking people what they don’t want
Most software surveys and research questions are centered around what people want in a product. “What feature do you think is missing?” “If you could add just one thing, what would it be?” “What would make this product more useful for you?”
What about the other side of the coin? Why not ask people what they don’t want? “If you could remove one feature, what would it be?” “What don’t you use?” “What gets in your way the most?”
More isn’t the answer. Sometimes the biggest favor you can do for customers is to leave something out.
Working in iterations
Don’t expect to get it right the first time. Let the app grow and speak to you. Let it morph and evolve. With web-based software there’s no need to ship perfection. Design screens, use them, analyze them, and then start over again.
Instead of banking on getting everything right upfront, the iterative process lets you continue to make informed decisions as you go along. Plus, you’ll get an active app up and running quicker since you’re not striving for perfection right out the gate. The result is real feedback and real guidance on what requires your attention.
From idea to implementation
Here’s the process we use to Get Real:
Come up with ideas. What is this product going to do? For Basecamp, we looked at our own needs. We wanted to post project updates. We wanted clients to participate. We knew that projects had milestones. We wanted to centralize archives so people could easily review old stuff. We wanted to have a big-picture, bird’s-eye view of what’s going on with all our projects. Together, those assumptions, and a few others, served as our foundation.
This stage is not about nitty gritty details. This is about big questions. What does the app need to do? How will we know when it’s useful? What exactly are we going to make? This is about high level ideas, not pixel-level discussions. At this stage, those kinds of details just aren’t meaningful.
Sketches are quick, dirty, and cheap and that’s exactly how you want to start out. Draw stuff. Scrawl stuff. Boxes, circles, lines. Get your ideas out of your head and onto paper. The goal at this point should be to convert concepts into rough interface designs. This step is all about experimentation. There are no wrong answers.
Create HTML screens
Make an html version of that feature (or section or flow, if it’s more appropriate). Get something real posted so everyone can see what it looks like on screen.
For Basecamp, we first did the “post a message” screen, then the “edit a message” screen, and it went on from there. Don’t write any programming code yet. Just build a mock-up in html and css. Implementation comes later.
When the mock-up looks good and demonstrates enough of the necessary functionality, go ahead and plug in the programming code.
During this whole process remember to stay flexible and expect multiple iterations. You should feel free to throw away the deliverable of any particular step and start again if it turns out crappy. It’s natural to go through this cycle multiple times.
Make simple decisions on behalf of your customers. That’s what we did in Basecamp. The number of messages per page is 25. On the overview page, the last 25 items are shown. Messages are sorted in reverse chronological order. The five most recent projects are shown in the dashboard. There aren’t any options. That’s just the way it is.
Yes, you might make a bad call. But so what. If you do, people will complain and tell you about it. As always, you can adjust. Getting Real is all about being able to change on the fly.
Done. Start to think of it as a magical word. When you get to done it means something’s been accomplished. A decision has been made and you can move on. Done means you’re building momentum.
Value the importance of moving on and moving forward. Get in the rhythm of making decisions. Make a quick, simple call and then go back and change that decision if it doesn’t work out.
Accept that decisions are temporary. Accept that mistakes will happen and realize it’s no big deal as long as you can correct them quickly. Execute, build momentum, and move on.
Keep breaking down timeframes into smaller chunks. Instead of a 12 week project, think of it as 12 weeklong projects. Instead of guesstimating at tasks that take 30+ hours, break them down into more realistic 6-10 hour chunks. Then proceed one step at a time.
The same theory applies to other problems too. Are you facing an issue that’s too big to wrap your mind around? Break it down. Keep dividing problems into smaller and smaller pieces until you’re able to digest them.
Give a programmer an afternoon to code a small, specific module and she’ll crank it out, ready to move onto the next one. Smaller tasks and smaller timelines are more manageable, hide fewer possible requirement misunderstandings, and cost less to change your mind about or redo. Smaller timelines keep developers engaged and give them more opportunities to enjoy a sense of accomplishment and less reason to think, “Oh I’ve got plenty of time to do that. For now, let me finish rating songs in my iTunes library.” -Gina Trapani, web developer and editor of Lifehacker, the productivity and software guide.
Next time someone tries to pin you down for an exact answer to an unknowable question – whether it’s for a deadline date, a final project cost, or the volume of milk that would fit in the Grand Canyon – just start by taking the air out of the room: say “I don’t know.” Far from damaging your credibility, this demonstrates the care you bring to your decision-making. You’re not going to just say words to sound smart. It also levels the playing field by reframing the question as a collaborative conversation. By learning how exact your estimate needs to be (and why), you can work together to develop a shared understanding about the true factors behind the numbers. -Merlin Mann, creator and editor of 43folders.com.
Set up a rule at work: Make half the day alone time. From 10am-2pm, no one can talk to one another (except during lunch). Or make the first or the last half of the day the alone time period. Just make sure this period is contiguous in order to avoid productivity-killing interruptions.
A successful alone time period means letting go of communication addiction. During alone time, give up instant messenging, phone calls, and meetings. Avoid any email thread that’s going to require an immediate response. Just shut up and get to work.
There’s no need to get big early – or later. Even if you have access to 100 of the very best people, it’s still a bad idea to try and hire them all at once. There’s no way that you can immediately assimilate that many people into a coherent culture. You’ll have training headaches, personality clashes, communication lapses, people going in different directions, and more.
So don’t hire. Really. Don’t hire people. Look for another way. Is the work that’s burdening you really necessary? What if you just don’t do it? Can you solve the problem with a slice of software or a change of practice instead?
If there’s no other way, then consider a hire. But you should know exactly who to get, how to introduce them to the work, and the exact pain you expect them to relieve.
Working with prospectives employees
Before we hire anyone we give them a small project to chew on first. We see how they handle the project, how they communicate, how they work, etc. Working with someone as they design or code a few screens will give you a ton of insight. You’ll learn pretty quickly whether or not the right vibe is there.
Scheduling can be tough for this sort of thing but even if it’s for just 20 or 40 hours, it’s better than nothing. If it’s a good or bad fit, it will be obvious. And if not, both sides save themselves a lot of trouble and risk by testing out the situation first.
Judging potential hires
When it comes to programmers, we only hire people we know through open source.
Enthusiasm. It’s one attribute you just can’t fake. When it comes time to hire, don’t think you need a guru or a tech-celebrity. Often, they’re just primadonnas anyway. A happy yet average employee is better than a disgruntled expert.
Find someone who’s enthusiastic. Someone you can trust to get things done when left alone. Someone who’s suffered at a bigger, slower company and longs for a new environment. Someone who’s excited to build what you’re building. Someone who hates the same things you hate. Someone who’s thrilled to climb aboard your train.
Designing the interface
Design is relatively light. A paper sketch is cheap and easy to change. html designs are still relatively simple to modify (or throw out). That’s not true of programming. Designing first keeps you flexible. Programming first fences you in and sets you up for additional costs.
Another reason to design first is that the interface is your product. What people see is what you’re selling. If you just slap an interface on at the end, the gaps will show.
We start with the interface so we can see how the app looks and feels from the beginning. It’s constantly being revised throughout the process. Does it make sense? Is it easy to use? Does it solve the problem at hand? These are questions you can only truly answer when you’re dealing with real screens. Designing first keeps you flexible and gets you to those answers sooner in the process rather than later.
Designing the core of the page
Epicenter design focuses on the true essence of the page – the epicenter – and then builds outward. This means that, at the start, you ignore the extremities: the navigation/tabs, footer, colors, sidebar, logo, etc. Instead, you start at the epicenter and design the most important piece of content first.
Whatever the page absolutely can’t live without is the epicenter. For example, if you’re designing a page that displays a blog post, the blog post itself is the epicenter. Not the categories in the sidebar, not the header at the top, not the comment form at the bottom, but the actual blog post unit. Without the blog post unit, the page isn’t a blog post.
Only when that unit is complete would you begin to think about the second most critical element on the page. Then after the second most critical element, you’d move on to the third, and so on. That’s epicenter design.
Epicenter design eschews the tradtional “let’s build the frame then drop the content in” model. In that process, the page shape is built, then the nav is included, then the marketing “stuff” is inserted, and then, finally, the core functionality, the actual purpose of the page, is poured in to whatever space remains. It’s a backwards process that takes what should be the top priority and saves it for the end.
Three state solution
For each screen, you need to consider three possible states:
The screen people see when everything’s working fine and your app is flush with data.
The screen people see when using the app for the first time, before data is entered.
The screen people see when something goes wrong.
The blank slate
What should you include in a helpful blank slate?
- Use it as an opportunity to insert quick tutorials and help blurbs.
- Give a sample screenshot of the page populated with data so people know what to expect (and why they should stick around).
- Explain how to get started, what the screen will eventually look like, etc.
- Answer key questions that first-time viewers will ask: What is this page? What do I do now? How will this screen look once it’s full?
- Set expectations and help reduce frustration, intimidation, and overall confusion.
First impressions are crucial. If you fail to design a thoughtful blank slate, you’ll create a negative (and false) impression of your application or service.
Coding less software
From the beginning, we’ve designed our products around the concept of less software. Whenever possible, we chop up hard problems into easy ones. We’ve found solutions to easy problems are not only easier to implement and support, they’re easier to understand and easier to use. It’s all part of how we differentiate ourselves from competitors; Instead of trying to build products that do more, we build products that do less.
- Less software is easier to manage.
- Less software reduces your codebase and that means less maintenance busywork (and a happier staff).
- Less software lowers your cost of change so you can adapt quickly. You can change your mind without having to change boatloads of code.
- Less software results in fewer bugs.
- Less software means less support.
Which features you choose to include or omit have a lot to do with less software too. Don’t be afraid to say no to feature requests that are hard to do. Unless they’re absolutely essential, save time/effort/confusion by leaving them out.
Slow down too. Don’t take action on an idea for a week and see if it still seems like a great idea after the initial buzz wears off. The extra marinading time will often help your brain come up with an easier solution.
Encourage programmers to make counteroffers.You want to hear: “The way you suggested will take 12 hours. But there’s a way I can do it that will only take one hour. It won’t do x but it will do y.” Let the software push back. Tell programmers to fight for what they think is the best way.
Listening to the code
Listen to your code. It will offer suggestions. It will push back. It will tell you where the pitfalls reside. It will suggest new ways to do things. It will help you stick to a model of less software.
Is a new feature requiring weeks of time and thousands of lines of code? That’s your code telling you there’s probably a better way. Is there a simple way to code something in one hour instead of a complicated way that will take ten hours? Again, that’s your code guiding you. Listen.
So what should you do in place of a spec? Go with a briefer alternative that moves you toward something real. Write a one page story about what the app needs to do. Use plain language and make it quick. If it takes more than a page to explain it, then it’s too complex. This process shouldn’t take more than one day.
Then begin building the interface – the interface will be the alternative to the functional spec. Draw some quick and simple paper sketches. Then start coding it into html. Unlike paragraphs of text that are open to alternate interpretations, interface designs are common ground that everyone can agree on.
Eliminating unnecesary paperwork
Build, don’t write. If you need to explain something, try mocking it up and prototyping it rather than writing a longwinded document. An actual interface or prototype is on its way to becoming a real product. A piece of paper, on the other hand, is only on its way to the garbage can.
Documents that live separately from your application are worthless. They don’t get you anywhere. Everything you do should evolve into the real thing. If a document stops before it turns real, it’s dead.
If you do find yourself requiring words to explain a new feature or concept, write a brief story about it. Don’t get into the technical or design details, just tell a quick story. Do it in a human way, like you would in normal conversation.
It doesn’t need to be an essay. Just give the flow of what happens. And if you can include the brief story in context with screens you are developing, all the better.
Stick to the experience instead of getting hung up on the details. Think strategy, not tactics. The tactics will fall into place once you begin building that part of your app. Right now you just want to get a story going that will initiate conversation and get you on the right track.
Using real text
As soon as you can, use real and relevant words. If your site or application requires data input, enter the real deal. And actually type in the text – don’t just paste it in from another source. If it’s a name, type a real name. If it’s a city, type a real city. If it’s a password, and it’s repeated twice, type it twice.
Do as your customers do and you’ll understand them better. When you understand them better, and feel what they feel, you’ll build a better interface.
In order to get people to notice you amid the din, give something away for free.
We want people to experience the product, the interface, the usefulness of what we’ve built. Once they’re hooked, they’re much more likely to upgrade to one of the paying plans (which allow more projects or pages and gives people access to additional features like file uploading and ssl data encryption).
A painless signup-cancelation process
Make it as easy as possible to get in – and get out – of your app.
If I’m a customer that wants to use your app, it should be a painless, no-brainer process. Provide a big, clear, signup button that pops and put it on each page of your marketing site. Tell folks how easy it is: “From sign-up to login in just 1 minute!” Keep the signup form as short as possible. Don’t ask for stuff you don’t need and don’t throw a long daunting form at people.
The same principles hold true for the cancellation process. You never want to “trap” people inside your product. While we’re sorry when people decide to cancel their Basecamp account, we never make that process intimidating or confusing. “Cancel my account” is a link that’s clear as day on a person’s account page. There shouldn’t be any email to send, special form to fill out, or questions to answer.
Softening bad news
Need to deliver bad news like a price increase? Make it as painless as possible by giving folks plenty of advance notice. Also, consider a grandfather period that exempts existing customers for a certain period of time. These folks are your bread and butter and you want to make them feel valued, not gouged.
To build up buzz and anticipation, go with a Hollywood-style launch: 1) Teaser, 2) Preview, and 3) Launch.
A few months ahead of time, start dropping hints. Let people know what you’re working on. Post a logo. Post to your blog about the development. Stay vague but plant the seed. Also, get a site up where you can collect emails from folks who are interested.
A few weeks ahead of launch, start previewing features. Give people behind-the-scenes access. Describe the theme of the product. For Basecamp, we posted screenshots and highlighted reminders, milestones, and other features.
You can also offer some special “golden tickets” to a few people so they can start using the app early. You’ll get the benefit of having some beta testers while they’ll feel that special glow that people get from being early adopters.
It’s release time. Now people can actually go to the “theater” and see your app. Get emails out to those who signed up. Launch your full marketing site. Spread the gospel as much as possible. Get blogs to link to you. Post about your progress: How many people have signed up? What updates/tweaks have you made? Show momentum and keep at it.
Building a promotional site
What should you include on this site? Some ideas:
- Overview: Explain your app and its benefits.
- Tour: Guide people through various features.
- Screen captures and videos: Show people what the app actually looks like and how to use it.
- Manifesto: Explain the philosophy and ideas behind it.
- Case Studies: Provide real life examples that show what’s possible.
- Buzz: Testimonial quotes from customers, reviews, press, etc.
- Forum: Offer a place for members of the community to help one another.
- Pricing & Sign-up: Get people into your app as quickly as possible.
- Weblog: Blogs keep your site fresh with news, tips, etc.
Promotion through education
As a promotional technique, education is a soft way to get your name – and your product’s name – in front of more people. And instead of a hard sell “buy this product” approach, you’re getting attention by providing a valuable service. That creates positive buzz that traditional marketing tactics can’t match. People who you educate will become your evangelists.
Education can come in many forms. Post tips and tricks at your site that people will want to share with others. Speak at conferences and stay afterwards to meet and greet with attendees. Conduct workshops so curious fans can learn more and talk to you in the flesh. Give interviews to publications. Write articles that share helpful information. And write books.
Everyone knows to pitch at the marketing site. But the sell shouldn’t stop there. If you have a tiered pricing plan (or a free version of your app), don’t forget to call out upgrade opportunities from within the product. Tell folks that you’ll remove barriers if they upgrade.
Existing customers are your best bet for sales. Don’t be shy about trying to get repeat business from people who already know and use your product.
Support versus development
Avoid building walls between your customers and the development/design team. Don’t outsource customer support to a call center or third party. Do it yourself. You, and your whole team, should know what your customers are saying. When your customers are annoyed, you need to know about it. You need to hear their complaints. You need to get annoyed too.
FAQ’s and help
Strive to build a tool that requires zero training. How do you do this? Well, as we’ve mentioned before, you start by keeping everything simple. The less complex your app is, the less you’ll need to help people out of the weeds. After that, a great way to preempt support is by using inline help and faqs at potential points of confusion.
Answering quickly to user’s problems
Customers light up when you answer their questions quickly. They’re so used to canned responses that show up days later (if at all) that you can really differentiate yourself from competitors by offering a thoughtful response right away. During business hours, we answer 90% of all email support requests within 90 minutes – and often within a half-hour. And people love it.
Even if you don’t have a perfect answer, say something. You can buy goodwill with a response that is delivered quickly in an open, honest way. If someone is complaining about an issue that can’t be fixed immediately, tell them something like, “We hear what you’re saying and we’ll be working on it in the future.” It’s a great way to diffuse a potentially negative situation.
Customers appreciate directness and will often shift from angr y to polite if you respond quickly and in a straight-shooting manner.
“How can a small team of just three developers create an innovative product and successfully compete with the big guys? The answer is to enlist an army of many. Remember from your first day that your customers are your most important asset and that they are absolutely vital to your long-term success so treat your community of users like royalty. The way to compete with the big guys is by starting small and paying attention to every one of your customers.
It is your customers that will be the first to alert you of bugs, that will be the first to alert you of needs that have not been met and it is your first customers that will carry the flag and spread your message.
This does not mean that your product has to be perfect when you launch. Quite to the contrary, release early and often. However, when your customers encounter bugs, make sure to send a reply to them quickly thanking them for their input.
Customers don’t expect your product to be perfect and they don’t expect that all of their features will be implemented. However, customers do expect that you are listening and acknowledging that you care, so show that you care. This is one area where most large companies show a huge deficit so develop a sense of community early.
At Blinklist, every single customer email is answered, usually within the first hour (unless we happen to be asleep). We also have an online forum and we make sure that every single post and comment gets acknowledged.
Equally important, all of our developers receive our customer feedback and they are active participants in the online discussion forums. This way, we are slowly but surely building an active and loyal BlinkList community.” -Michael Reining, co-founder, MindValley & Blinklist
Saying no to customers
When it comes to feature requests, the customer is not always right. If we added every single thing our customers requested, no one would want our products.
As a software development company, you have to act as a filter. Not everything everyone suggests is the right answer. We consider all requests but the customer is not always right. There will be times when you just have to piss some people off. C’est la vie.
If something goes wrong, tell people. Even if they never saw it in the first place.
Here’s a sample of what we post when something goes wrong: “We apologize for the downtime this morning – we had some database issues which caused major slowdowns and downtimes for some people. We’ve fixed the problem and are taking steps to make sure this doesn’t happen again…Thanks for your patience and, once again, we’re sorry for the downtime.”
Be as open, honest, and transparent as possible. Don’t keep secrets or hide behind spin. An informed customer is your best customer. Plus, you’ll realize that most of your screwups aren’t even that bad in the minds of your customers. Customers are usually happy to give you a little bit of breathing room as long as they know you’re being honest with them.
A side note about delivering news, bad and good: When bad news comes, get it all out in the open at once. Good news, on the other hand, should be trickled out slowly. If you can prolong the good vibes, do it.
Don’t stop blogging once you launch. Show your product is a living creature by keeping a dedicated blog that you update frequently (at least once a week, more often if you can).
Things to include:
- Tips & tricks
- New features, updates, & fixes
Beta passes the buck to your customers. If you’re not confident enough about your release then how can you expect the public to be? Private betas are fine, public betas are bullshit. If it’s not good enough for public consumption don’t give it to the public to consume.
Don’t wait for your product to reach perfection. It’s not gonna happen. Take responsibility for what you’re releasing. Put it out and call it a release. Otherwise, you’re just making excuses.
You don’t have to fix each bug instantly. Most bugs are annoying, not destroying. Annoyances can be tabled for a bit. Bugs that result in “it doesn’t look right” errors or other misdemeanor miscues can safely be set aside for a while. If a bug destroys your database, though, you obviously need to fix it immediately.
Prioritize your bugs. How many people are affected? How bad is the problem? Does this bug deserve immediate attention or can it wait? What can you do right now that will have the greatest impact for the greatest number of people? Often times adding a new feature may even be more important to your app than fixing an existing bug.
Also, don’t create a culture of fear surrounding bugs. Bugs happen. Don’t constantly seek someone to blame. The last thing you want is an environment where bugs are shoved under the rug instead of openly discussed.
Beeing aware of bloats
You don’t have to become an outer space pen that writes upside down. Sometimes it’s ok to just be a pencil. You don’t need to be a swiss-army knife. You can just be a screwdriver. You don’t need to build a diving watch that’s safe at 5,000 meters if your customers are land-lovers who just want to know what the time is.
Don’t inflate just for the sake of inflating. That’s how apps get bloated.