I wish I had read this book sooner when I first started working on TrAvid. I would have avoided lots of mistakes described in the book. My raing 10/10. Definitely recommended for anyone working on websites.
** Support **
- Feel The Pain
Tear down the walls between support and development
listening to customers is the best way to get in tune with your product’s strengths and weaknesses.
Don’t outsource customer support to a call center or third party.
Get the developer to answer support emails.
- Zero Training
Use inline help and FAQs so your product doesn’t require a manual or training
Use tooltip
- Answer Quick
Quick turnaround time on support queries should be a top priority
- Tough Love
Be willing to say no to your customers
Be prepare to say no to feature requests
- In Fine Forum
Use forums or chat to let customers help each other
- Publicize Your Screwups
Get bad news out there and out of the way
Deliver bad news right away. Deliver the good news slowly to keep the good vibes.
** Post-Launch **
- One Month Tuneup
Issue a major update 30 days after launch
This will keep you focus on the core feature set at launch time
Generate the 2nd wave of buzz
- Keep the Posts Coming
Show your product is alive by keeping an ongoing product development blog post-launch
Keep a product update blog
Things to include:
Faqs
How-tos
Tips & tricks
New features, updates, & fixes
Buzz/press
- Better, Not Beta
Don’t use “beta” as a scapegoat
private beta is fine, public beta is bullshit
- All Bugs Are Not Created Equal
Prioritize your bugs (and even ignore some of them)
- Ride Out the Storm
Wait until knee-jerk reactions to changes die down before taking action
wait for 24-48 hours before responding to something negative
- Keep Up With the Joneses
Subscribe to news feeds about your competitors
- Beware the Bloat Monster
More mature doesn’t have to mean more complicated
resist the urge to add features
keep things simple
- Go With The Flow
Be open to new paths and changes in direction
Example: Flickr which started off as an online game
** Conclusion **
Start Your Engines
- Execution
Success is all about great execution in:
- web design
- good promotion
- good code
Constantly seek out your weak links and focus on them until they’re up to par.
- People
- More Than Just Software
Apply the principles to other areas in life
** Promotion **
- Hollywood Launch
Go from teaser to preview to launch
Teaser
drop hints on blogs
stay vague
boost the ego of a selective few to be the beta testers
put up a email collecting box
Preview
A few weeks ahead of launch, start previewing features
show screen shots
highlight features
tell people about the ideas and principles behind the app
collect emails
Launch
Send emails
post about progress: how many people have signed up
Keep posting about updates/tweaks
build the momentum
- A Powerful Promo Site
Build an ace promotional site that introduces people to your product
Include the following:
Overview: Explain your app and its benefits.
Tour: Guide people through various features.
Screen captures and videos: Show people what the app actually looks like and how to use it.
Manifesto: Explain the philosophy and ideas behind it.
Case Studies: Provide real life examples that show what’s possible.
Buzz:Testimonial quotes from customers, reviews, press, etc.
Forum: Offer a place for members of the community to help one another.
Pricing & Sign-up: Get people into your app as quickly as possible.
Weblog: Blogs keep your site fresh with news, tips, etc.
- Ride the Blog Wave
Blogging can be more effective than advertising (and it’s a hell of a lot cheaper)
Create a blog that’s helpful. Not just about the company.
- Solicit Early
Get advance buzz and signups going ASAP
Get some sort of site up and start collecting emails as soon as possible
- Promote Through Education
Share your knowledge with the world
You can give something back to the community that supports you and score some nice promotional exposure at the same time.
Education gives rises to healthy marketing, build up evangelists
Teaching Leads to Passion
- Feature Food**
They’re hungry for it so serve it up
Talk about the new features on blogs
Get people excited
- Track Your Logs**
Study your logs to track buzz
figure out where the buzz is coming from
Go to those blogs or forums, contact the people who praises you
Collect positive praise and create a “buzz” page at your site.
Inline Upsell
Promote upgrade opportunities inside the app
don’t forget to call out upgrade opportuni- ties from within the product.
Name Hook
Give your app a name that’s easy to remember
** Pricing and Signup **
- Free Samples
Noisy world. In order to get people to notice you amid the din, give something away for free.
- Easy On, Easy Off
Make signup and cancellation a painless process
- Silly Rabbit, Tricks are for Kids
Avoid long-term contracts, sign-up fees, etc.
- A Softer Bullet
Soften the blow of bad news with advance notice and grandfather clauses
Need to deliver bad news like a price increase? Give advanced notice.
** Words **
- There’s Nothing Functional about a Functional Spec
Don’t write a functional specifications document
Functional specs are fantasies
Functional specs are about appeasement
make everyone feel involved
Functional specs only lead to an illusion of agreement
people interpret words differently
Functional specs force you to make the most important decisions when you have the least information
Functional specs lead to feature overload
easy to add bullet points
Functional specs don’t let you evolve, change,and reassess
Specs don’t deal with the reality that once you start building something, everything changes.
Write a one page story about what the app needs to do.
Follow the process
paper sketch
html
code
Stay flexible
- Don’t Do Dead Documents
Eliminate unnecessary paperwork
Build, don’t write.
Documents that live separately from your application are worthless.
- Tell Me a Quick Story
Write stories, not details
- Use Real Words
Insert actual text instead of lorem ipsum
You need real copy to know
how long certain fields should be
how tables will expand or contract
what your app truly looks like
- Personify Your Product
What is your product’s personality type?
Think of your product as a person. What type of person do you want it to be?
** Priorities **
- What’s the Big Idea?
Explicitly define the one-point vision for your app
Mantra
- Ignore Details Early On
Working in iterations from large to small.
- It’s a Problem When It’s a Problem
Make decisions just in time, when you have access to the real information you need.
examples: scalability, features, servers
- Hire the Right Customers
Find the core market for your application and focus solely on them
If you try to please everyone, you won’t please anyone
Know who your app is really intended for and focus on pleasing them.
Polarize your customers
- Scale Later
You don’t have a scaling problem yet
Create a great app and then worry about what to do once it’s wildly successful.
- Make Opinionated Software
Your app should take sides
** Feature Selection **
- Half, Not Half-Assed
Build half a product, not a half-ass product
build half a product that kicks ass
Stick to what’s truly essential.
Take whatever you think your product should be and cut it in half.
Minimal Viable Product
Start off with a lean, smart app and let it gain traction.
- It Just Doesn’t Matter
Essentials only
Answer to customer support questions: “It Just Doesn’t Matter”
Leave out the nice-to have and not important features
- Start With No
Make features work hard to be implemented
Each time you say yes to a feature, you’re adopting a child. (e.g. design, implementation, testing, etc.)
The secret to building half a product instead of a half-ass product is saying no
Don’t be a yes-man
Feature request => No.
If keep hearing about it, implement.
“Innovation is not about saying yes to everything. It’s about saying NO to all but the most crucial features” — Steve Jobs
- Hidden Costs
Expose the price of new features
be on the lookout for feature loops (i.e. features that lead to more features)
For every new feature you need to…
1. Say no.
2. Force the feature to prove its value.
3. If “no” again, end here. If “yes,” continue…
4. Sketch the screen(s)/ui.
5. Design the screen(s)/ui.
6. Code it.
7-15. Test, tweak, test, tweak, test, tweak, test, tweak…
16. Check to see if help text needs to be modified.
17. Update the product tour (if necessary).
18. Update the marketing copy (if necessary).
19. Update the terms of service (if necessary).
20. Check to see if any promises were broken.
21. Check to see if pricing structure is affected.
22. Launch.
23. Hold breath.
- Can You Handle It?
Build something you can manage
Build products and offer services you can manage.
It’s easy to make promises. It’s much harder to keep them.
Consider: organizationally, strategically, and financially
- Human Solutions
Build software for general concepts and encourage people to create their own solutions
Give people just enough to solve their own problems their own way.
Example: Twitter
- Forget Feature Requests
Let your customers remind you what’s important
How do you manage them? You don’t. Just read them and then throw them away.
If you keep reading about a feature request, it’s time to consider implement it.
- Hold the Mayo
Ask people what they don’t want
Sometimes the biggest favor you can do for customers is to leave something out.
Innovation Comes From Saying No.
Filtering out the noise and get the signal
** Process **
- Race to Running Software
Get something real up and running quickly
Running software is real.
Once you’re there, you’ll be rewarded with a significantly more accurate perspective on how to proceed.
Stories, wireframes, even html mockups, are just approximations.
- Rinse and Repeat
Work in iterations
Iterations lead to liberation
- From Idea to Implementation
Go from brainstorm to sketches to HTML to coding
Brainstorm
about big questions
Paper sketches
Create HTML screens
Code it
- Avoid Preferences
Decide the little details so your customers don’t have to
Preferences are a way to avoid making tough decisions
Customers shouldn’t have to think about every nitty gritty detail
More options require more code: evil
Make the call
Examples: sorting order, number of items to display on each page
- “Done!”
Decisions are temporary so make the call and move on
Keep the momentum going
Revise if necessary
Execute, build momentum, and move on.
To me, ideas are worth nothing unless executed. They are just a multiplier. Execution is worth millions.
- Test in the Wild
Test your app via real world usage
Do it quick
1. Decide if it’s worth doing, and if so:
2. Do it quick – not perfect. just do it.
3. Save it. upload it. publish it
4. See what people think
- Shrink Your Time
Break it down
Keep breaking down timeframes into smaller chunks.
Same goes to tasks
Smaller Tasks and Smaller Timelines are easier to manage
** The Organization **
- Unity
Don’t split into silos
As much as possible, integrate your team so there’s a healthy back-and-forth dialogue throughout the process.
hire people with multiple talents who can wear different hats during development.
- Alone Time
People need uninterrupted time to get things done
Getting in the zone takes time. And that’s why interruption is your enemy.
The alone time zone is where the real development magic happens.
Set up a rule at work: Make half the day alone time.
- Meetings Are Toxic
Don’t have meetings
For those times when you absolutely must have a meeting (this should be a rare event), stick to these simple rules:
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.
- Seek and Celebrate Small Victories
Release something today
Long, drawn out release cycles are motivation killers.
quick wins that you can celebrate are great motivators
“What can we do and release in 4 hours?” It could be…
A new simple feature
A small enhancement to an existing feature
Rewriting some help text to reduce the support burden
Removing some form fields that you really don’t need
** Staffing **
- Hire Less and Hire Later
Add slow to go fast
communication overhead, personality clashes
You don’t need as many people as you think.
1 great player > 4 mediocre players
- Kick the Tires
Work with prospective employees on a test-basis first
“test drive” potential employees
- Actions, Not Words
Judge potential tech hires on open source contributions
Quality of work
Cultural perspective
Level of passion
amount of time indicates how much they love programming
Completion percentage
Social match
If someone’s lacking in manners or social skills, filter them out.
If you want something done, ask the busiest person you know.
- Get Well Rounded Individuals
Go for quick learning generalists over ingrained specialists
- You Can’t Fake Enthusiasm
Go for happy and average over frustrated and great
A happy yet average employee is better than a disgruntled expert.
- Wordsmiths
Hire Good Writers
Always hire the better writer for a given job position
Effective, concise writing and editing leads to effective, concise code, design, emails, instant messages, and more.
Indicator of an organized mind
** Interface Design **
- Interface First
Design the interface before you start programming
Design is relatively light.
Hard to change code
The interface is your product
Answer these questions
Does it make sense?
Is it easy to use?
Does it solve the problem at hand?
- Epicenter Design
Start from the core of the page and build outward
you start at the epicenter and design the most important piece of content first.
worry about the navigation/tabs, footer, colors, sidebar, logo, etc later
- Three State Solution
Design for regular, blank, and error states
Regular
The screen people see when everything’s working fine and your app is flush with data.
Blank
The screen people see when using the app for the first time, before data is entered.
Error
The screen people see when something goes wrong.
- The Blank Slate
Set expectations with a thoughtful first-run experience
The blank state is the most crucial because it creates first impression!
What should you include in a helpful blank slate?
Use it as an opportunity to insert quick tutorials and help blurbs.
Give a sample screenshot of the page populated with data so people know what to expect (and why they should stick around).
Explain how to get started, what the screen will eventually look like, etc.
Answer key questions that first-time viewers will ask:
What is this page?
What do I do now?
How will this screen look once it’s full?
Set expectations and help reduce frustration, intimidation, and overall confusion.
- Get Defensive
Design for when things go wrong
- Context Over Consistency
What makes sense here may not make sense there
Consistency is not necessary
- Copywriting is Interface Design
Every letter matters
Great interfaces are written.
Examples: buttons, labels etc
- One Interface
Incorporate admin functions into the public interface
build these admin functions (i.e. edit, add, delete) into the regular application interface
** Code **
- Less Software
Keep your code as simple as possible
each time you increase the amount of code, your software grows exponentially more complicated.
Get 80% of the functionality with 20% of the time: it’s a win
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.You can change your mind without having to change boatloads of code.
Less software results in fewer bugs.
Less software means less support.
Encourage programmers to make counteroffers: say no when it’s too complicated
It’s better to inform the user using text rather than with server side code. Example: image upload format
- Optimize for Happiness
Choose tools that keep your team excited and motivated
Choose ruby for elegance and simplicity to keep the engineers happy
- Code Speaks
Listen when your code pushes back
If it takes forever to implement something, there is probably a better way
- Manage Debt
Pay off your code and design “bills”
technical debt: fixing hairy design (pay down payment) rather than keep hacking (interests)
- Open Doors
Get data out into the world via RSS, APIs, etc.
give up the idea of sealing in data. Instead, let it run wild
