Beginning With The End In Mind

What does test-driven-development (TDD), acceptance criteria of user stories and drawing a line in the sand of lean startup analytics all have in common?

They are all engineering/product development applications of Stephen R. Covey’s habit „Begin With The End In Mind“ of his famous and highly recommendable book „The 7 Habits of Highly Effictive People“. Every method forces you to think upfront about when your end product is considered to be a success.

Whereas Stephen R. Covey’s approach relates more to personal development, I have come to the strong believe that this is also a very important method in engineering and every structured approach of achieving something.

But why is beginning with the end in mind so important?

In general it is highly important because it forces you to think about the what before thinking or even getting lost in thinking about the how. Or as Covey puts it „It is possible to be busy – very busy – without being very effictive.“. In other words if you start doing something without thinking clearly about the end result you could be very efficient without being effective at all.

Example?

Have you ever attended a meeting which didn’t have a clear goal ending up jumping from one topic to another and having no result at all?

Have you ever started a task ending up not finishing it completely because you didn’t know when it is considered to be completed and doing something else seemed more important than thinking about when the task is considered to be finished?

Have you ever developed a system ending up in a system which was rejected by its potential customers because you did not have a working feedback cycle including clear criteria when a customer experiment is considered to be successful?

Have you ever written a piece of software and you didn’t know what it was supposed to do ending up not understanding it any more a couple of weeks after writing it and throwing it away completely?

So what to do?

The idea is to have the goal in mind including very specific ways of determining when this goal is reached. The SMART criteria can give you good guidance on how this can be done.

For example in TDD you are forced to make very specific testable assumptions (called assertions) about your code before writing the code itself. Acceptance criteria of user stories behave the same way in regard to new features of a product. You define upfront when something is considered to be successful without even thinking and possible getting lost in how to achieve that. Drawing a line in the sand when conducting customer experiments helps you to clearly and objectively find out what the customers think about your product and what steps to take next.

Be careful

Whereas TDD forces you to make testable assumptions, other methods don’t necessarily do that. That is why you have to make sure to establish a measurable goal to determine success or failure. Otherwise you will either end up not reaching any goal at all (e.g. feature creep) or you will end up accepting something as a success which actually is not (confirmation bias).

dominik

dominik

Add comment

Follow us

Don't be shy, get in touch. We love meeting interesting people and making new friends.