ºÝºÝߣ

ºÝºÝߣShare a Scribd company logo

How to build a great Web Application - Lessons from Getting Real by 37 Signals

?
?
Robin Dhanwani
Robin Dhanwani

Ideas are many but execution is the key. Recently I came across the book "Getting Real" from 37 signals, it was a new way to look at building products hence would like to share lessons learnt from it.

1 of 17
How to build a great Web Product Lessons from Getting Real, a book by 37 signals @robindhanwani
Its about Skipping Charts, Graphs, boxes, arrows, schematics and wireframes. and actually building the real thing.
Have less of everything that is essential, less features, less paperwork, less of everything that¡¯s not essential Many times we try to add every new feature, add processes, systems and everything we can think of and most of the times times it complicates things and is not needed.
Just give what customers need and remove everything else. We build on assumptions what customers need and most of the times its not the case, so build only what they need. If they need something more, they will let you know.
Launch early, tweak and constantly improve. Follow Agile Development Methodology with incremental and iterative development. Take feedback, collaborate and keep improvising the product.
Get Rid Of ... Scalability Debates Useless Meetings Endless Preference Options Lengthy Functional Specs Timelines that take Months or Years Top Down Hierarchy Useless Paperwork
Do Less¡­ We believe software is too complex. 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. What can you do with - 3 people instead of ten - in 3 months instead of six - in 20k instead of 100k
Don¡¯t compete with competitors on: - Money Spent - Features - Time Size Instead of one upping, try one-downing. Instead of outdoing, try underdoing. - Less features - Less options/preferences - Less people and corporate structure - Less meetings and abstractions - Less promises
Find out why do you want to do it ? Is it a problem you are facing, something you are really passionate about or something else. Its better to find out coz this is what will help you keep going!!
Outside Money is Plan B - If you turn to outsiders, you will have to answer them too. - These days hardware isn¡¯t expensive and plenty of great s/w is open source. - Constraints force creativity
Fix Time and Budget, Flex Scope There's a myth that goes like this: we can launch on time, on budget, and on scope. It almost never happens and when it does quality often suffers. Benefits of doing this: - Prioritization - Flexibility - Reality
Have an Enemy - Find your app¡¯s enemy and what u don¡¯t wanna build - At same time, don¡¯t overanalyze other products, it might limit the way you think. Take a look and move on with ur vision.
The Three Musketeers Use a team of three for version 1.0. Start with a developer, a designer, and a sweeper (someone who can roam between both worlds).
If you try to please everyone, you won¡¯t please anyone So, identify your target audience
Ignore Details Early On Work from Large to Small Success and satisfaction are in the details. However, success isn't the only thing you'll find in the details. You'll also find stagnation, disagreement, meetings, and delays. These things can kill morale and lower your chances of success.
Support Feel the Pain of your customers. 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.
It¡¯s a nice read and great lessons, go read it yourself: Getting Real

More Related Content

How to build a great Web Application - Lessons from Getting Real by 37 Signals

  • 1. How to build a great Web Product Lessons from Getting Real, a book by 37 signals @robindhanwani
  • 2. Its about Skipping Charts, Graphs, boxes, arrows, schematics and wireframes. and actually building the real thing.
  • 3. Have less of everything that is essential, less features, less paperwork, less of everything that¡¯s not essential Many times we try to add every new feature, add processes, systems and everything we can think of and most of the times times it complicates things and is not needed.
  • 4. Just give what customers need and remove everything else. We build on assumptions what customers need and most of the times its not the case, so build only what they need. If they need something more, they will let you know.
  • 5. Launch early, tweak and constantly improve. Follow Agile Development Methodology with incremental and iterative development. Take feedback, collaborate and keep improvising the product.
  • 6. Get Rid Of ... Scalability Debates Useless Meetings Endless Preference Options Lengthy Functional Specs Timelines that take Months or Years Top Down Hierarchy Useless Paperwork
  • 7. Do Less¡­ We believe software is too complex. 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. What can you do with - 3 people instead of ten - in 3 months instead of six - in 20k instead of 100k
  • 8. Don¡¯t compete with competitors on: - Money Spent - Features - Time Size Instead of one upping, try one-downing. Instead of outdoing, try underdoing. - Less features - Less options/preferences - Less people and corporate structure - Less meetings and abstractions - Less promises
  • 9. Find out why do you want to do it ? Is it a problem you are facing, something you are really passionate about or something else. Its better to find out coz this is what will help you keep going!!
  • 10. Outside Money is Plan B - If you turn to outsiders, you will have to answer them too. - These days hardware isn¡¯t expensive and plenty of great s/w is open source. - Constraints force creativity
  • 11. Fix Time and Budget, Flex Scope There's a myth that goes like this: we can launch on time, on budget, and on scope. It almost never happens and when it does quality often suffers. Benefits of doing this: - Prioritization - Flexibility - Reality
  • 12. Have an Enemy - Find your app¡¯s enemy and what u don¡¯t wanna build - At same time, don¡¯t overanalyze other products, it might limit the way you think. Take a look and move on with ur vision.
  • 13. The Three Musketeers Use a team of three for version 1.0. Start with a developer, a designer, and a sweeper (someone who can roam between both worlds).
  • 14. If you try to please everyone, you won¡¯t please anyone So, identify your target audience
  • 15. Ignore Details Early On Work from Large to Small Success and satisfaction are in the details. However, success isn't the only thing you'll find in the details. You'll also find stagnation, disagreement, meetings, and delays. These things can kill morale and lower your chances of success.
  • 16. Support Feel the Pain of your customers. 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.
  • 17. It¡¯s a nice read and great lessons, go read it yourself: Getting Real