bookshelf
Getting Real:The smarter, faster, easier way to build a successful web application
#1 Getting Real is a better, smaller, and faster way to build software.
You start building what the user sees and then work backward.
It’s an iterative process focusing on delivering only what the user needs and eliminating what they don’t need
#2 Underdo your competition
common sense dictates that to beat your competition, you need to do more. Ship more features, spend more, hire more etc.
This is an expensive, defensive, and paranoid way of building products.
Solve the simple problems
#3 Less is more
Less:
- features
- options/preferences
- people and corporate structure
- meetings and abstractions
- promises
This way you can adapt quickly, focus on the good ideas while dropping the bad ones. You can listen to your customers and understand their needs
#4 Build Software For Yourself
Start by solving your own problems. You’ll be the target audience and you’ll be able to tell what matters and what doesn’t
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.
Scratch your own itch
#5 Outside Money is Plan B
Raising money from investors means you’ll need to answer to them and expectations are raised.
Think hard and determine what’s really essential and what you can do without.
#6 constraints force creativity, embrace them
Having limited resources forces you to work with what you got, to adapt and to deliver sooner.
delivering sooner will allow you to know if your idea has potential or not. If it doesn’t, back to the drawing board. If it does, you’ll be self sustainable shortly
#7 Have a fixed budget and 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
This way you set realistic expectations and know what to prioritize
It’s better to make half a product than a half-assed product
#8 Sometimes the best way to know what your app should be is to know what it shouldn’t be.
Having an enemy is a clear marketing message.
People love conflict and understand a product by comparing it to others. Eventually, they’ll pick sides
#9 Be excited about building your app
The less your app is a chore to build, the better it will be. Keep it small and manageable so you can actually enjoy the process. If your app doesn’t excite you, something’s wrong
#10 Make change easier
If a change is expensive, it’s unlikely you’ll make it.
If your competitors can change faster than you, they have a huge advantage over you.
#11 Use a team of 3 for V1
A Developer, A designer and a sweeper (somewhere that can both design and code)
If you can’t build your V1 with 3 people, then you either need different people or you need to slim down your initial version.
Small teams move fast.
#12 Personality as an advantage
Smaller companies are closer to the customers and can communicate in a more personal way.
Being small makes internal communication easier as well.
You can ditch the formalities and the bureaucracy.
Everyone can speak openly and honestly
#13 Define the one-point vision for your app
What’s the vision? Why does it exist? what makes it different?
Answering these questions will help you in maintaining a consistent path and will guide you in your decision making.
The vision should also be brief
#16 Don’t obsess over the details early onIt can greatly slow down your progress
There’s plenty of time to be a perfectionist. Just do it later.
Details reveal themselves as you use what you’re building. You’ll see what needs more attention. You’ll feel what’s missing.
#17 Don’t waste time on problems you don’t have yet
Don’t overbuild or try to handle 100k users when it will take you 2 years to get there
Make decisions just in time, when you have access to the real information you need.
#18 If you try to please everyone, you won’t please anyone
Focusing on a narrow market allows you to easily identify which features would be useful and which ones won’t.
It’s also likely to attract passionate customers who would promote your product in the future
#19 Your app should take sides
Don’t try to be all things to all people.
Seek out customers who are actually partners.
Speak to people who share your vision.
A customer is either on the bus or off the bus
#20 Build half a product, not a half-assed product
Do one thing very well, instead of many things poorly
Stick to what’s truly essential.
Take whatever you think your product should be and cut it in half.
What you really want to do is build half a product that kicks ass.
#21 Make features work hard to be implemented
Don’t try to build every feature you can think of/or that is suggested.
Let features go through a lengthy process to make sure they’re essential.
This way you don’t waste your time, energy and money
#22 Expose the price of new features
examine a possible new feature closely, and analyze how much effort it would take to implement. It’s not just about design/code.
A feature may also affect marketing copy, terms of service, product’s pricing, etc.
You may find that a “simple” feature will result in a major headache.
#23 Let Customers remind you what’s important
Customers want everything.
you’ll be given a huge list of feature requests. It can be overwhelming to keep track of everything.
Forget the list and focus on the things that customers keep asking for over and over again
#24 Ask people what they don’t want
“If you could remove one feature, what would it be?”
“What don’t you use?”
“What gets in your way the most?”
More isn’t the answer. Sometimes the biggest favor you can do for customers is to leave something out
#25 Get something real up and running quickly
It’s hard for people to agree when everything is on paper.
Each one will throw ideas and keep making sketches.
Having a real product allows teams to reach agreement faster.
#26 Work in iterations
You won’t get it right the first time.
Build and analyze. See what’s working and see what’s not.
You don’t need to be perfect, you need to get started.
#27 Wireframe > UI > Logic
start with rough sketches, to generate ideas
Build a static UI (HTML & CSS), to see what the result will look like
Code it that’s where you make it work
go through this cycle multiple times
#28 Avoid preferences
“should we display 25 products to users? 50? You know what let’s give them the choice”
People don’t like making decisions, it’s a headache, not a blessing
Make simple decisions on behalf of your customers, if they don’t like them they’ll let you know.
#29 Decisions are temporary so make the call and move on
what if you screw up and make the wrong call? It’s ok. This isn’t brain surgery, it’s a an app
value the importance of moving on and moving forward.
Be constantly in motion
#30 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.
#31 release beta features to a select few inside the real application itself
Don’t have a release version and a beta version. They should always be the same thing
This way you get real data about your app.
example: GitHub’s feature preview option
#32 Shrink Your Time
Set small, realistic timeframes for small, manageable tasks
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.
#33 Unity
Make sure there’s a back and forth between different teams.
Marketing should work with design, design with dev, dev with support, etc.
You don’t want teams to live in their own little world instead of the entire context of the app
#34 People need uninterrupted time to get things done
give up instant messaging, phone calls, and meetings.
interruption is your enemy. The alone time is where real progress is made.
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).
#35 Don’t have meetings
Every minute you avoid spending in a meeting is a minute you can get real work done instead.
Your day turns into small pieces and your natural workflow is disrupted
They’re usually about abstract concepts, not real things (like code or UI)
#36 in case it’s necessary to have a meeting
- Set a 30 minute timer. When it rings, meeting’s over. Period.
- Invite as few people as possible.
- Never have a meeting without a clear agenda.
#37 Release something today
Long, drawn out release cycles are motivation killers. They insert too much time between celebrations. On the other hand, quick wins that you can celebrate are great motivators.
Thoughts about Hiring people
- don’t hire many people early
- give employees small project to chew on first. We see how they handle the project, how they communicate, how they work,etc.
- Open source is a great way to judge potential hires
- Go for quick learning generalists over ingrained specialists
- Hire good writers. Good writers know how to communicate. They make things easy to understand. They can put themselves in someone else’s shoes. They know what to omit. They think clearly. And those are the qualities you need.
#38 design the UI before coding it
You can see how the app looks and feels, and how everything fits together
It’s easy to change a design
It’s hard and expensive to change code.
design is flexible, programming first is not
#39 Design the core feature first, then build around it
This allows you to to focus on what really matters on day one.
Essentials first, extras second.
#40 Design for regular, blank, and error states
For each screen, you need to consider 3 possible states:
- Regular: everything’s working fine and data is loaded
- Blank: when using the app for the first time and data isn’t loaded yet
- Error: when something goes wrong.
#41 Design a a helpful blank slate
During this stage, users build the first impression.
insert quick tutorials
add a sample screenshot after populating the UI with data
answer key questions like: what is this page? What do I do now?
#42 invest in copywriting
every letter matters
You need to speak the same language as your audience too
Keep it short and sweet. Say what you need to and no more.
Good writing is good design.
#43 Keep your code as simple as possible
Less software is easier to manage. Less software reduces your codebase and that means less maintenance busywork (and a happier staff). Less software lowers your cost of change so you can adapt quickly.
#44 Choose tools that keep your team excited and motivated
A happy programmer is a productive programmer. your team needs to work with tools they love.
frameworks, programming languages, etc. choose wisely
#45 Eliminate unnecessary paperwork
Build, don’t write. If you need to explain something, try mocking it up and prototyping it rather than writing a longwinded document.
Documents that live separately from your application are worthless.
#46 Write stories, not details
Sometimes the best way to explain a concept or a new feature is by telling a story.
#47 What is your product’s personality type?
Picking a personality for your product will guide the copywriting, the interface and the features
Your product has a voice — and it’s talking to your customers 24 hours a day.
insert 2 pictures comparing personaility
#48 Give something away for free
freebies, free trials, free versions can make users experience the product, interface and how useful it is. Once they’re hooked, it’s likely they’ll upgrade
#49 Make signup a painless process
If users can experience the benefits of your app without needing to sign up, you have a huge advantage.
only ask for info when you need it
#50 Make cancellation a painless process
give users the option to delete their accounts without needing to fill forms or answer questions
also allow them to export their data and info, it’s theirs
#51 Epic launch
no one will use your app if no one knows about it
follow the Hollywood style launch:
Teaser
preview
launch
create a teaser, let people what know what you’re working on. Stay vague but plant the seed. This will spark people’s interest
A few weeks ahead of launch, start previewing features. Give people behind-the-scenes access. Share your product’s personality with your audience.
encourage people to sign up to know when the product launches. These will be your beta testers
On release day, spread the word, send emails to those who signed up, document your journey, share your progress.
setup a promotional website:
#52 Blogging as an advertising tool
advertising is expensive, blogging is not.
write blog posts that provide tips, tricks, links, etc. and point to your product
#53 Track who’s talking about you
engage with people who love your product and pay attention to the critics.
#54 Promote upgrade opportunities inside the app
If your app offers a tiered pricing plan, make sure you let users know the benefits of upgrading.
if there’s a premium feature don’t hide it, let users use it first and then tell them about the the upgrade
#55 pick a memorable name for your app
The name doesn’t have to be descriptive, just make sure it’s short and catchy.
And don’t sweat it if you can’t get the exact domain name you want.
#56 Tear down the walls between support and development
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.
understand what they like/dislike
#57 Strive to build a tool that requires zero training.
You don’t need a manual to use google or amazon. Keep things simple.
At points of confusion, use inline help and faqs here’s an example from google docs:
#58 Quick turnaround time on support queries should be a
top priority
people LOVE fast customer support.
If there’s an issue that can’t be immediately fixed, let them know. Answers don’t have to be perfect. Just honest and genuine.
#59 Be willing to say no to your customers
When it comes to feature requests, the customer is not always right. If we added every single thing our customers requested, no one would want our products.
#60
Forums and web-based group chat are a great way to let customers ask questions and help one another out. By eliminating the middleman — that’s you — you provide an open stream of communication and save yourself time in the process.
#61 Get bad news out there and out of the way
If something goes wrong, tell people. Even if they never saw it in the first place.
Be as open, honest, and transparent as possible.
Found this article useful? Make sure you share it with other people on Twitter