‘Getting Real’ …….know reality before you start a company
‘Getting real’………a really good book written by 37signal . I recommend to read this book to every who want ot start a company and who already started. So what special in this book? The author tell you the actuall process of web development and how to be best and different in competitive world. Theory not work always…….therefore instead of reading lots of software engineering books which tells thousands rule to follow during development process, get real.Here I listed some points from this book that I liked…….
Getting real is less. Less mass, less software, less features, less paperwork, less of everything that’s not essential
When there’s too many people involved, nothing gets done. The leaner you are, the faster — and better — things get done.
Ship less features, but quality features.
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.
The answer is less. Do less than your competitors to beat them. Solve the simple problems and leave the hairy, difficult, nasty problems to everyone else. Instead of oneupping, try one-downing. Instead of outdoing, try underdoing.
- Less features
- Less options/preferences
- Less people and corporate structure
- Less meetings and abstractions
- Less promises
A great way to build software is to start out by solving your own problems. You’ll be the target audience and you’ll know what’s important and what’s not. That gives you a great head start on delivering a breakout product.
The key here is understanding that you’re not alone. If you’re having this problem, it’s likely hundreds of thousands of others are in the same boat. There’s your market. Wasn’t that easy?
When you solve your own problem, you create a tool that you’re passionate about. And passion is key. Passion means you’ll truly use it and care about it. And that’s the best way to get others to feel passionate about it too.
Think hard and determine what’s really essential and what you can do without.
What can you do with three people instead of ten? What can you do with $20k instead of $100k? What can you do in three months instead of six?
If you’re creating software just to make a quick buck, it will show. Truth is a quick payout is pretty unlikely. So focus on building a quality tool that you and your customers can live with for a long time.
Setting expectations is key. If you try to fix time, budget, and scope, you won’t be able to deliver at a high level of quality. Sure, you can probably deliver something, but is “something” what you really want to deliver?
The ability to change is key. Having everything fixed makes it tough to change. Injecting scope flexibility will introduce options based on your real experience building the product. Flexibility is your friend.
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.
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.
When it comes to web technology, change must be easy and cheap. If you can’t change on the fly, you’ll lose ground to someone who can.
Nimble, agile, less-mass businesses can quickly change their entire business model, product, feature set, and marketing message. They can make mistakes and fix them quickly. They can change their priorities, product mix, and focus. And, most importantly, they can change their minds.
Change is your best friend. The more expensive it is to make a change, the less likely you’ll make it. And if your competitors can change faster than you, you’re at a huge disadvantage. If change gets too expensive, you’re dead.
And remember: All the cash, all the marketing, all the people in the world can’t buy the agility you get from being small.
When it comes to web technology, change must be easy and cheap. If you can’t change on the fly, you’ll lose ground to someone who can. That’s why you need to shoot for less mass.
For the first version of your app, start with only three people. That’s the magic number that will give you enough manpower yet allow you to stay streamlined and agile. Start with a developer, a designer, and a sweeper (someone who can roam between both worlds).
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.
