Dan 28 Sep 05

Great idea. I took your advice regarding “Hire your clients” thinking, and have a list of consulting services I will do, and what I wont do. It’s good for the customer, as well: no one likes half-assed products or services. You could provide them with tricks on how to still use your product without the feature (e.g. Ta-da List has not categories, headers or dates, so “—- My Header —-” will do.)

And consulting-wise, I could probably half-ass my way through anything, but I have friends who are better at lots of things. They like referrals, the client will have better work done, I’m not stuck & frustrated with something I don’t enjoy.

Mathew Patterson 28 Sep 05

I’ve done this on websites before - it is a liberating feeling. It also means you spend more time designing the really important parts of your site, making the little changes.

It can be a political challenge though. You need to be able to support your seemingly low-feature design with real numbers showing where your ‘sale’ is made or broken.

I’m also a fan of removing things from sites when they aren’t working, instead of letting them grow mouldy. The broken window theory applied to websites, I suppose.

Hugo 28 Sep 05

This is a very interesting concept and one I never thought about. I think we are all guilty of building a list of things that would be great in our product. We end up loosing focus and our web site becomes bloated with useless features.

Jamie 28 Sep 05

Just wait ‘til you see my web app that juices oranges!

Mark Gallagher 28 Sep 05

JF, I believe 90% of your religion, but this bit of advice….. I’m not feeling the mojo.

If I am at the start of project and coaching my team, I agree with other chapters in your bible. The part that says don’t have a long requirements gathering process where you list every possible feature / function from the business types and then, after you have this long list, you start to develop. I like your suggestions on starting with a few ideas, doing quick prototypes and see where it takes you.

But at the start, I also don’t want to coach my team to put together a list of what the project will not do. I don’t want a list that might kill the creative process where during the prototype phase, you see an idea or a new feature that you could not see in the beginning. You only see it when you kick the tires on a prototype.

At this point, having a list of what the project will not do just becomes a blocking tool.

Totally agree that scope creep is one of the biggest problems in web development, but there are better ways to manage that.

Good discussion.

Mark

Mark Gallagher

Jan 28 Sep 05

How about making those anti-feature lists somewhat public? It would be a very honest thing to do towards your customers. Codeweavers does something similar, by stating exactly what works, and what doesn’t work at the moment.

Casey Glass 28 Sep 05

I find that an ‘out of scope’ list is a great way to remove ambiguities in what problems a project is intended to solve. It is also great at stopping the dreaded scope creep!

Mark 28 Sep 05

What about making an initial list of every possible thing that the software could do (within context), and then start weeding out the unnecessary as the vision becomes more defined?

Sort of like a mind map for development instead of creative.

JF 28 Sep 05

How about making those anti-feature lists somewhat public? It would be a very honest thing to do towards your customers.

http://www.basecamphq.com/manifesto.php

Egor Kloos 28 Sep 05

When building websites you already have an out of scope list. As soon as you choose your CMS you already have default set of options. Anything outside that will cost extra.

However, stating to the client what you can’t do or rather what they shouldn’t want to need in the site aviods, to a point, an expectations issue.

I think you can approach the do I or don’t I paradiam with a ‘do this and not this’ list. Define your boundries alround and spin it anyway you need to for the client. Define what you can build, what you already have built, what you shouldn’t and what you can’t. What you of want or need to build outside the set boundry becomes a seperate sub project.

JF 28 Sep 05

What about making an initial list of every possible thing that the software could do (within context), and then start weeding out the unnecessary as the vision becomes more defined?

Have fun! This will only serve to broaden the vision. Once you have something on paper, and a bunch of people involved in making these suggestions, removing items becomes a huge political battle. No one likes to see their suggestions pulled. This is a sure fire way to start a project off with low morale.

Matt 28 Sep 05

I think this is a good practice as long as your reasons behind an item being on the “anti-list” are sound. If something makes the list because “so-and-so is also doing it” or not, then you’re focusing on the wrong thing and your product/project will suffer.

Mark 28 Sep 05

Jason,

I guess if you’re working on a small team of 3, and you’ve got the right people on that team, then those political battles should be at the very least minimized, if not completely erased — right?

If you’re going to write down what something won’t do, you’ve got to at least have a concept of what it’s going to do, both in the initial (half-product) phase and in the long run. Wouldn’t it be easier to have all that written down as possibilities and then scale back appropriately?

David 28 Sep 05

Along the same lines, when redoing a project/component, it’s often helpful to put everything on the “anti-feature” list and make those involved argue to “allow” it back into the product. You end up with a lot less bloat if features must be defended.

Anders Toxboe 28 Sep 05

Requirements change - so do the anti-requirements.

In an agile environment, isn’t it the selection of which features to implement from iteration to iteration that defines the anti-requirements? The features that never get a chance to be implemented are the anti-requirements.

So is this necessary? I think the process of thinking it through is necessary, but not the creation of a static list of anti-requirements as they change just as regular requirements do.

JF 28 Sep 05

Along the same lines, when redoing a project/component, it�s often helpful to put everything on the �anti-feature� list and make those involved argue to �allow� it back into the product. You end up with a lot less bloat if features must be defended.

Yes, that’s a good way of thinking about it. Everything’s OUT to start and features need to win their way in.

Matt 28 Sep 05

Along the same lines, when redoing a project/component, it�s often helpful to put everything on the �anti-feature� list and make those involved argue to �allow� it back into the product. You end up with a lot less bloat if features must be defended.
———
Yes, that�s a good way of thinking about it. Everything�s OUT to start and features need to win their way in.

In my experience, taking features away from people that already have it, regardless of whether they use it or not, can be very painful. Even though YOU know you’re giving them a better product, their perception is that you’re now giving them less.

Laurel Fan 28 Sep 05

Now that I think of it, an anti-feature list is also a good way to find the features that _should_ be planned for future releases but aren’t. If I put something that everyone else has been implicity assuming will be a part of V n+2 on the anti-feature list, I’m giving my fellow team members a chance to convince me that it shouldn’t be there. It’s just another way to narrow the “don’t know” and unspoken assumption gap between “definitely going to be in” and “definitely going to be out”; there’s no reason why it would only result in the “don’t know“‘s being put on the out list.

Geof Harries 28 Sep 05

In my experience, taking features away from people that already have it, regardless of whether they use it or not, can be very painful. Even though YOU know you�re giving them a better product, their perception is that you�re now giving them less.

This is not my experience. If you have a healthy, open relationship with the client (whether internal or external) and are confident in your project planning methodology, then passionately convincing them is not difficult.

As long as you can prove your point with solid results, minus the fluff that was initially thought to be key to its success, then your track record will speak for itself. The trick is to learn how to be an effective negotiator in this regard.

Matt 28 Sep 05

This is not my experience. If you have a healthy, open relationship with the client (whether internal or external) and are confident in your project planning methodology, then passionately convincing them is not difficult.

You’re right. The companies I’ve worked for have not had this kind of relationship w/ their customers so that is why I’ve had that experience.

All the more reason to start your project small and grow when necessary. It’s always going to be easier to grow then to shrink a product.

Geof Harries 28 Sep 05

It�s always going to be easier to grow then to shrink a product.

Amen, brotha.

Ben Askins 28 Sep 05

We tend to do this up front on all projects. We’ll explicitly list all “exclusions” along with “constraints” so that it’s clear to all stakeholders including the development team and the clients. Then when the product is delivered noone is left saying “But I thought it would…”.

Matt 29 Sep 05

Matt,

Your MerchBoss website/product is great looking and the functionality appears to be very well thought out. After working on a music label website myself, and being forced to implement a horrible old school shopping cart (it was several years ago) I would have loved to bring your app on board instead. Maybe next time!

Hey thanks Geof!

Scott Hampton 29 Sep 05

I’m glad to see this idea being discussed in the apps world. This is one of our critical tools in medical product design. We use a design input form (functional) that describes the users and their experiences if we get the design right. One of the big parts is that we have a feature ranking system. Features which are identified in brainstorming are later ranked as: Required, Mandatory, Desired, Useful, but also EXCLUDED.

Excluded: as in, marketing want’s the bells&whistles package to include free beer but it is NOT going to be done. Liberte!

Further in we have a section called “What this product won’t do”. This gets a lot of work, because clients want their first foray into a new market to be el supremo but they usually don’t know enough about the market to define every feature (who does?). So we drop into this bit all the optional stuff, or stuff competitors do that is actively being avoided. A lot of times we end up with positive product features included as negatives here, as in “The product does not require assembly.”