May 14, 2010

Getting Real by 37Signals

From http://gettingreal.37signals.com/


Notes from the book.


Introduction





  • Build only real things, not representations like graphs, etc.

  • Less of everything that is not essential.

  • Stay small and be agile.

  • Start with interface, before getting software wrong.

  • Deliver what customers need and eliminate what they don't.

  • Deal with actual problems rather than ideas about them.


The Starting Line



  • Build Less





    • Defensive companies - the ones trying to build more than the competition - only think behind - they don't lead, they follow.

    • Solve the simple problems and leave the hairy, difficult, nasty problems to everyone else.

    • Less features, preferences, people, meetings, promises, etc.




  • Build software for yourself





    • Solve your own problems.

    • When you solve your own problem, you create a tool that you're passionate about.

    • Building for someone creates lots of mini-guesses.




  • Fund yourself





    • Getting funds from investors often begins to trump building a quality product as expectations are raised and they want their money back and quickly.

    • Constraints drive innovation, force creativity, force to get your idea out sooner.

    • Simple exit plans.

    • Quick payout is pretty unlikely. So focus on building a quality tool that you and your customers can live with for a long time.




  • Fix Time and Budget, Flex Scope





    • There's always time to add stuff later - later is eternal, now is fleeting.

    • Launching something great that's a little smaller in scope than planned is better than launching something mediocre and full of holes because you had to hit some magical time, budget, and scope window.

    • Benefits of this:





      • Prioritization - This will push you to make tough decisions instead of hemming and hawing.

      • Reality - Deliver quality.

      • Flexibility - The ability to change is key.




    • Scope down. It's better to make half a product than a half-assed product.




  • Have 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.

    • e.g. Basecamp to be something completely different, the anti-Microsoft-Project.

    • 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.

    • Marketers (and all human beings) are well trained to follow the leader. The natural instinct is to figure out what's working for the competition and then try to outdo it - to be cheaper than your competitor who competes on price, or faster than the competitor who competes on speed. The problem is that once a consumer has bought someone else's story and believes that lie, persuading the consumer to switch is the same as persuading him to admit he was wrong. And people hate admitting that they're wrong.Instead, you must tell a different story and persuade listeners that your story is more important than the story they currently believe. If your competition is faster, you must be cheaper. If they sell the story of health, you must sell the story of convenience. Not just the positioning x/y axis sort of "We are cheaper" claim, but a real story that is completely different from the story that's already being told.

       






  • It Shouldn't be a Chore





    • Your passion - or lack of - will shine through.

    • It's difficult not to detect the emotional investment of the hands that built it.





Stay Lean



  • Less Mass



    • The leaner you are, the easier it is to change things, including minds.




  • Lower Your Cost of Change



    • Stay flexible by reducing obstacles to change.

    • If your competitors can change faster than you, you're at a huge disadvantage.

    • All the cash, all the marketing, all the people in the world can't buy the agility you get from being small.

    • Simple rules, as with the bird flock simulation, lead to complex behavior. Complex rules, as with the tax law, lead to stupid behavior.

    • In a well-designed system, it's the interactions and relationships that create the interesting behavior.




  • The Three Musketeers - a team of three for version 1.0



    • a developer, a designer, and a sweeper (someone who can roam between both worlds)

    • you'll be forced to deal with tradeoffs earlier in the process

    • It will make you figure out your priorities earlier rather than later

    • good communication - Metcalfe's Law - "the value of a communication system grows at approximately the square of the number of users of the system"




  • Embrace Constraints



    • Let limitations guide you to creative solutions




  • Be Yourself



    • Differentiate yourself from bigger companies by being personal and friendly

    • Small companies enjoy fewer formalities, less bureaucracy, and more freedom.

    • Smaller companies are closer to the customer by default.

    • You can also internally ditch formalities.





Priorities



  • What's the Big Idea?



    • Explicitly define the one-point vision for your app

    • vision will guide your decisions and keep you on a consistent path

    • Examples:



      • Basecamp: Project management is communication

      • Backpack: Bring life's loose ends together

      • Campfire: Group chat over IM sucks

      • Ta-da List: Competing with a post-it note

      • Writeboard: Word is overkill




    • Make the big decision about your vision upfront and all your future little decisions become much easier.




  • Ignore Details Early On



    • Work from large to small. Always.

    • Success and satisfaction are in the details. You'll also find stagnation, disagreement, meetings, and delays. These things can kill morale and lower your chances of success.




  • It's a Problem When It's a Problem



    • Don't waste time on problems you don't have yet.

    • Don't overbuild. Increase hardware and system software as necessary.

    • Make decisions just in time, when you have access to the real information you need.




  • Hire the Right Customers



    • Find the core market for your application and focus solely on them

    • The customer is not always right. You have to sort out who's right and who's wrong for your app.

    • If you try to please everyone, you won't please anyone

    • Focusing on a core market also makes it much easier to spread the word about your software.




  • Scale Later



    • You don't have a scaling problem yet. Wait until that actually happens.

    • 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.




  • Make Opinionated Software



    • Your app should take 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.

    • Don't go chasing people you'll never make happy.





Feature Selection



  • Half, Not Half-Assed



    • Build half a product that kicks ass, not a half-ass product.

    • 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.




  • It Just Doesn't Matter



    • Essentials only - Figure out what matters and leave out the rest.

    • Best designers are the ones that can determine what just doesn't matter.




  • Start With No



    • Make features work hard to be implemented.

    • Once a feature is out, you're stuck with it - try to take a released feature away from customers and see how pissed off they get.

    • Make each feature prove itself and show that it's a survivor.

    • Deeper look only when a request for a feature keeps coming back.

    • Innovation is not about saying yes to everything. It's about saying NO to all but the most crucial features.




  • Hidden Costs



    • Expose the price of new features

    • Be on the lookout for feature loops (i.e. features that lead to more features) - a simple idea can snowball into a major headache.

    • 1. Say no.
      2. Force the feature to prove its value.
      3. If "no" again, end here. If "yes," continue...
      4. Sketch the screen(s)/ui.
      5. Design the screen(s)/ui.
      6. Code it.
      7-15. Test, tweak, test, tweak, test, tweak, test, tweak...
      16. Check to see if help text needs to be modified.
      17. Update the product tour (if necessary).
      18. Update the marketing copy (if necessary).
      19. Update the terms of service (if necessary).
      20. Check to see if any promises were broken.
      21. Check to see if pricing structure is affected.
      22. Launch.
      23. Hold breath.




  • Can You Handle It?



    • Build products and offer services you can manage.

    • It's easy to make promises. It's much harder to keep them. Make sure whatever it is that you're doing is something you can actually sustain - organizationally, strategically, and financially.




  • Human Solutions



    • Build software for general concepts and encourage people to create their own solutions.

    • 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.




  • Forget Feature Requests



    • Let your customers remind you what's important.

    • 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.

    • the ones that are important will keep bubbling up anyway

    • If it's really worth remembering, customers will remind you until you can't forget.

    • Just because x number of people request something, doesn't mean you have to include it. Sometimes it's better to just say no and maintain your vision for the product.




  • Hold the Mayo



    • 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?"

    • Sometimes the biggest favor you can do for customers is to leave something out.





Process




  • Race to Running Software






    • Get something real up and running quickly




    • Once running - more accurate perspective on how to proceed.




    • Stories, wireframes, even html mockups, are just approximations. Running software is real.




    • if you sketch or throw out ideas, you won't agree. If you start making the real thing, one tends to reach agreement.







  • Rinse and Repeat






    • Work in iterations




    • lets you continue to make informed decisions as you go along




    • real feedback and real guidance




    • Knowing that you're going to revisit issues is a great motivator to just get ideas out there to see if they'll fly.







  • From Idea to Implementation






    • Go from brainstorm to sketches to HTML to coding




    • Brainstorm






      • Come up with ideas. What is this product going to do?




      • 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







    • Paper sketches






      • quick, dirty, and cheap




      • 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






        • Don't write any programming code yet. Just build a mock-up in html and css.







      • Code it




      • stay flexible and expect multiple iterations










  • Avoid Preferences






    • Decide the little details so your customers don't have to




    • Preferences are a way to avoid making tough decisions.




    • Instead of using your expertise to choose the best path, you're leaving it in the hands of customers - making busy work for them.




    • they create more software




    • Make simple decisions on behalf of your customers




    • If you make a bad call, people will complain and tell you about it.







  • "Done!"






    • Decisions are temporary so make the call and move on




    • This isn't brain surgery, it's a web app.




    • No matter how much you plan you're likely to get half wrong anyway.




    • ideas are worth nothing unless executed







  • Test in the Wild






    • Test your app via real world usage




    • Formal usability testing is too stiff




    • release beta features to a select few inside the real application itself




    • don't have a release version and a beta version. They should always be the same thing. A separate beta version will only get a superficial walk through. The real version, with some beta features sprinkled in, will get the full workout




    • The Beta Book: It was a win-win: I got to deliver a much improved paper book, and the community got early access to something they wanted. And if you're in a competitive race, getting something out earlier helps folks commit to you and not your competition.




    • Do it quick:






      • 1. Decide if it's worth doing, and if so:
        2. Do it quick - not perfect. just do it.
        3. Save it. upload it. publish it
        4. See what people think










  • Shrink Your Time






    • Break it down




    • 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







The Organization




  • Unity






    • Don't split into silos




    • While specialization has its advantages, it also creates a situation where staffers see just their own little world instead of the entire context of the web app.




    • hire people with multiple talents who can wear different hats during development




    • The end result will be a more harmonious product.







  • Alone Time






    • People need uninterrupted time to get things done




    • One positive side effect of time difference spreads is alone time.




    • don't have to mindshift between various tasks




    • The alone zone is where real progress is made.




    • Getting in the zone takes time. And that's why interruption is your enemy - they force you to start over.




    • Make half the day alone time when no one can talk to one another. Make sure this period is contiguous.




    • A successful alone time period means letting go of communication addiction.







  • Meetings Are Toxic






    • Don't have meetings




    • Absolutely must meeting:






      • Set a 30 minute timer. When it rings, meeting's over. Period.




      • Invite as few people as possible.




      • Never have a meeting without a clear agenda.







    • break teams into smaller, autonomous and independent units to reduce communications links







  • Seek and Celebrate Small Victories






    • Release something today




    • Motivation is local - if you aren't motivated by what you are working on right now, then chances are it won't be as good as it should be.




    • quick wins that you can celebrate are great motivators




    • find 4-hour quick wins







Staffing



  • Hire Less and Hire Later



    • Add slow to go fast

    • you should know exactly who to get, how to introduce them to the work, and the exact pain you expect them to relieve

    • Brooks' law: Adding people to a late software project makes it later.

    • The real trouble with using a lot of mediocre programmers instead of a couple of good ones is that no matter how long they work, they never produce something as good as what the great programmers can produce.




  • Kick the Tires



    • Work with prospective employees on a test-basis first

    • 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.




  • Actions, Not Words



    • Judge potential tech hires on open source contributions

    • make a decision based on the things that really matter:



      • Quality of work: Many programmers can talk the talk but trip when it comes time to walk the walk.

      • Cultural perspective: Look at the specific decisions made by a candidate in coding, testing, and community arguments to see whether you've got a cultural match.

      • Level of passion: involvement in open source requires at least some passion.

      • Completion percentage: lots of programmers can't get stuff done.

      • Social match: Working with someone over a long period of time, during both stress/relaxation and highs/lows, will show you their real personality.







  • Get Well Rounded Individuals



    • Go for quick learning generalists over ingrained specialists

    • Everyone needs to have an organized mind. Everyone needs to be able to communicate with customers.

    • Keep in mind that small teams often need to change direction and do it quickly. You want someone who can adjust and learn and flow as opposed to a stick-in-the-mud who can do only one thing.




  • You Can't Fake Enthusiasm



    • Go for happy and average over frustrated and great

    • 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.




  • Wordsmiths



    • Hire good writers

    • If you are trying to decide between a few people to fill a position, always hire the better writer. Good writers know how to communicate. They make things easy to understand. They can put themselves in someone else's shoes. They know what to omit. They think clearly.





Interface Design



  • Interface First



    • Design the interface before you start programming

    • Programming is the heaviest component of building an app, meaning it's the most expensive and hardest to change.




  • Epicenter Design



    • Start from the core of the page and build outward

    • design the most important piece of content first




  • Three State Solution



    • Design for regular, blank, and error states

    • Regular - The screen people see when everything's working fine and your app is flush with data.

    • Blank - The screen people see when using the app for the first time, before data is entered.

    • Error - The screen people see when something goes wrong.




  • The Blank Slate



    • Set expectations with a thoughtful first-run experience

    • The blank slate is your app's first impression and you never get a second

    • the customer decides if an application is worthy at this blank slate stage - the stage when there's the least amount of information, design, and content on which to judge the overall usefulness of the application.

    • What should you include in a helpful blank slate?



      • quick tutorials and help blurbs

      • sample screenshot of the page populated with data

      • how to get started

      • 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.







  • Get Defensive



    • Design for when things go wrong




  • Context Over Consistency



    • What makes sense here may not make sense there

    • Give people what they need when they need it and get rid of what they don't




  • Copywriting is Interface Design



    • Every letter matters

    • Do you label a button Submit or Save or Update or New or Create? That's copywriting. Do you write three sentences or five? Do you explain with general examples or with details? Do you label content New or Updated or Recently Updated or Modified? Is it There are new messages: 5 or There are 5 new messages or is it 5 or five or messages or posts? All of this matters.

    • You need to speak the same language as your audience




  • One Interface



    • Incorporate admin functions into the public interface





Code



  • Less Software



    • Keep your code as simple as possible

    • each time you increase the amount of code, your software grows exponentially more complicated




  • Optimize for Happiness



    • Choose tools that keep your team excited and motivated

    • A happy programmer is a productive programmer




  • Code Speaks



    • Listen when your code pushes back

    • If programmers got paid to remove code from sofware instead of writing new code, software would be a whole lot better.




  • Manage Debt



    • Pay off your code and design "bills"

    • pay it off at some point by cleaning up the hairy code or redesigning

    • The same way you should regularly put aside some of your income for taxes, regularly put aside some time to pay off your code and design debt. If you don't, you'll just be paying interest (fixing hacks) instead of paying down the principal (and moving forward).




  • Open Doors



    • Get data out into the world via RSS, APIs, etc.





Words




  • There's Nothing Functional about a Functional Spec






    • Don't write a functional specifications document




    • Functional specs are fantasies




    • They're about making everyone feel involved and happy, never about making tough choices and exposing costs




    • only lead to an illusion of agreement - Everyone may be reading the same thing but they're thinking something different.




    • they force you to make the most important decisions when you have the least information




    • they lead to feature overload




    • they don't let you evolve, change,and reassess




    • Write a one page story about what the app needs to do. Use plain language and make it quick.




    • Then begin building the interface - the alternative to the functional spec - quick and simple paper sketches - Then start coding it into html - common ground that everyone can agree on







  • Don't Do Dead Documents






    • Eliminate unnecessary paperwork




    • 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.







  • Tell Me a Quick Story






    • Write stories, not details




    • Stick to the experience




    • Think strategy, not tactics







  • Use Real Words






    • Insert actual text instead of lorem ipsum




    • Dummy text is a veil between you and reality







  • Personify Your Product






    • What is your product's personality type?




    • Polite? Stern? Forgiving? Strict? Funny? Deadpan? Serious? Loose? Do you want to come off as paranoid or trusting? As a know-it-all? Or modest and likable?




    • Your product has a voice - and it's talking to your customers 24 hours a day.







Pricing and Signup



  • Free Samples



    • Give something away for free




  • Easy On, Easy Off



    • Make signup and cancellation a painless process

    • Tell folks how easy it is: "From sign-up to login in just 1 minute!"

    • There should always be a free option so customers can demo the app without entering credit card information.

    • 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.

    • You never want to "trap" people inside your product.

    • Make sure people can get their data out if they decide to leave.

    • This is crucial because giving people control over their information builds trust.




  • Silly Rabbit, Tricks are for Kids



    • Avoid long-term contracts, sign-up fees, etc.

    • No one likes long term contracts, early termination fees, or one time set-up fees.




  • A Softer Bullet



    • Soften the blow of bad news with advance notice and grandfather clauses

    • e.g. price increase

    • consider a grandfather period that exempts existing customers for a certain period of time - make them feel valued





Promotion



  • Hollywood Launch



    • Go from teaser to preview to launch

    • Teaser



      • 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.

      • At this stage, you should also start seducing mavens and insiders. These are the folks on the cutting edge. They're the tastemakers. Appeal to their vanity and status as ahead-of-the-curvers. Tell them they're getting an exclusive sneak preview. If a site like Boing Boing, Slashdot, or Digg links up your app, you'll get loads of traffic and followers. Plus, your page rank at Google will go up too.




    • Preview



      • 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.

      • Also, tell people about the ideas and principles behind the app. For Backpack, we posted our manifesto before launch. This got people thinking and talking about the app.

      • 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.

      • And again, encourage people to sign up so you've got a foundation of emails to blitz once you launch.




    • Launch



      • 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.







  • A Powerful Promo Site



    • Build an ace promotional site that introduces people to your product

    • The best promotional tool is a great product. Word will get out if you've got an app that people find really useful.

    • Still, you need an ace promotional site too:



      • 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.







  • Ride the Blog Wave



    • Blogging can be more effective than advertising (and it's a hell of a lot cheaper)

    • Advertising is expensive. And evaluating the effectiveness of various types of advertising can wind up being even more expensive than the advertising itself.

    • blogs can offers helpful advice, tips, tricks, links, etc




  • Solicit Early



    • Get advance buzz and signups going ASAP




  • Promote Through Education



    • Share your knowledge with the world

    • 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.

    • e.g.: Yellow Fade Technique, a method to subtly spotlight a recently changed area on a page - A lesson was learned and a lot of people who never would have known about our products were exposed to them.




  • Feature Food



    • They're hungry for it so serve it up




  • Track Your Logs



    • Study your logs to track buzz

    • You need to know who's talking about you.

    • Find out and then make your presence felt. Leave comments at those blogs. Thank people for posting links. Ask them if they want to be included on your special advance list so they'll be among the first to know about future releases, updates, etc. Collect positive praise and create a "buzz" page at your site. Testimonials are a great way to promote your app since third-party praise is more trustworthy to most people.

    • If the comments are negative, still pay attention. Show you're listening. Respond to critiques thoughtfully. Something like: "We appreciate the feedback but we did it this way because..." Or "You raise a good point and we're working on it." You'll soften up your critics and put a human face on your product. It's amazing how much a thoughtful comment on a blog can diffuse naysayers and even turn complainers into evangelists.




  • Inline Upsell



    • Promote upgrade opportunities inside the app

    • e.g. When someone tries to upload a file, we don't just turn them away. We explain why file uploading isn't available and encourage them to upgrade to the paid version and explain why that's a good idea.

    • Existing customers are your best bet for sales.




  • Name Hook



    • Give your app a name that's easy to remember

    • Don't worry about picking a name that vividly describes your tool's purpose; That usually just leads to a generic, forgettable name.

    • e.g.: Basecamp is a better name than something like Project Management Center or ProjectExpress. Writeboard is better than CollaborEdit.

    • Pick a name that's short, catchy, and memorable and then run with it.

    • And don't sweat it if you can't get the exact domain name you want. You can always be creative and get close with a couple of extra letters (e.g. backpackit.com or campfirenow.com).





Support




  • Feel The Pain






    • Tear down the walls between support and development




    • listening to customers is the best way to get in tune with your product's strengths and weaknesses.




    • Don't outsource customer support to a call center or third party




    • Put yourself in your customer's shoes. If you want your steak cooked just how you like it, would you rather talk to the bus boy or the chef that's actually cooking it?







  • Zero Training






    • Use inline help and FAQs so your product doesn't require a manual or training







  • Answer Quick






    • Quick turnaround time on support queries should be a top priority




    • 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 angry to polite if you respond quickly and in a straight-shooting manner.




    • customers do expect that you are listening and acknowledging that you care




    • We also have an online forum and we make sure that every single post and comment gets acknowledged.







  • Tough Love






    • Be willing to say no to your customers




    • As a software development company, you have to act as a filter. Not everything everyone suggests is the right answer.




    • it's critical that you love your product - And you won't love your product if it's filled with a bunch of stuff you don't agree with







  • In Fine Forum






    • Use forums or chat to let customers help each other




    • forums are mainly a place for the community to help each other and share their experiences with the product







  • Publicize Your Screwups






    • Get bad news out there and out of the way




    • If something goes wrong, tell people. Even if they never saw it in the first place.




    • An informed customer is your best customer.




    • 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.







Post-Launch



  • One Month Tuneup



    • Issue a major update 30 days after launch

    • A quick update shows momentum. It shows you're listening. It shows you've got more tricks up your sleeve. It gives you a second wave of buzz. It reaffirms initial good feelings. It gives you something to talk about and others to blog about.




  • Keep the Posts Coming



    • Show your product is alive by keeping an ongoing product development blog post-launch

    • Things to include:



      • Faq

      • How-tos

      • Tips & tricks

      • New features, updates, & fixes

      • Buzz/press







  • Better, Not Beta



    • Don't use "beta" as a scapegoat

    • These days it feels like everything is in beta stage forever.

    • tells customers you're not really committed to rolling out a finished product

    • 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.




  • All Bugs Are Not Created Equal



    • Prioritize your bugs (and even ignore some of them)

    • Often times adding a new feature may even be more important to your app than fixing an existing bug.

    • If customers complain about a bug, be straight up with them. Tell them you've noted the issue and are dealing with it. If it won't be addressed right away, explain why and say you're focusing on areas of the product that affect a greater number of people. Honesty is the best policy.




  • Ride Out the Storm



    • Wait until knee-jerk reactions to changes die down before taking action

    • Most people respond before they've really dug in and used whatever you've added

    • negative reactions are almost always louder and more passionate than positive ones

    • you may only hear negative voices even when the majority of your base is happy about a change

    • Make sure you don't foolishly backpedal on a necessary, but controversial, decision.




  • Keep Up With the Joneses



    • Subscribe to news feeds about your competitors




  • Beware the Bloat Monster



    • More mature doesn't have to mean more complicated

    • Sometimes there's a point where you should just let a product be.

    • This is one of the key benefits to building web-based software instead of traditional desktop based software. Desktop software makers such as Adobe, Intuit, and Microsoft need to sell you new versions every year. And since they can't just sell you the same version, they have to justify the expense by adding new features. That's where the bloat begins.

    • With web-based software based on the subscription model, people pay a monthly fee to use the service. You don't need to keep upselling them by adding more and more and more, you just need to provide an ongoing valuable service.




  • Go With the Flow



    • Be open to new paths and changes in direction

    • Be a surfer. Watch the ocean. Figure out where the big waves are breaking and adjust accordingly.





The difference between you and everyone else will be how well you execute. Success is all about great execution.


 


The key is balance. If you tilt too far in one direction, you're headed for failure. Constantly seek out your weak links and focus on them until they're up to par.

Posted by at
Labels:

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)