For many software teams the requirements document is the king of documents.

You know the routine. The software team works with the customer (or customer proxy) to put together a “complete” list of “requirements”. Once that is done, the team writes the software implementing the requirements and voila! the project is done.

Or maybe not.

Every software project I’ve ever been on has involved scope management. This is a process of determining if a requirement is truly a requirement for right now and whether it could be delayed until part of a future version or release. This is performed not only when “requirements” are being first developed, but also during development/testing/deployment in an effort to meet a project timeline constraint.

Words Matter

In the Agile development world, “requirements” is sometimes replaced with “features”.  This is a very important change, mostly related to the meaning of words and cognitive dissonance.

Think about it.  “Requirement” is based on the word “require” – something compulsory or necessary by rule. For someone to agree to postpone a “requirement”, you are basically asking them to admit it wasn’t actually required in the first place – thus, it wasn’t a “real” requirement.  And therein lies the problem…

Asking someone to postpone a “requirement” is asking them to admit a mistake.

This points to the beauty of using the word “feature” when describing the software desired.  Features connote desires.  And it is OK for customers to desire pretty much everything.  “You want features, load me up!”  Throw features on the deck, list them like crazy.  Pile them on, as project managers, we’re not afraid of hundreds or thousands of features.  Knock yourself out – as long as they are prioritized.

Once we start developing, we can then start having conversations such as:

• Do we have enough features to deploy?
• Would you like to change the priorities of the features you’ve listed?
• Any new features?”

Those are much, much easier conversations to have and project decisions will be made much quicker without the debates about whether a “requirement” is actually a requirement.

Removing features is very tricky and fraught with problems, even if those features are used by very few people.

New Follower Emails

The first example is when Twitter improved their new follower emails. Many articles where written about how it was a great improvement (and now in HTML!! heh). And the new follower emails are an improvement. However, as I wrote previously about the new follower notification emails, they actually removed a feature. Before the improvement, the emails included my Twitter id. Now they don’t, and that was important to me.

I’m probably not a typical Twitter user. Most people I know have only one Twitter account. Maybe I shouldn’t worry so much about staying “on topic” – that is the email marketer in me.

@replies

Recently, Twitter removed a feature used by a very small population of their user base. However, it caused quite a stir. (Twitter @replies Saga) It is interesting to note that this feature was removed because of the large processing load it placed on the Twitter database.

What is the lesson?

In both of these cases, if Twitter had not initially provided the feature, it probably would not have been a big deal.

And that leads to the lesson. If you are designing new software, keep this in mind. Adding features is easy. Too easy. Software features are really, really easy to add. Once users start using them, they are very difficult to take away.

So, do what the 37Signals guys have been saying – implement less features. You can always add them if your users request them.

Taking features away? Well, that’s a lot more difficult (and painful).

But they are broken.

I’ve read several articles talking about the “richer, HTML version” of the email. Richer? What year is it?  Formatting doesn’t make something “rich”, data does.

Data is rich, markup is lame.

The twitter got it right by adding more data about followers and updates, but HTML? Who cares.

The email still fails to include the person’s bio and their location. And what about maybe the last few tweets at the bottom of the email? They should give me more data, not less. There simply is no reason to not include the basic profile information about the new follower. It isn’t an overwhelming amount of data – include it twitter, please.

But this isn’t why the new twitter notification emails are broken.

The new emails are sent to my profile name. That’s it.

The new notification email is broken because it doesn’t include my twitter account name.

So now, the notifications say “Hi Philip Crawford”, when they used to say “Hi Philip Crawford (wiscoDude)” – or InboxFox or one of my other accounts.

Old style new follower email with almost no information

The improved new follower email with more information

I’m guessing most people have only one twitter account. I don’t. I have multiple twitter accounts because I have multiple “personalities” (I’m sure someone will snicker about that).

I have a twitter account for my email marketing company (@inboxfox), my programming persona (@philip_crawford) and my personal account (@wiscoDude). I keep them separate because I tweet about completely different things for all three. I don’t think my email marketing people want to hear about my drinking escapades or my morel hunting. And I know for a fact my personal friends don’t want to hear about the latest in email marketing reports. I’ve actually unfollowed some people in a subject domain because they tweeted too many times about their personal life – that isn’t why I follow them.

And this points out a current problem with the twitter. Multiple “personas” are not possible to implement with one account. I don’t think that is a huge problem and if I were Biz, I certainly wouldn’t be worried about it, but the email notifications don’t take this into account.

So there you have it. Twitter simply needs to include my twitter id in the email.

And follower bio, location, latest tweets….why are they skimping on text in this email?

As my friend Preston (@gl33p) pointed out, maybe this is simply opportunity for someone else to provide a service that Twitter has chosen not to provide.