Goal oriented business analysis

September 28, 2010

Idea: Goal oriented business analysis focuses on trying to understand stakeholder’s goals rather than their requirements. Often requirements are ‘solutions in disguise’.

Trying to elicit stakeholder requirements is a common stumbling block in business analysis. Often stakeholders will discuss their favoured ‘solution’, suggesting how they would like a problem solved rather than explaining what the problem is.

Starting with a solution is bad for a whole host of reasons, not least because it closes down the design process before it has even begun. Taking a suggested solution (rather than a stated problem) to a designer or software developer severely limits the opportunity for them to explore the problem and propose creative solutions. This often results is sub-optimal, or worse unnecessary, system functionality being developed.

To avoid this problem and to fully exploit the creative resources of the problem solving team (including designers and developers), business analysts need to elicit problems rather that suggested solutions from project stakeholders.

Focus on the stakeholder’s goals rather than their requirements. Rather than asking stakeholders what they need, or what they would like to see developed (what their requirements are), ask ‘what do you want to achieve here?’. Get stakeholders to describe their vision of the situation under analysis after the problem is fixed rather (a goal) instead of how they see the problem being fixed (a solution).


Building the ‘right product’

August 27, 2010

Part of the Product Manager’s job is to make sure the ‘right product’ gets built.*

She must think about both the problem and solution to:

(1) Validate the need for the product (the problem)

By making sure there is actually a problem for the product to solve, who the problem affects, and how it affects them.

(2) Build an effective product (the solution):

a) Decide what needs to be done to solve the problem.

b) Communicate what needs to be done to the people who will actually build the product (what your product must do to solve the problem).

c) Monitor progress and steer when necessary.

In software development, tools and techniques to build an effective product include development methodologies like Agile, and actionable metrics.

Validating the need for a product requires a different approach. Key challenges are finding a problem in the first place, and establishing that the problem needs solving.

Steve Blank, and others in the world of tech startups discuss the problem/solution distinction in detail. Seth Godin talks about avoiding solving the wrong problem too.

The challenge for product managers, particularly those operating in established businesses with solid-looking boundaries and established-looking ‘best practices’, is try to apply some of what people like Steve, Eric, Seth and others teach.

Most importantly building the ‘right product’ means spending enough time in the problem space, and avoiding getting stuck in the more familiar solution space too soon, or for too long.

*’product manager’ is a term with different meanings in different contexts. The ‘problem/solution confusion issue’ is applicable everyone responsible for delivering an outcome, and who has some control (even indirectly) over both the problem and solution space. For example, this definition would includes many project managers and most entrepreneurs.