Gettings Real - heighlights
Starting
When there's too many people involved, nothing gets done.
Many months are spent on planning features and arguing details with the goal of everyone reaching an agreement on what is the "right" thing for the customer.
Months of writing specs are not necessary — specs should have the foundations nailed and details figured out and refined during the development phase.
Getting Real is about skipping all the stuff that represents real (charts, graphs, boxes, arrows, schematics, wireframes, etc.) and actually building the real thing.
Getting Real foregoes functional specs and other transitory documentation in favor of building real screens.
Getting Real gets rid of... Timelines that take months or even years Pie-in-the-sky functional specs Scalability debates Interminable staff meetings The "need" to hire dozens of employees Meaningless version numbers Pristine roadmaps that predict the perfect future Endless preference options Outsourced support Unrealistic user testing Useless paperwork Top-down hierarchy You don't need tons of money or a huge team or a lengthy development cycle to build great software. Those things are the ingredients for slow, murky, changeless applications. Getting real takes the opposite approach.
Change
The ability to change is key. Having everything fixed makes it tough to change.
If your competition is faster, you must be cheaper. If they sell the story of health, you must sell the story of convenience.
A lot of small companies make the mistake of trying to act big.
Mass is increased by... Long term contracts Excess staff Permanent decisions Meetings about other meetings Thick process Inventory (physical or mental) Hardware, software, technology lock-ins Proprietary data formats The past ruling the future Long-term roadmaps Office politics
Change is your best friend.
If change gets too expensive, you're dead.
When it comes to web technology, change must be easy and cheap.
Ignore Details Early On Work from large to small
Don't worry about the size of your headline font in week one. You don't need to nail that perfect shade of green in week two. You don't need to move that "submit" button three pixels to the right in week three. Just get the stuff on the page for now. Then use it. Make sure it works.
New features
Believe it or not, the bigger problem isn't scaling, it's getting to the point where you have to scale. Without the first problem you won't have the second.
Organizations need guideposts. They need an outline; employees need to know each day when they wake up why they're going to work.
Take whatever you think your product should be and cut it in half. Pare features down until you're left with only the most essential ones.
For every new feature you need to...
- 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. > 7-15. 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.
Ask people what they don't want
Innovation comes from saying no to 1,000 things to make sure we don't get on the wrong track or try to do too much.
Most of the time you spend is wasted on things that just don't matter. If you can cut out the work and thinking that just don't matter, you'll achieve productivity you've never imagined.
It is simply too easy, and sometimes fun, to waste valuable time inventing features that turn out to be unnecessary or unimplementable.
Environment and hires
Guess which part of the day we get the most work done? The alone part. It's not that surprising really. Many people prefer to work either early in the morning or late at night — times when they're not being bothered.
The alone zone is where real progress is made.
Getting in the zone takes time. And that's why interruption is your enemy. It's like rem sleep — you don't just go to rem sleep, you go to sleep first and you make your way to rem. Any interruptions force you to start over. rem is where the real sleep magic happens. The alone time zone is where the real development magic happens.
They usually convey an abysmally small amount of information per minute
Judge potential tech hires on open source contributions
A single good programmer working on a single task has no coordination or communication overhead. Five programmers working on the same task must coordinate and communicate. That takes a lot of time... The real trouble with using a lot of mediocre programmers instead of a couple of good ones is that no matter how long they work, they never produce something as good as what the great programmers can produce.
Enthusiasm. It's one attribute you just can't fake.
Someone you can trust to get things done when left alone.
At Creative Good, we call it "intelligent inconsistency": making sure that each page in the process gives users exactly what they need at that point in the process.
Design
Copywriting is interface design.
Whatever the page absolutely can't live without is the epicenter.
Only when that unit is complete would you begin to think about the second most critical element on the page. Then after the second most critical element, you'd move on to the third, and so on. That's epicenter design.
Epicenter design flips that process and allows you to focus on what really matters on day one. Essentials first, extras second.
"Defensive Design for the Web" Remember: Your app may work great 90% of the time. But if you abandon customers in their time of need, they're unlikely to forget it.
To avoid crappy-admin-screen syndrome, don't build separate screens to deal with admin functions. Instead, build these functions (i.e. edit, add, delete) into the regular application interface.
Much like a weblog, it's up to them to populate it — the overall look and feel doesn't take shape until people enter their data: posts, links, comments, hours, sidebar info, or whatever.
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.
You Never Get A Second Chance...
Is a new feature requiring weeks of time and thousands of lines of code? That's your code telling you there's probably a better way.
If programmers got paid to remove code from sofware instead of writing new code, software would be a whole lot better.
Keep your code as simple as possibe each time you increase the amount of code, your software grows exponentially more complicated. Each minor addition, each change, each interdependency, and each preference has a cascading effect.
The way you fight this complexity is with less software. Less software means less features, less code, less waste.
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.
Tere is No CODE That is More Flexible Than NO Code!
Don't try to lock-in your customers. Let them get their information when they want it and how they want it.
Motivating
Optimize for Happiness Choose tools that keep your team excited and motivated
Would you truly be happy working in this environment eight hours a day?
Happiness has a cascading effect. Happy programmers do the right thing. They write simple, readable code. They take clean, expressive, readable, elegant approaches. They have fun.
Don't Do Dead Documents Eliminate unnecessary paperwork
Documents that live separately from your application are worthless.
Documents that live separately from your application are worthless. They don't get you anywhere.
Don't waste your time typing up that long visionary tome; no one's going to read it.
I've even worked with developers who've spent hours writing long, descriptive emails or coding standards documents that also went unread.
Documenting
Functional specs are fantasies!
There's Nothing Functional about a Functional Spec Don't write a functional specifications document
Functional specs lead to feature overload
Write a one page story about what the app needs to do. Use plain language and make it quick. If it takes more than a page to explain it, then it's too complex.
A "spec" is close to useless. I have never seen a spec that was both big enough to be useful and accurate. And I have seen lots of total crap work that was based on specs. It's the single worst way to write software, because it by definition means that the software was written to match theory, not reality.
Use Real Words Insert actual text instead of lorem ipsum
Easy On, Easy Off Make signup and cancellation a painless process
There should always be a free option so customers can demo the app without entering credit card information.
Keep the signup form as short as possible. Don't ask for stuff you don't need and don't throw a long daunting form at people.
Don't hold users against their will. If they want to leave, let them pick up with all of the content they created while they were on your site and leave...for free...
Ask them if they want to be included on your special advance list so they'll be among the first to know about future releases, updates, etc. Collect positive praise and create a "buzz" page at your site.
During business hours, we answer 90% of all email support requests within 90 minutes — and often within a half-hour. And people love it.
You don't need a manual to use Yahoo or Google or Amazon. So why can't you build a product that doesn't require a manual? Strive to build a tool that requires zero training.
Just because you discover a bug in your product, doesn't mean it's time to panic. All software has bugs — it's just a fact of life.
These days it feels like everything is in beta stage forever. That's a cop out. An interminable beta stage tells customers you're not really committed to rolling out a finished product. It says, "Use this, but if it's not perfect, it's not our fault."
Betas
Private betas are fine, public betas are bullshit.
Don't wait for your product to reach perfection.
Is it just me, or are we all in beta, all the time?
Sometimes it's ok to just be a pencil. You don't need to be a swiss-army knife.
With web-based software based on the subscription model, people pay a monthly fee to use the service. You don't need to keep upselling them by adding more and more and more, you just need to provide an ongoing valuable service.