We’ve talked about scaling and agile methodology on how to build stuff, but hey, we want to know what to build, dammit!

Unfortunately, SAFe, scrum, XP, or Lean Startup don’t talk about what we need to build. Just how to get it out the door.

Picking a winning product seems like the holy grail. Business analysis and agile product management methods can help us with it.

The problem is that some of the regular methods didn’t deliver. They relied on gut feelings, or subjective interpretation of information. And they didn’t take into account how complex the market is.

A couple of methods, that have a lot in common, have surfaced in the last decade, and changed the way we think about the problem. They try to revert the way we build to a way that makes sense in our reality.

First we need to explain what doesn’t make sense. Let’s say I, the product manager,  know I need a feature. The team spends 6 months building it, then shows it to me, and I say, “it’s not what I wanted” . Sounds familiar? We can say that the customer (me) never knows what he wants, but that’s getting off easy. The real problem is that the team didn’t understand what problem it was solving. If the team understood the problem, they might have come up with a different feature to solve the problem, and wouldn’t have wasted 6 precious months.

The problem starts with us not asking “what problem does the feature solve”. Even more so, we should start with the problem, and then build the feature that solves it. This is what stands behind Chris Matts’ Feature Injection. Apart from the cool name, there is real understanding of the need, and only then suggestion for a solution. It’s what stands behind Gojko Adzic’s Impact Mapping, in which we start with the impact we want to achieve, then figure out how to build it. And it’s what stand behind Liz Keogh’s Capability Red, where we want to understand the customer in order to develop a solution for their problem.

And don’t forget of Design Thinking –  actually seeing what the problems are, then coming up with a solution.

In all cases, there might be a smaller, easier and cheaper solution than the one we thought of first. Once we understand the need or the problem, we can suggest multiple solutions, than pick the one to try.

You are probably thinking at this point: This is just common sense. These are simple ideas. Why, I could have thought of that!

Well, this kind of agile thinking is not that common. Organizations continue to develop what their product people think, they deploy the solution and then see what happens. Only then, understanding what happened in hindsight. That’s a big ass feedback cycle.

It may not be common, it may not be easy, but it is simple agile sense.