Jason Fried, David Heinemeier Hansson, Matthew Linderman, and 37signals
Too many features, too many buttons, too much to learn. Our products do less than the competition – intentionally. We build products that work smarter, feel better, allow you to do things your way, and are easier to use. (Location 156)
Months of planning are not necessary. Months of writing specs are not necessary – specs should have the foundations nailed and details figured out and refined during the development phase. Don’t try to close all open issues and nail every single detail before development starts. Ship less features, but quality features. (Location 209)
If there are minor bugs, ship it as soon you have the core scenarios nailed and ship the bug fixes to web gradually after that. The faster you get the user feedback the better. (Location 214)
Underdo your competition Conventional wisdom says that to beat your competitors you need to one-up them. If they have four features, you need five (or 15, or 25). If they’re spending x, you need to spend xx. If they have 20, you need 30. This sort of one-upping Cold War mentality is a dead-end. It’s an expensive, defensive, and paranoid way of building products. Defensive, paranoid companies can’t think ahead, they can only think behind. They don’t lead, they follow. (Location 227)
Do less than your competitors to beat them. Solve the simple problems and leave the hairy, difficult, nasty problems to everyone else. Instead of one-upping, try one-downing. Instead of outdoing, try underdoing. (Location 232)
Less features Less options/preferences Less people and corporate structure Less meetings and abstractions Less promises (Location 235)
Launch on time and on budget Here’s an easy way to launch on time and on budget: keep them fixed. Never throw more time or money at a problem, just scale back the scope. (Location 297)
If you can’t fit everything in within the time and budget allotted then don’t expand the time and budget. Instead, pull back the scope. There’s always time to add stuff later – later is (Location 300)
Our recommendation: Scope down. It’s better to make half a product than a half-assed product (more on this later). (Location 312)
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. (Location 338)
However, this can quickly lead one astray. Instead, we stay focused on the big picture and keep asking ourselves, what is the key problem we are trying to solve and how can we solve it. (Location 346)
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. (Location 350)
What might take a big team in a huge organization weeks to (Location 402)
change may only take a day in a small, lean organization. That advantage is priceless. Cheap and fast changes are small’s secret weapon. (Location 402)
Start with a developer, a designer, and a sweeper (someone who can roam between both worlds). (Location 424)
version. Remember, it’s OK to keep your first version small and tight. You’ll quickly get to see if your idea has wings and, if it does, you’ll have a clean, simple base to build on. (Location 430)
We took big tasks and broke them up into small bits that we tackled one at a time. We moved step by step and prioritized as we went along. (Location 450)
Differentiate yourself from bigger companies by being personal and friendly 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. (Location 463)
On our website we list a toll-free number that forwards to our mobile phones and on our business cards each of us list our mobile numbers. We emphasize to our customers that they can get in touch with us any time no matter what the problem might be. Our customers appreciate this level of trust and no one has ever abused this service. (Location 481)
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? (Location 493)
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?” (Location 496)
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 (Location 525)
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. (Location 549)
Find the core market for your application and focus solely on them (Location 554)
If you try to please everyone, you won’t please anyone (Location 556)
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. (Location 610)
Start off with a lean, smart app and let it gain traction. Then you can add to the solid foundation you’ve built. (Location 613)
The best designers and the best programmers aren’t the ones with the best skills, or the nimblest fingers, or the ones who can rock and roll with Photoshop or their environment of choice, they are the ones that can determine what just doesn’t matter. That’s where the real gains are made. Most of the time you spend is wasted on things that just don’t matter. If you can cut out the work and thinking that just don’t matter, you’ll achieve productivity you’ve never imagined. (Location 628)
The secret to building half a product instead of a half-ass product is saying no. Each time you say yes to a feature, you’re adopting a child. You have to take your baby through a whole chain of events (e.g. design, implementation, testing, etc.). And once that feature’s out there, you’re stuck with it. Just try to take a released feature away from customers and see how pissed off they get. (Location 634)
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. (Location 640)
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 (Location 642)
because it doesn’t do 100 other things. You like it because it doesn’t try to please everyone all the time.” (Location 643)
Expose the price of new features Even if a feature makes it past the “no” stage, you still need to expose its hidden costs. (Location 651)
For every new feature you need to... 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 (Location 657)
necessary). 20. Check to see if any promises were broken. 21. Check to see if pricing structure is affected. 22. Launch. (Location 663)
Build something you can manage If you launch an affiliate program do you have the systems in place to handle the accounting and payouts? Maybe you should just let people earn credit against their membership fees instead of writing, signing, and mailing a check each month. (Location 667)
Bottom line: Build products and offer services you can manage. It’s easy to (Location 670)
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. (Location 671)
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. (Location 674)
Let your customers remind you what’s important 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. (Location 685)
But, as we mentioned before, your first response should be a no. 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. (Location 690)
And one more thing: 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. (Location 700)
Work 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. (Location 744)
You don’t need to aim for perfection on the first try if you know it’s just going to be done again later anyway. (Location 749)
Unfortunately, we’re terrible at planning ahead, at understanding the ramifications of our actions and in prioritizing the stuff that really matters. (Location 755)
Brainstorm Come up with ideas. What is this product going to do? (Location 765)
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. (Location 768)
Paper sketches 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. (Location 771)
Avoid Preferences Decide the little details so your customers don’t have to (Location 782)
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. It may seem like you’re doing them a favor but you’re just making busy work for them (Location 785)
(and it’s likely they’re busy enough). For customers, preference screens with an endless amount of options are a headache, not a blessing. Customers shouldn’t have to think about every nitty gritty detail – don’t put that burden on them when it should be your responsibility. (Location 787)
create more software. More options require more code. And there’s all the extra testing and designing you need to do too. You’ll also wind up with preference permutations and interface screens that you never even see. That means bugs that you don’t know about: broken layouts, busted tables, strange pagination issues, etc. (Location 789)
It turns out that preferences have a cost. (Location 797)
Decisions are temporary so make the call and move on 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. (Location 803)
Instead, 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. (Location 808)
Test your app via real world usage There’s no substitute for real people using your app in real ways. Get real data. Get real feedback. Then improve based on that info. Formal usability testing is too stiff. (Location 824)
Instead, release beta features to a select few inside the real application itself. Have them use the beta features alongside the released features. This will expose these features to people’s real data and real workflow. And that’s where you’ll get real results. (Location 829)
Further, 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. (Location 831)
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 (Location 844)
Break it down Estimates that stretch into weeks or months are fantasies. The truth is you just don’t know what’s going to happen that far in advance. So shrink your time. 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. (Location 851)
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.” (Location 863)
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. (Location 907)
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. (Location 909)
Release something today The most important thing in software development is motivation. 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. In fact, it’s probably going to suck. (Location 946)
When you find those 4-hour quick wins, you’ll find celebration. That builds morale, increases motivation, and reaffirms that the team is headed in the right direction. (Location 955)
Design the interface before you start programming Too many apps start with a program-first mentality. That’s a bad idea. Programming is the heaviest component of building an app, meaning it’s the most expensive and hardest to change. Instead, start by designing first. (Location 1067)
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. (Location 1072)
Having most of the UI designed up front was extremely beneficial on several levels. First, it gave Scott a real vision and excitement for where we were going. It was much more than just an idea, it was real. (Location 1084)
Start from the core of the page and build outward 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. (Location 1092)
Design for regular, blank, and error states For each screen, you need to consider three possible states: (Location 1107)
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 (Location 1127)
screen look once it’s full? Set expectations and help reduce frustration, intimidation, and overall confusion. (Location 1132)
Remember: Your app may work great 90% of the time. But if you abandon customers in their time of need, they’re unlikely to forget it. (Location 1148)
That’s why context is more important than consistency. It’s OK to be inconsistent if your design makes more sense that way. Give people just (Location 1154)
what matters. Give them what they need when they need it and get rid of what they don’t. It’s better to be right than to be consistent. (Location 1155)
To avoid crappy-admin-screen syndrome, don’t build separate screens to deal with admin functions. Instead, build these functions (i.e. edit, add, delete) into the regular application interface. (Location 1179)
Keep your code as simple as possible You’d think that twice as much code would make your software only twice as complex. But actually, each time you increase the amount of code, your software grows exponentially more complicated. Each minor addition, each change, each interdependency, and each preference has a cascading effect. Keep adding code recklessly and, before you know it, you’ll have created the dreaded Big Ball of Mud. (Location 1196)
Fears you have about tomorrow often never come to fruition. Don’t bog yourself down trying to solve these phantom issues. (Location 1204)
Less software means less support. Which features you choose to include or omit have a lot to do with less software too. (Location 1213)
For every feature that makes it into your app, ask yourself: Is there a way this can be added that won’t require as much software? (Location 1222)
The kinds of engineers you want The number one reason I wanted to build our app using Ruby on Rails is that it is so elegant, productive, and beautifully designed. It tends to attract the kind of engineers who care about just those sort of things...those are exactly the kinds of engineers you want on your team because they create the kind of beautiful, elegant and productive software you need to win the market.” (Location 1243)
Don’t worry about design, if you listen to your code a good design will appear...Listen to the technical people. If they are complaining about the difficulty of making changes, then take such complaints seriously and give them time to fix things. (Location 1256)
Pay off your code and design “bills” We usually think of debt in terms of money but it comes in other forms too. You can easily build up code and design debt. (Location 1264)
Hack together some bad code that’s functional but still a bit hairy and you’re building up debt. Throw together a design that’s good enough but not really good and you’ve done it again. It’s OK to do this from time to time. In fact, it’s often a needed technique that helps you do the whole Get-Real-ASAP-thing. But you still need to recognize it as debt and pay it off at some point by cleaning up the hairy code (Location 1266)
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. (Location 1348)
No One’s Going to Read It I can’t even count how many multi-page product specifications or business requirement documents that have languished, unread, gathering dust nearby my dev team while we coded away, discussing problems, asking questions and user-testing as we went. (Location 1350)
Webapps don’t move forward with copious documentation. Software development is a constantly shifting, iterative process that involves interaction, snap decisions, and impossible-to-predict issues that crop up along the way. None of this can or should be captured on paper. Don’t waste your time typing up that long visionary tome; no one’s going to read it. Take consolation in the fact that if you give your product enough room to grow itself, in the end it won’t resemble anything you wrote about anyway. (Location 1353)
Write stories, not details 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. (Location 1359)
You need real copy to know how long certain fields should be. You need real copy to see how tables will expand or contract. You need real copy to know what your app truly looks like. (Location 1372)
Soften the blow of bad news with advance notice and grandfather clauses 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. (Location 1441)
To build up buzz and anticipation, go with a Hollywood-style launch: 1) Teaser, 2) Preview, and 3) Launch. (Location 1457)
Blogging can be more effective than advertising (and it’s a hell of a lot cheaper) (Location 1505)
Share your knowledge with the world When a teacher (Location 1521)
As a promotional technique, education is a soft way to get your name – and (Location 1525)
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. (Location 1525)
Teaching is all about good karma. You’re paying it forward. You’re helping others. You get some healthy promotion. And you can even bask in a bit of nobility. So what do you know that the world wants to hear about? (Location 1537)
They’re hungry for it so serve it up New or interesting features are a great way to generate buzz for your application. (Location 1555)
But if you are using something new or noteworthy, go ahead and spotlight it for special interest groups. (Location 1565)
It’s amazing how much a thoughtful comment on a blog can diffuse naysayers and even turn complainers into evangelists. (Location 1575)
Promote upgrade opportunities inside the app 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. (Location 1578)
Tell folks that you’ll remove barriers if they upgrade. For example, in Basecamp you can’t upload files if you have a free account. When someone tries to upload a file, we don’t just turn them away. (Location 1580)
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. (Location 1654)
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. (Location 1671)
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. (Location 1708)
Show your product is alive by keeping an ongoing product development blog post-launch 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). (Location 1716)
A frequently-updated product blog is the best indicator that a webapp is in active development, that it’s loved and that there’s a light on at home. An abandoned product blog is a sign of an abandoned product, and says the people in charge are asleep at the (Location 1725)
wheel. Keep the conversation going with your users on your product blog, and be transparent and generous with the information you share. Let your company’s philosophies shine through. Openly link and discuss competitors. Hint at upcoming features and keep comments open for feedback. (Location 1727)
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. (Location 1739)
Prioritize your bugs (and even ignore some of them) Just because you discover a bug in your product, doesn’t mean it’s time to panic. All software has bugs – it’s just a fact of life. 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. (Location 1748)
And remember what we said earlier about the importance of honesty. If customers complain about a bug, be straight up with them. Tell them you’ve noted the issue and are dealing with it. (Location 1757)
If it won’t be addressed right away, tell (Location 1758)
why and explain that you’re focusing on areas of the product that affect a greater number of people. Honesty is the best policy. (Location 1759)
Also, remember that negative reactions are almost always louder and more passionate than positive ones. In fact, 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. (Location 1767)
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. (Location 1777)
come up with an idea. Everyone has a cousin that’s a web designer. Everyone can write a blog. Everyone can hire someone to hack together some code. The difference between you and everyone else will be how well you execute. Success is all about great execution. (Location 1801)
You need people who are passionate about what they do. People who care (Location 1810)
about their craft – and actually think of it as a craft. People who take pride in their work, regardless of the monetary reward involved. People who sweat the details even if 95% of folks don’t know the difference. People who want to build something great and won’t settle for less. (Location 1811)