Getting Real - Kitap Notları
Dediğim gibi bugün Getting Real' ı bitirdim (son bir kaç bölüm essay kaldı). Son zamanlarda bir çok konuda kısa notlar tutuyorum, bu notlar da Gettin Real' dan:
- Only explicitly required features for that moment, If it’s not reuqired right now by you do not do it now.
- Less interface.
Focus on something, solve it
- Do not try to beat competitors use a new way, put something new into the market,
- Know your enemy, Choose and focus a point.
- Use less money, small team, less features,
- First version of the app should be able to developed by only 3 people.
- Use Deadlines,
- Lower the scope to meet deadlines.
- Do not try to act big, show personality, show that you are small and take advantage of it.
- What’s your big idea?
- Work small, ignore details in the beginning, you can work on them later. Try to have fun with what you do.
- Don’t fix a problem before it’s a problem.
- Find your audience and market, focus on their expectations,
- Take a side
- Application should take a side strictly, this might piss off some clients but who gives a shit. They can choose another solution.
- make application as small as possible, Feature wise, Code wise etc.
- Instead of having lots of features which don’t work, have a few which work great,
- Build features and cut it half, that's what you need,
- Focus on only essential features and rest will come after essentials are good,
- Remove features which “Just doesn’t matter”. If a feature not changing outcome remove / don’t develop it.
- Do not try to please everyone, focus on the essentials and the target market.
- Do not accept features by default, A feature should be accepted after a long battle.
- Solve the root problem, and let people to solve the rest of the problem in your framework.
Add a New Feature Routine
- 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.
- Do it instead of spending ages on planning it, do it as a early, shortcut dirty version if it’s required.
- Build, Revise, Repeat…
- Avoid Prefences, Put your professional expertise, make a default setting stick with it. Just ignore little details focus on the essentials.
- Do the decision, make your call, get it done, unless you got it working your idea is pointless.
- It doesn’t matter it’s beta or not, get it released. It may not be perfect but release it, then you might fix it.
- Have alone working time, “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). Or make the first or the last half of the day the alone time period. Just make sure this period is contiguous in order to avoid productivity-killing interruptions.”
- Release often to keep yourself motivated, Add new small features and have small releases to keep yourself motivated.
- Prioritise the design, most important element to less important one.
- Use a simple and good language in the UI.
- Code less, and code only required functionality,
- Do trade-offs between more feature and less code,
- Think 10 times before add a new feature, think 100 times before add a BIG feature.
- If you hacked the to code to get it work, go back and fix it before it bites you later.
- Don’t document stuff, build a mockup instead.
- To explain and document features use a real-worl alike story. Don’t go into technical details do it in a human way.
- Personify the application, decide a personality for your application and use it consistently in every single section. Design, interface, messages, features.
- Give something for free. Lite version, sample etc.
- Make sign-up and cancellation easy, allow your users to export their data whenever day want in a acceptable format such as XML.
- Don’t do stupid trick for contract, make it obvious and easy such as pay monthly and cancel whenever you want style.
- How to launch a new product
- Promo Website
- Write education materials, books, videos, tips and tricks about the product,
- Add small features and promote them in specific groups,
- Try to sell more to your current users, (such as upgrade plans)
- Choose a simple, short and catchy name instead of something long and too descriptive,
- Do not use external support team, let developer to do the support
- Use inline help (such as a note for a known problem) in the application and Keep stuff simple so anyone can use it without training,
- Have a quick turnaround time in support requests (no more than an hour),
- Customer is not always right,
- Use forums to help customers to themselves,
- Publicise Bad News
- Keep a development blog,
- Keep releasing often, show people that you are alive,
- Don’t do public beta, if it’s not good enough to be public don’t make it public,
- Prioritize your bugs,
- Keep watching your enemies.