Getting Real

#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


  • 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

seth godin quote on telling a different story than the competition

#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.

diagram showing how it's hard to communicate when you have a large team

#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

visions of different companies

#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

Don't build every feature, focus on what makes you stand out

#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

ideas don't matter,focus on execution

#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.

if you can't give an accurate estimate say I don't know

#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?

upwork blank slate

#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:




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:

promotional website tips like adding the manifesto, buzz, case studies, app tour

#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:

Google docs inline tooltip

#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.


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.

Be swift direct and honest

Found this article useful? Make sure you share it with other people on Twitter

Follow along

If you want to know about any new posts or any thing I'm working on make sure you subscribe!