Get latest articles directly in your inbox
These are highlights/notes from book “Getting Real: The Smarter, Faster, Easier Way to Build a Successful Web Application” by Jason Fried and David Heinemeier Hansson.
These are my personal notes/highlights which I took while reading. I would recommend reading the book, but in case you are short on time - just skim through these notes 😊
You can checkout the digital version here.
In case you are looking for book recommendations! Check Learnshots
One-upping Cold War mentality is a dead-end. It’s an expensive, defensive, and paranoid way of building products
Solve the simple problems and leave the hairy, difficult, nasty problems to everyone else. Try one-downing.
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’re not alone, many folks might face similar problems.
Passion is key. Passion means you’ll truly use it and care about it.
If you’re going to live with something for two years, three years, the rest of your life, you need to care about it.
Constraints drive innovation. Do more with less. (Bootstrap)
Focus on building a quality tool that you and your customers can live with for a long time.
Fix time and budget and launch on time.
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.
Find out what’s really important
Scope down
Be flexible
Find competitors. Make your product anti-competitor. Don’t stress over it. Use your own ideas and build.
Don’t follow the leader.
Keep your app small and manageable.
Be flexible - change must be easy. You can react and evolve. If your competitors can change faster than you, you’re at a huge disadvantage.
Team of three for v1. Start with a developer, a designer and a both world guy (Full stack). Talented people don’t need endless resources.
Metcalfe’s Law, that “the value of a communication system grows at approximately the square of the number of users of the system,”
Constains are good. Work with what you have!
Be yourself. Stay close to customers, their requirements and feedbacks.
What the vision of your product? Before coding, find that! How it is different? Why is this required!
Don’t be a perfectionist at the start. You’ll have lot of time later. In the beginning, make building a solid core product your priority instead of obsessing over scalability and server farms.
Don’t waste time on problems you don’t have right now. Eg. Scalability, etc. Just let the product out. Iterate later. Don’t overbuild. Make timely decisions and stick by them.
Find right customers for your app. Target a specific group. Don’t go chasing people you’ll never make happy.
Take whatever you think your product should be and cut it in half. - Remove features down until you’re left with only the most essential ones.
Do the essentials first. Avoid stuff that doesn’t really matters. If it will really matter - you can always add it later based on feedbacks.
Say no to features. Listen to all but don’t act quickly. Analyse and decide what’s most important thing you need right now.
For every new feature -
Say no.
Force the feature to prove its value.
If “no” again, end here. If “yes,” continue…
Sketch the screen(s)/ui.
Design the screen(s)/ui.
Code it.
Test, tweak, test, tweak, test, tweak, test, tweak…
Check to see if help text needs to be modified.
Update the product tour (if necessary).
Update the marketing copy (if necessary).
Update the terms of service (if necessary).
Check to see if any promises were broken.
Check to see if pricing structure is affected.
Launch.
Hold breath
It’s easy to make promises. It’s much harder to keep them. Do something you can actually sustain — organizationally, strategically, and financially.
If a feature is really worth remembering, they’ll remind you until you can’t forget.
Get something real up and running quickly! Real things lead to real reactions.
Let the app grow and speak to you. Let it morph and evolve.
Idea to Implementation - 4 steps
Brainstorm - High level ideas
Sketches - rough designs on paper
Create html versions for same (No code/logic)
Code it
Give options to use from. Don’t fix/decide, let customers choose. Make simple decisions - don’t add option for everything
Accept that decisions are temporary. Execute, build momentum, and move on.
Ideas are worthless, execution is everything
Release beta. Test in public! Two benefits -
Customers get this product which solves their problems
You get vital feedback to improve on.
Smaller tasks and timelines. (KISS soft. principle for products)
Solve problem standing in your face. Don’t think about 20 problems at a time.
hire people with multiple talents who can wear different hats during development.
Most work is done when you are alone.
The goal is to avoid meetings. Every minute you avoid spending in a meeting is a minute you can get real work done instead. 3 Meeting rules -
Meeting <= 30 minutes.
Less people -> better meeting
Have a clear agenda.
Long, drawn out release cycles are motivation killers. Celebrate small achievements! This keeps you motivated.
Avoid hiring more and more people. You don’t need as many people as you think.
Brooks’ law - Adding people to a late software project makes it later.
Before hiring anyone - give them a small project to chew on first.
OSS is a great way to judge technical skills
Quality of work
Cultural perspective
Level of passion
Completion percentage
Social match
People who love to program and get things done are exactly the kind of people you want on your team.
Always hire the better writer.
Good writers know how to communicate. They make things easy to understand. They think clearly.
Start by designing first - simple paper sketches. designs are still relatively simple to modify
Essentials first, extras second. Design core screens first.
For each screen, design three states -
Regular
Blank - the natural state of the app is one that’s devoid of data. When someone signs up, they start with a blank slate.
Error - there will always be errors!
Context is more important than consistency. Give people just what matters
Good writing is good design. Eg. Icons with names, form fields with examples, buttons with labels, step by step instructions in a process, a clear explanation of your refund policy. These are all interface design.
Have same interface for admin and regular flows.
Less software means less features, less code, less waste.
Secret to good software design is knowing what to leave out.
Regularly put aside some time to pay off your code and design debt.
Give people information they need via APIs, RSS, etc.
Avoid unnecessary documents. Build, don’t write.
Write stories and flow of what happens.
Use actual text in copies (avoid lorem ipsum, etc)
You need real copy to know what your app truly looks like. Do as your customers do and you’ll understand them better.
Give something away for free.
Devise specialized, smaller offerings to get customers to bite.
Make signup and cancellation a painless process.
Provide a big, clear, signup button that pops and put it on each page of your marketing site
There should always be a free option so customers can demo the app
Keep the signup form as short as possible
The same principles hold true for the cancellation process.
Giving people control over their information builds trust.
Don’t hold users against their will.
Keep billing simple, don’t try to trick them to earn more. That will harm more than you will gain in longer term.
Teaser -> Preview -> Launch
Teaser - Post a logo, some memes, blog.
Preview - clip of product features. describe theme and ideas behind product. Offer early access. Beta test.
Launch - emails, marketing, blogs to link you., social media
Create a blog, keep updating with new posts.
Get some sort of site up and start collecting emails as soon as possible.
New or interesting features are a great way to generate buzz for your application
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. Explain why upgrading is a good idea.
Name is important. Keep it small, easy to remember and catchy. But don’t sweat over it.
Don’t outsource customer support to a call center or third party. Do it yourself. It’s important to understand why your customer needs something, not just what it is they need
Strive to build a tool that requires zero training. Add Faq, product tour, etc.
Customers light up when you answer their questions quickly. Response time should be minimal.
Customers don’t expect your product to be perfect and they don’t expect that all of their features will be implemented. However, customers do expect that you are listening and acknowledging that you care,
Not everything everyone suggests is the right answer.
If something goes wrong, tell people.Be as open, honest, and transparent as possible.
Things to blog about-
Faq
How-tos
Tips & tricks
New features, updates, & fixes
Buzz/press
Private betas are fine, public betas are bullshit
Prioritize your bugs. Don’t panic and get to fixing it straightaway. All software has bugs.
Negative reactions are almost always louder and more passionate than positive ones. Stay calm!
Subscribe and get updates from your competitors.
Be open to new paths and changes.
Success is all about great execution.
More book summaries
I hope you learned something new. Feel free to suggest improvements ✔️
I share regular updates and resources on Twitter. Let’s connect!
Keep exploring 🔎 Keep learning 🚀
Liked the content? Do support :)
Explore more
Support me