Business Driven Goals - Why > What > How

​Whenever I am presented with a problem I usually jump straight in and start to think about the solution. It is a natural inclination I have to create a link between my knowledge and understanding, to the solution. I think that most people behave instinctively in a similar manner.

In that regards, I think it is very natural that when presenting a team with a feature that is to be developed, the language used is often based around HOW to create the solution.

A recurring problem that the teams I have been on, and our customer faced was to make sure the requirements defined WHAT is needed, and not HOW it was to be built. Over time this approach has been cemented, which was a very positive step forward.

It has allowed the team the ability to collaborate and Identify how best we can create a solution.

More recently we have started to be much more focused on defining stories based around the business value. It allows all members of the team to be conscious of the exact value being added with the work being done and keeps the work on focus. 

However, the feature that is being delivered is specific in its definition, so any attempt to define the business value for a story is inferred by the team. With a small amount of luck, the business value of the story will match the business value of the goal that the feature is trying to satisfy. 

But ...the team has not been told WHY the feature is to be built.

Quite possibly, the feature selected is not the best way to satisfy the business goal. 

Just as there is cognitive bias attached to presenting HOW to build something ahead of WHAT to build, there is a cognitive bias in presenting specifically WHAT to build ahead of WHY there is a need to build something. In each of these scenarios we are narrowing the scope of ideas.

We have previously learned that:

• By presenting a team with the steps to build a solution, it blocks them from creating better steps to the same solution.

To follow that same train of thought:

• By presenting a team with a solution to a business goal, it blocks the wider collaboration in thinking of better solutions.

By understanding the business goals that we are trying to achieve we improve by:

• Allowing teams to focus their efforts solely towards achieving that goal, and not wasting time exceeding the goal.
• Eliminating scope creep on features
• Eliminating pet projects
• Letting teams see which actions bring the goal closer
• Letting the team learn from steps that do not bring the goal closer

Lets be real - If a client decides that a feature will be of business value, and is paying for the feature to be built, its simply not feasible to suggest that the business goal be shared and that other solutions be explored. 

However, what should always be feasible is that the team can find out the business goals behind each feature, and also find out how to measure when the goal is complete.

So when we are looking at our goals, lets start with WHY, then we can look at WHAT, and eventually move to HOW.