More notes on Getting Real

Continued from First Notes on Getting Real, a book by web app company 37 Signals.

Differentiate yourself from bigger companies by being personal and friendly

Hell, we're all over that one.

From "Be Yourself"

What's the Big Idea

Before you start designing or coding anything you need to know the purpose of your product — the vision. Think big. Why does it exist? What makes it different than other similar products?

They do this in one sentence, something I'm not good at. Well, unless you count three semicolons, a couple parenthetical phrases including their own subjects, verbs and objects, and another complete semicolon and parethesis extravaganza embedded in em dashes.

But let's give this a try for PWGD.

Many-to-many communication is essential for democracy.

Or: Democracy needs many-to-many communication.

Or: Many-to-many communication is democracy.

Or perhaps better, replace 'democracy' in any of these with 'self-government' (or self-rule or participatory society).

I'd consider "People need people" but that's a tad too broad (for now).

Whether or not this helps for the grant-app, I think it will help maintain focus on what features we develop for People Who Give a Damn.

And it will be a lot of fun to make Agaric Design's clients come up with their own one-sentence statement of purpose or otherwise short mantra.

From "What's the Big Idea"

Ignore Details Early On: Work from large to small

I love their examples of details, which are exactly the kinds of things that any good design company (like Agaric Design of course) obsesses over. And as they say, we love the details:

* The space between objects
* The perfect type leading
* The perfect color
* The perfect words
* Four lines of code instead of seven
* 90% vs 89%
* 760px vs 750px
* $39/month vs. $49/month

Success and satisfaction is in the details.

However, success isn't 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.

37Signals' remedy? Do these things later. It's what we mostly do also, although I can't imagine anybody having a meeting about any of these things. A good argument, sure. These are exactly the kinds of details we're always asking the client to just not think about until the overall functionality and look is down.

The point is that even though these are often small matters, it is details like these regarding the look and feel of a web site or application that you will notice. You can make a note to yourself to be sure (especially for the perfectionist details like ensuring every image has a descriptive alt tag and button-style links are a link for the whole button), but in general it's like 37Signals wrote:

Details reveal themselves as you use what you're building. You'll see what needs more attention. You'll feel what's missing. You'll know which potholes to pave over because you'll keep hitting them. That's when you need to pay attention, not sooner.

From "Ignore Details Early On"

It's a Problem When It's a Problem

The fact that I'm disagreeing with them here probably means it's me with the problem, but I think this goes too far:

Don't waste time on problems you don't have yet

Do you really need to worry about scaling to 100,000 users today if it will take you two years to get there?

Those kinds of "future problems" can and often must be considered. You don't necessarily have to solve the "problem" of a million users, but you have to be using a framework that gives you a reason to feel that you can handle the expected, hoped for, or simply predictable circumstances you and your client (or service or product) will face in a couple years.

Here's the 37Signals call, for the record:

Bottom Line: Make decisions just in time, when you have access to the real information you need. In the meanwhile, you'll be able to lavish attention on the things that require immediate care.

At Agaric Design we'd rather err on the side of thinking ahead, but as above not working or making final decisions that can wait until the new reality is in better view.

From "It's a Problem When It's a Problem"

Scale Later

This essay is slightly later in the book, but in it 37Signals returns to their Don't Worry, Be Happy mantra for worrying about problems later. They make it sound so good...

Create a great app and then worry about what to do once it's wildly successful. Otherwise you may waste energy, time, and money fixating on something that never even happens.

Backed up by the further point:

You have to revisit anyway

The fact is that everyone has scalability issues, no one can deal with their service going from zero to a few million users without revisiting almost every aspect of their design and architecture.
—Dare Obasanjo, Microsoft (from Scaling Up and Startups)

We still maintaint that we can, should, and do plan for the likely needs of our clients. For an extreme, but common, example, many people need only a static web page, based on what they ask for. We would never give a client a static web page. What if they need to edit it later? Add a section? Give coworkers, friends, or fans the ability to add pages or comments? Since we can give all this with an open source content management system like Drupal, we give it. It would be a disservice to our client to provide just a static page because that's all they need at the moment.

More to the point, Drupal also gives a platform proven to scale to, at least, hundreds of thousands of users and millions of visitors.

From "Scale Later"

Find the core market for your application and focus solely on them

They called this "Hire the right customers."

The Agaric Design Collective considers ourselves problem-solvers before even web developers, so in one sense we don't like the idea of choosing clients based on their having needs we already have met before. On the other hand we'll be the first to tell people that their needs are getting out of our area of core expertise (broadly, communication!).

This makes particular sense for a web application, but it is a basic truth: "If you try to please everyone, you won't please anyone."

As a design and web development collective, we've found it possible to please diverse clients, and we like the fact that every job has been different, because of our range of clients. But then, we are doing a specific thing: web development, graphic design and related marketing or promotional services and consulting, for clients who themselves are generally focused in their purpose.

Relating this back to PWGD, though, and I'm not quite sure where that leaves us. Start with a focus on the activist community?

From "Hire the Right Customers"

Their "Make Opinionated Software" essay is in the same vein, and more useful advice is given in the next essage:

Take whatever you think your product should be and cut it in half.

The point isn't necessarily to stay at the most minimal and essential, but to start there:

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.

From "Half, Not Half-assed"

If it doesn't really matter, leave it out

Hard to apply toward a project called People Who Give a Damn, and hard for Agaric Design to say to our clients, but still largely true.

If you can cut out the work and thinking that just don't matter, you'll achieve productivity you've never imagined.

From "It Just Doesn't Matter"

Make features work hard to get implemented, is their advice. Sayeth Steve Jobs, reportedly: "Innovation is not about saying yes to everything. It's about saying NO to all but the most crucial features." From "Start With No"

37Signals makes adding new features seem worse than starting to make a new application in the first place. But the point is that adding features should be thought out as carefully as starting a new project. See "Hidden Costs"

Above all:

Make sure whatever it is that you're doing is something you can actually sustain — organizationally, strategically, and financially.

From "Can You Handle It?"

Continue with Still more Getting Real.