We’ve talked about scaling and 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 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, it’s 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.
| Reference: | The New Agile–Picking A Winner from our JCG partner Gil Zilberfeld at the Geek Out of Water blog. |
[The team spends 6 months building it, then shows it to me, and I say, “it’s not what I wanted”] This should be obvious, but that sentence does not describe Agile in any way. There should never be any time when a customer goes 6 months without seeing the product. What you have described here is classic Waterfall, and suffers from the really big problem of Waterfall – that decisions are made at the beginning, when the least is know about the project. In an Agile project, the customer would have seen the development of the feature (and, BTW, a… Read more »