The truth — you need a backlog.

Creating products is hard. Writing software to create the products is even harder because you first need to understand what you are writing software for. You need to be able to add value — otherwise your efforts are meaningless.

You need the requirements for the software. Somebody has to formulate, describe, show by an example, imitate, copy, steal…whatever technique is suitable for describing “what is it that I want”.

Keep track of your requirements — keep them simple.

In order to keep track of the list of “this is what I want”, you should have them documented — preferably in an easily readable and understandable format. Complicated requirements are just noise — they don’t add any value to anyone. Instead, complicated and inadequate requirements are the main cause for confusion, misinterpretation and misunderstanding. Don’t complicate things by using language that people don’t understand.

“As a product owner, I want to have global search in our web site so that our content can be searched.”

You’ve probably seen these types of requirements, right? What added value does that language provide to you? Really? As an alternative, consider this:

“We need to provide a global search for our users in our web site. The sarch function should be always accessible, maybe always visible. The search function should perform the search on whatever content we have on our site.”

That sounds more understandable, right? The tone of voice in the example above is more constructive, it is far more human and less formal.

People feel comfortable reading understandable requirements. And furthermore, the context of your requirements becomes self-evident.

Create your backlog. You will need it.

A well managed, documented set of requirements for your product may have many names. I like to call the set of requirements a “product backlog”.

Requirements change over time. And so does your product. And your backlog. For any given point in time, your backlog describes what the product looked like at that specific time.

Treat your backlog well

But what do you do with your product backlog? You will use your product backlog as a checklist for communicating and organizing your work around the product creation process. Your colleagues will use the product backlog as the source of information for understanding the goal and vision of your business.

The contents of your product backlog, at any given point in time, is the most valuable asset for you. Treat it with appropriate respect and be ready to sacrifice enough time to keep your product backlog in good shape.

That’s how you tell your teams, what you want.

It’s quite simple, isn’t it.

The next part of my blog series will focus on how to effectively communicate the contents of your product backlog. Especially when your backlog changes.