Do you really know how to make a project successful?
Let's speak about an excellent book delivered by the RoR team (the same who successfully released Basecamp, Tada List, Backpack, Writeboard, Campfire and Highrise) : "
Getting Real" by the 37signals Team.
I'm really convinced today about the good practices related into this book.
By experience, many projects i participated on, applied exactly the opposite of "Getting Real"...all these projects have never been released on time and on budget or worth, nothing has been released at all. Most of these projects had in common a management by contract, long-term specification phase, customers unhappy after the (long) period of specs + development (their needs has changed in the interval), release more than competitors and all the features in version 1.0, too much bureaucracy, too much meetings, too much politics, too many project managers.
I will write 3 articles about the "Getting Real" book : i'll try to deliver a shrink overview by extracting lines from chapters of the book, being to my eyes some essential points that can help you in order to make a project real : release a quality product satisfying your customers.
The goal of these articles is also to give you the envy to read the original book (including many essays): it can be bought as a
PDF or
paper Back, or read
freely online** The starting line **
* Build less *
One first key point is "underdo your competitors". Many think you beat your competitors if you one-up them. If they have 4 features, you should deliver 5, 15 or 25 more. But this kind of defensive, paranoid and expensive way to build products should be forget. By doing this, you can't think ahead, but behind...so you don't lead but follow.
The answer is : do less.
Less features, Less options/preferences, less people and corporate structures, less meetings and abstractions, less promises
* Build software for yourself *
Solve your own problems. By doing this you're the target audience, and you'll know what's important and what's not.
* Constraints drive innovation *
Constraints force you to get your idea out in the wild sooner. After one month or two, you've a pretty good idea if you're onto something or not. If your idea is lemon, it's time to go back (opposed to months or years down the road).
Don't forget : build a quality tool that you & your customers can live with for a long time.
* Launch on time & on budget *
To launch on time and on budget : keep them fixed. Don't throw more time and money at a problem, just scale back the scope.
The myth "Launch on time, on budget and on scope" never happens, and when it does, the quality often suffers.
Lauching something great that's little smaller in scope than planned is better than launching something mediocre and full of holes.
* Prioritization *
You have to figure out what is really important, and what you're going to make for the initial release.
* Your passion - or lack of - will shine through *
If your product doesn't excite you, something's wrong. If you're only working on it to cash out, it will show. If you feel passionnately about your app, it will come through in the final product.
** Stay lean **
* Less mass *
The more massive is an object, the more energy is required to change its direction. It's true in the business world as in the physical world.
For web technology it's also true : changes must be easy and cheap. If you can't change on the fly, you'll lose ground to someone who can.
Mass is increased by : Long terms contracts, excess staff, permanent decisions, meetings about other meetings, thick process, hard / soft / technologies lock-ins, proprietary data formats, The past ruling the future, Long-Terms roadmaps, office politics.
Mass is reduced by : Just in time thinking, Multi Tasking team members, embracing constraints, less software & less code, less features, small team size, simplicity, pared down interfaces, open source products, open data formats, open culture that makes it easy to admit mistakes.
With less mass, you change of direction quickly. You can react and evolve. You can focus on good ideas and drop the bad ones. You can listen and respond to your customers. You can integrate new technologies now instead of later.
* Stay flexible *
if your competitors can change faster than you, you're at huge disadvantage. If changes get too expensive, you're dead.
The ability to change on a dime is one thing small teams have by default that big teams can never have.
Cheap and fast changes are small's secret weapon.
All the cash, all the marketing, all the people in the world can't buy the agility you get from being small.
* Use a team of 3 for version 1.0 *
For the first version of your app start with only three people. Start with a developer, a designer, a sweeper (someone who can roam between both worlds).
If you can't build your version with three people, then you either need different people or need to slim down your initial version.
Remember : keep your first version small and tight. You'll quickly get to see if your idea has wings, and, if it does, you'll have a clean, simple base to build on.
* Differentiate yourself from bigger companies by being personal and friendly *
A lot of small companies make the mistake of trying to act big. Being small can actually be a huge advantage, especially when it comes to communication.
Small companies enjoy fewer formalities, less bureaucracy, and more freedom. Smaller companies are closer to the customer by default.
** Priorities **
* What's the big idea *
Explicitly define the one-point vision for your app : What does your app stand for? What's it really all about?
Your vision should be brief too. A sentence should be enough to get the idea across.
* Ignore details early on *
Work from large to small.
Success is not the only thing you'll find in the details.
You'll also find stagnation, disagreement, meetings and delays. These things can kill morale and lower your chances of success.
Just get the stuff on the page for now. Then use it. Make sure it works. Later on you can adjust and perfect it.
* It's a problem when it's a problem *
Don't waste your time on problems you don't have yet.
Do you need to worry about scaling to 100 000 users today if it will take two years to get there.
Do you need to hire 8 programmers if you only need 3 today.
Do you really need 12 top-of-the-line servers now if you can run on two for a year?
* Hire the right customers *
Find the core market for your application and focus solely on them.
The customer is not always right. The truth is that you have to sort out who's right and who's wrong for your app.
If you try to please everyone, you won't please anyone.
* Scale later *
You don't have a scaling problem yet.
In the beginning, make building a solid core product your priority instead of obsessing over scalability and server farms.
Create a great app and then worry about what to do once it's wildly successful.
* Make opiniated software *
The best software has a vision. The best software takes sides.
When someones uses software, they're not just looking for features, they're looking for an approach. They're looking for a vision.
** Feature selection **
* Half and not Half-ass *
Stick to what's truly essential
Take whatever you think your product should be and cut it in half.
Pare features down until you're left with only the essential ones. Then do it again.
Start off with a lean, smart app, and let it gain traction. Then you can start to add to the solid foundation you've built.
* Start with No *
The secret to building half a product instead of half-ass product is saying no.
Don't be a yes man:
Every new feature that comes to us meets a no. We listen but don't act. The initial response is « Not now »
If a request feature keeps coming back, that's when we know it's time to take a deeper look. Then, and only then, do we start considering the feature for real.
* Hidden costs *
Expose the price of new 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.Test tweak test tweak test tweak...
8.Check to see if help text needs to be modified.
9.Update the product tour (if necessary)
10.Update the marketing copy (if necessary)
11.Update the terms of service (if necessary)
12.Check to see if any promises were broken.
13.Check to see if pricing structure is affected
14.Launch
* Can you handle it *
Build products and offer services you can manage.
It's easy to make promises. It's much harder to keep them.
Make sure whatever it is that you're doing is something you can actually sustain – organizationally, strategically, financially.
* Human solutions *
Build software for general concepts and encourage people to create their own solutions.
Don't force conventions on people. Instead make your software general so everyone can find their own solution.
* Forget feature requests *
Let your customers remind you what is important.
Customers want everything under the sun. They'll avalanche you with feature requests.
We'll hear about 'This little extra feature', or 'This can't be hard', or 'Wouldn't it be easy to add it' or 'It should just take a few seconds to put it in' or 'If you added this I'll pay twice as much' etc...
As said before, your first response should be a NO.
Where do you store theses request features? How do you manage them? You don't. Just read them then throw them away.
Don't worry about tracking and saving each request that comes in. Let your customers be your memory. If it's really worth remembering, they'll remind you until you can't forget.
* Hold the mayo *
Ask people what they don't want.
More isn't the answer. Sometimes, the biggest favor you can do for customers is to leave something out.
Finally, about Just Say No (that certainly will shock some readers), listen what Steve Jobs (CEO, Apple) said about innovation.
* Innovation comes from saying no *
[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. We’re always
thinking about new markets we could enter, but it’s only by saying no
that you can concentrate on the things that are really important.