Marc R 07 Feb 06

Whenever I do prioritization I like to include a “Critical” category above “High”. Critical means without it there is no product. This prevents strong desires get mixed up with needs.

Kendall 07 Feb 06

This is great insight. I think the idea of stripping down to the bare esentials for an initial release is the way to go. At the same time I think it’s a really difficult thing to do. Also how do you deal with portions of the product that might overlap. Feature A and Feature B are interrelated… Feature B is deemed essential but Feature A is not. Build in support for Feature A intially or just figure you’ll cross that bridge when you get there?

M. Longfellow 07 Feb 06

Get to the point… evolve into perfection once you’re live…add focused value once you secure a useable track record/ meaningful data points/ get the thing launched … Thanks for the a great post with philosophical & entrepreneurial insight.

Ryan Ripley 07 Feb 06

Cross the bridge when you get there… By the time you get around to working on v1.1 you may realize that feature A is completely unneeded, and that feature B no longer meets the users requirements…

It’s amazing how quickly user and business needs can change…

—Ryan

rich 07 Feb 06

Generally, how do you go about future-proofing things?

ie. How do you get the essentials done in such a way that you don’t close down the options for the v1.1 ideas, and so on…?

To me that’s always seemed like a tricky balance in projects as a whole. I know much of it is to do with technical details - making code abstract and easy to extend, etc. - but I mean more generally with balancing priorities in a project.

Any rules-of-thumb?

Mark Gallagher 07 Feb 06

Decisions on essential and non-essential are all judgment calls based on your experience, your understanding of your users and technical decisions.

Sometimes non-essential features (that are cool) can be included in version 1.0 because the coding is easy. If the coding is not easy or they complicate the UI, then you remove them from version 1.0.

And sometimes an essential feature proves very tough from a technical perspective to stabilize in the app, so if it is delaying the launch you look for a workaround - usually a more simple approach.

There is a risk if these judgments are made by the more technical members of the team that think they know what the users want. A disconnect can occur between this perspective and the real world of the users.

An experienced project manager and user feedback help to make the right decisions.

But defining “essential” and “non-essential” is more an art than a science.

Chris 07 Feb 06

Please, this is not a troll, but in light of Google’s own future foray into ajax-powered chat ( http://mail.google.com/mail/help/chat.html ), first to market does indeed matter. And yes, I know Campfire is different, for different purposes, etc. But nonetheless. And hats off to having your fingers on the same pulse as Google.

JF 07 Feb 06

Chris, just to play with your point a little. Google hasn’t been first to market with any of their products. They’ve just done them better than the rest.

willy wonka 07 Feb 06

Hey JF - excellent points.

How about including this as a filter: If the product will break by removing it - keep it? This way you have *bare* bones in the app.

- ww

Bernt 07 Feb 06

And how do we know they are non-essential? We�ve been using Campfire for over a month without any of these features and doing just fine.

But how does that go with what every UI expert knows: that designers are not users?

Chris 07 Feb 06

Well for that matter, neither of you are first to market. Chat has been around for.. what? 30 years? Web-based chat (in one form or another) for over 10? But you’re both striving to do it better than the rest.

And no, Google’s not always “better than the rest”.. Google video?

In agreement with your posting, keep it lean and quick at 1.0. Be the iTunes in face of Google Video.

Dave Ritter 07 Feb 06

An interesting flipside to this is being willing to take criticism for what you’ve left out. Especially if you’re building something for a space where lots of established software exists, if you build software that only has the essentials included, you need to expect that people will feel the lack of those features. We’ve definitely seen this happen with our release in the already-established LMS space.

This doesn’t mean software should have tons of features because people want them… Just that the idea of “less” often means leading with design. Teaching people what they want, not giving them what they think they want. Not to sound too arrogant, but I think design can often reveal things to people they weren’t previously aware they wanted.

In short, I completely agree… with the caveat that you’re ready to whether the negative feedback. Which is probably a good idea anyway.

Dave Ritter 07 Feb 06

dammit.

of course i meant “weather the negative feedback…”. My english profs would be ashamed…

RS 07 Feb 06

Bernt said..

But how does that go with what every UI expert knows: that designers are not users?

You can choose to build for yourself. Then you’re the user.

David Demaree 07 Feb 06

Slightly off-topic, but this has been bugging me since the preview last week: I think people who are trying to compare Google’s upcoming GTalk-in-Gmail feature with Campfire (or people who’ve compared Campfire, positively or negatively, with IM services) are missing the point.

Whether it’s built into Gmail or not, Google Talk is still focused on communication between individuals, whereas Campfire facilitates collaboration among groups. The only commonality is that they’re both web-based chat facilitated by Ajax.

I think a lot of us are trying to see Campfire for its Ajaxness and not for its real-world potential, and that’s a shame.

Noah 07 Feb 06

I’m not knocking your product, and most of the clients especially java based web ones blow but isn’t campfire a lot like IRC?

JF 07 Feb 06

But how does that go with what every UI expert knows: that designers are not users?

We are users of our products. We build products for ourselves. We’re not special so we know that if we find the products useful then hundreds of thousands (or millions) of others will as well.

Dave Churchville 07 Feb 06

Great post!

We did this with the first release of our product. It was painful, but necessary to get it out the door.

Surprisingly, the limited feature set turned out to be a selling point - less for anxious users to learn.

Even though subsequently we added more features, this philosophy is still our guiding force. Listen to what users say, and very carefully add more features that will help the largest percentage.

JF 07 Feb 06

Yes, Campfire is a lot like IRC. You may know people who know what IRC is and how to use but, but 99% of folks in the business world don’t. This is not a product targeted at techies in the IRC-know.

Baeck 07 Feb 06

> Generally, how do you go about future-proofing things?

I think when you cut things down to just the essentials and do LESS(tm), you automatically leave things open for the future. A product that doesn’t have a lot of code to begin with is a whole lot easier to change - even if the code is poor - than a product with a ton of (possibly well-written) code.

Small iterations and careful consideration of new features or changes to existing features make for a more easily-maintained code base.

Hullabaloo 07 Feb 06

“Cost” vs “Benefit”
There are a lot of factors that go into a project. One of the first is the “Time Criticality” of the project. Often times those 1.1 features can be much more “expensive” rather than with just including them in the first place. It really is about resources and this comes down to two things. “Project Analysis” and “Feasibility Study”. If it is done properly with all parties concerned the best path can be laid even if it makes a few disgruntled. Especially on large projects with many people involved. Project planning is a “Catch-22” after all. On everyone’s A-List is minimizing “Cost” which ultimately reduces the project “Scope” but not the “Functionality”.

So in conclusion “Cost” is related to who pays and “Benefits” to clients. Often time 1.1 never is a reality because of these factors. Pay me now or Pay me Later…

D.Ditzler 07 Feb 06

When I was doing a lot of development I aways kept a running list called “wish list” anything that came up after the original spec had been signed off on got moved into the wish list. I learned that lesson the hardway as we were adding features (yea the dreaded “feature creap”) as we were going allong and the deadlines kept slipping by.

That was back in the day when the tools were much more crude than today but non the less it still takes time and energy to manage. It was a good solution because then we had a list to go back to the cleient with (most of which were the client’s ideas anway) and we could talk about how much it would add cost and time and work that into the next version.

on a side note I thought campfire was the CRM tool? That must be something else.

Kevin 07 Feb 06

Great post! I really enjoyed reading everyones feedback.

I like to do the same thing with essential features, but I often refer to them as “show stoppers”. If product doesn’t have feature X, then it’s not worth doing. Such as, if your widget maker doesn’t make widgets, then it’s probably going to be a failure. Actually defining how well said widgets are made, is the grey area (i.e. Essential vs. Non-Essential).

Keep up the great work…

Alex Bunardzic 07 Feb 06

This flies in the face of your other point that future should be left to the future. By delegating ‘nice and cool to have’ stuff to the V1.1. (i.e. to the future), you’re elevating yourself to the glorified position of a soothsayer. And I think you’d be the first to admit that such a thing would be impossible.

So leave the future to the future. Let tomorrow take care of tomorrow.

The thing that really, truly matters is how to make your product desirable. This is where the trick lies. If a business can make its product look and feel prestigious in the eyes of its prospects, that business will meet with success.

So, will the product be perceived as being prestigious if you strip it down to its bare essentials, or will it end up being more desirable if you add some fluff on top of it? That’s the million dollar question. And I’m not pretending to know the answer, but I do know that different products need different combination of essential/fluff in order to attain the desirable status.

For example, your own Basecamp managed to strike a beautiful balance, and became prestigious by sticking to pretty much bare essentials. By managing to resist the temptation to add nice and cool features, you’ve made that product a resounding success.

But who’s to say that some other product, such as Campfire, is eligible for the same treatment? Maybe Campfire really needs some fluff if it is to become the bread and butter of the social software arena?

The ball is in your court. I have too much of a similar dilemma to worry about when it comes to positioning my line of products.

Best of luck to you, we all hope you guys deliver an awesome product!

Alex

Nick Ciske 07 Feb 06

D.Ditzler: The CRM-ish tool is called Sunrise.

Alex: Putting a feature into the 1.1 column doesn’t mean it actually gets into the 1.1 release, at least that not what Jason is saying here. When 1.1 comes around, you do the same process- what essential for 1.1 makes it in, everything else is put off.

Rinse. Repeat. Have a shiny and managable product.

Putting it on the 1.1 list (or wish list or whatever you call it) is merely a way of ending the discussion and getting back to work on essentials.

JF 07 Feb 06

Putting it on the 1.1 list (or wish list or whatever you call it) is merely a way of ending the discussion and getting back to work on essentials.

Exactly. 1.1 isn’t a promise it’s a suggestion.

pwb 07 Feb 06

Totally agree with original post. People have a very poor understanding of the drag that non-essential features introduce into the development, testing, maintenance and upgrading of the system. The essentiality of features becomes patently obvious when users start using the product. Why try to predict them?

Alex Bunardzic 07 Feb 06

Exactly. 1.1 isn�t a promise it�s a suggestion.

But the wishlist, or a suggestion, does imply that we’re gazing into the crystal ball. If there is something that gets mentioned and we don’t see it as being important right now, why even bother with it? Why assume that it might get important later? Isn’t it a bit like an unnecessary balast to tag it along the way?

So, if you’ve stumbled upon the ‘it would be nice if we could lock the room’ idea, for example, and then realized that it’s not going to make vital difference to your product, why even stop to bother with it? You say that it might become vital in the future? How do you know?

JF 07 Feb 06

Alex, you are taking things way too literally. Lay off a bit.

v1.1 means not now, maybe later. That’s all. 1.0 is all about now. 1.1 is all about later.

Alex Bunardzic 07 Feb 06

v1.1 means not now, maybe later. That�s all. 1.0 is all about now. 1.1 is all about later.

I guess. You know the saying: better late(r) than never.

indi 07 Feb 06

one good thing about this approach is it makes you carefully consider what goes into each subsequent version (e.g. “do we really need that feature now”) … an important step to control feature-itis

Dan 07 Feb 06

But if you get rid of all of the “it would be nice if”s, doesn’t that mean the product won’t be nice?

Anonymous Coward 07 Feb 06

Dan:

But if you get rid of all of the �it would be nice if�s, doesn�t that mean the product won�t be nice?

Why does a product have to be nice? Look for example at iPod. Is it nice? I don’t think so. Still, it is a very prestigious and desirable product. But when you look at it and when you use it, there is nothing to write home about.

Adrian 07 Feb 06

It’s one thing to defer non-essential features to future versions, but another entirely to remove features from established products that are underused and/or dilute the product’s focus.

Anyone got any examples of this happening?

Mathew Patterson 07 Feb 06

An Anonymous Coward said, of the Ipod
But when you look at it and when you use it, there is nothing to write home about.

I think sixty bazillion websites, magazines and blog posts would suggest otherwise! Cleary there is something worth writing about.

Jon 08 Feb 06

hah. bunch of the stuff on that list are the stuff i was asking for when the test happened. good to see it will happen “sometime”.

sometimes i find that if you just get the essentials out and can get by on that you take longer to get the cool stuff out. like way longer. you dont have the excitement and energy of the initial launch to keep you motivated anymore. just my .02

Alipasha 08 Feb 06

good article, but what I don’t get is this:

Why not just call it “Signal vs Noise”? At least that is exactly how this pattern is called in the physics :-)

runningbehind.com
socialsmiles.com

Adrian 08 Feb 06

Has anyone considered that the value of determining essential vs. non-essential relies on subjectively answering the question, “For whom?”

When you’re designing for a client, ultimately they’re the arbiter of what’s essential and what’s not. That said, they may need a great deal of assistance in discovering their true requirements in much the same way that a good therapist can help people work out who they are and what they really want from life.

When you’re designing mass-market software, it’s harder. Who’s the client? Yourself? (Eating your own dogfood/scratching your own itch.) A demographic? (People like us.) An archetype? (Cooper’s personas.)

I’d be interested to hear who 37s think they’re designing for and by implication, how they decide what’s really essential for those people.

There’s a subtle but important distinction between personal design (designing something for your own use, and if anyone else likes it, fine) which is what often starts most open source projects, and egocentric design (designing ostensibly for others, but really just doing what floats your own boat.)

TJ 08 Feb 06

That is one of the better posts latley. Great job Jason.

JF 08 Feb 06

I�d be interested to hear who 37s think they�re designing for and by implication, how they decide what�s really essential for those people.

We design for ourselves.

Spencer Fry 08 Feb 06

You make some great points. I agree with many of the others that this is by far one of the best posts you’ve made lately.

Alex Bunardzic 08 Feb 06

Mathew Patterson wrote, regarding the iPod:

I think sixty bazillion websites, magazines and blog posts would suggest otherwise! Cleary there is something worth writing about.

Hmmm, just because there are gazillion of writeups on something, doesn’t automatically mean that the topic is worth writing about. Do you have any inkling about how many worthless writeups are posted daily on Jessica Simpson, Britney Spears, Hillary Duff…?

But getting back to the iPod — what is it that could be worth writing about that little thingy? To me, it looks like a cheap cigarette holder one would get at a dollar store. I fail to see where’s the great design.

On the other hand, it is exactly this blandness and extreme simplicity that made it into such a desirable and prestigious product. It beats the competition’s fancy and thus even more offensive design.

beckie 08 Feb 06

If you leave too much out of 1.0, you end up with a complex product lifecycle when evolving to 1.1 and beyond.

See how hard it is to add useful to and finish unfinished parts of Backpack…

BradM 09 Feb 06

I both appreciate and agree with your points on this topic. I would just be leary of the fact that if you leave out the ‘that would be cool’ or the ‘it would be nice if’ functional elements, you may lose a large share of the market. What I mean is, people hear about ‘Campfire’ as this new innovative chat tool and decide to try it out… however, room locking is essential for them to conduct a private conversation with employees and customers. If they were to try it out at v1.0 without room locking they may think…’This is a nice idea, but its lacking this or that’. Now they used the product once and never came back.

How do you overcome the challange that you may be losing some market share because you have left out the ‘cool’ features?

JF 09 Feb 06

How do you overcome the challange that you may be losing some market share because you have left out the �cool� features?

We’re not after the “this is cool” market. We’re after the “this is useful” market. Cool wears off, useful never does.

BradM 11 Feb 06

Sorry, I shouldn’t have used ‘cool features’. What I really meant was that the fact that what you may consider non-essential, may be essential others initially.

RichardB 12 Feb 06

The original post is proving useful to us, and we’re not building an app.

I work at a large university and much of the time we buy rather than build. Jason’s focus on the essential is also helpful when you assemble a team from across the organization and start to define the needs that the project will try to satisfy.

I expect that this focus on the essential willl prove even more valuable as we start to bring in vendors with pre-built solutions containing many features designed to tantalize the naive and defocus the unsuspecting.

We’re going to go into that process with our list of what
is essential and discpline the vendors to just show us how their product satisfies these essential needs. If it doesn’t do that part well and easily and in a fashion that the larger user community will learn in a jiffy, then the jazz really doesn’t matter.

Thanks, Jason. This was VERY helpful.

lil beeky 10 Oct 06

this some stupid shit

lil beeky 10 Oct 06

this some stupid shit

lil beeky 10 Oct 06

this some stupid shit