Getting real - The smartest, fastest, easiest way to build a successful web application
How much do I want to read more? 8/10
What I love about this book is its paradoxical approach. It shows our common thoughts and beliefs are actually stupid in many ways, and the opposite becomes common sense reading this book.
The book itself breath with its inner philosophy: short, concise, no bullshit. Every paragraph brings its insight and shall not be removed.
Getting Real is about skipping all the stuff that represents real (charts, graphs, boxes, arrows, schematics, wireframes, etc.) and actually building the real thing.
Getting real is less. Less mass, less software, less features, less paperwork, less of everything that’s not essential (and most of what you think is essential actually isn’t).
Getting Real is staying small and being agile.
It begins with what the customer actually experiences and builds backwards from there.This lets you get the interface right before you get the software wrong.
Getting Real is about iterations and lowering the cost of change. Getting Real is all about launching, tweaking, and constantly improving.
it forces you to deal with the actual problems you’re trying to solve instead of your ideas about those problems. It forces you to deal with reality.
Getting Real gets rid of…
- Timelines that take months or even years
- Pie-in-the-sky functional specs
- Scalability debates
- Interminable staff meetings
- The “need” to hire dozens of employees Meaningless version numbers
- Pristine roadmaps that predict the perfect future Endless preference options
- Outsourced support
- Unrealistic user testing
- Useless paperwork
- Top-down hierarchy
In this book we’ll show you…
- The importance of having a philosophy Why staying small is a good thing
- How to build less
- How to get from idea to reality quickly How to staff your team
- Why you should design from the inside out Why writing is so crucial
- Why you should underdo your competition
- How to promote your app and spread the word
- Secrets to successful support
- Tips on keeping momentum going after launch
Our modus operandi
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.
Ruby on Rails
Rails takes care of the busy work so you can focus on your idea.
“Ruby on Rails is astounding. Using it is like watching a kung-fu movie, where a dozen bad-ass frameworks prepare to beat up the little newcomer only to be handed their asses in a variety of imaginative ways.”
The Starting Line
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.
What’s Your Problem?
Build software for yourself
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.
The Open Source world embraced this mantra a long time ago – they call it “scratching your own itch.” For the open source developers, it means they get the tools they want, delivered the way they want them.
As the designer or developer of a new application, you’re faced with hundreds of micro-decisions each and every day: blue or green? One table or two? Static or dynamic? Abort or recover? How do we make these decisions? If it’s something we recognize as being important, we might ask.The rest, we guess.And all that guessing builds up a kind of debt in our applications – an interconnected web of assumptions.
As a developer, I hate this.The knowledge of all these small-scale timebombs in the applications I write adds to my stress. Open Source developers, scratching their own itches, don’t suffer this. Because they are their own users, they know the correct answers to 90% of the decisions they have to make. I think this is one of the reasons folks come home after a hard day of coding and then work on open source: It’s relaxing.
Born out of necessity.
You need to care about it
When you write a book, you need to have more than an interesting story. You need to have a desire to tell the story.You need to be personally invested in some way. If you’re going to live with something for two years, three years, the rest of your life, you need to care about it.
-- Malcolm Gladwell
Outside money is plan B
remember, if you turn to outsiders for funding, you’ll have to answer to them too.
hink hard and determine what’s really essential and what you can do without.
What can you do in three months instead of six? What can you do if you keep your day job and build your app on the side?
Constraints force creativity
Run on limited resources and you’ll be forced to reckon with constraints earlier and more intensely. And that’s a good thing. Constraints drive innovation.
Constraints also force you to get your idea out in the wild sooner rather than later – another good thing.
A month or two out of the gates you should have a pretty good idea of whether you’re onto something or not. If you are, you’ll be self-sustainable shortly and won’t need external cash. If your idea’s a lemon, it’s time to go back to the drawing board. At least you know now as opposed to months (or years) down the road. And at least you can back out easily. Exit plans get a lot trickier once investors are involved.
Fix Time and Budget, Flex Scope
Launch on time and on budget
There’s a myth that goes like this: to launch on time, on budget almost never happens and when it does quality often suffers.
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 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. Leave the magic to Houdini. You’ve got a real business to run and a real product to deliver.
ou have to figure out what’s really important.What’s going to make it into this initial release? This forces a constraint on you which will push you to make tough decisions instead of hemming and hawing.
Setting expectations is key. Is what you deliver really is “something” what you really want to deliver?
The ability to change is key. Having everything fixed makes it tough to change.
Our recommendation: Scope down. It’s better to make half a product than a half-assed product
Have an Enemy
Pick a fight
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.
When we decided to create project management software, we knew Microsoft Project was the gorilla in the room. Instead of fearing the gorilla, we used it as a motivator. We decided Basecamp would be something completely different.
When it came to Writeboard, we knew there were competitors out there with lots of whizbang features. So we decided to emphasize a “no fuss” angle instead. We created an app that let people share and collaborate on ideas simply, without bogging them down with non-essential features. If it wasn’t essential, we left it out. And in just three months after launch, over 100,000 Writeboards have been created.
One bonus you get from having an enemy is a very clear marketing message.
Don’t 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.
-- Seth Godin
What’s the key problem?
One of the quickest ways to get yourself into trouble is to look at what your competitors are doing.This has been especially true for us at BlinkList. Since we launched there have been about 10 other social bookmarking services that have been launched. Some people have even started to generate spreadsheets online with a detailed feature by feature comparison.
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.
-- Michael Reining (MindValley & Blinklist)