A few months ago we wrapped up a large project that spanned probably nine months and was successful in numerous ways. I go over and over in my mind why this project turned to be successful where other projects have not, and why we do not implicitly apply some of the things we have learned to work to other projects easily.
In order to be really successful, the team needs to fully understand the problem at hand, and they need to understand it from every stakeholder’s position.
For this project I mention, we were handed a problem, not a product with well-defined requirements, customer expectations and the like. These types of projects call for a very different type of approach from the team and I think our difference in approach led us to a lot of our success.
The more I have worked with ideas put forth by Jeff Patton and the folks from Luma, the more I understand the importance of the Product Manager in properly framing the problems that development teams are employed to solve. We do not have this position however, and I suspect a large number of teams share our experience. The lack of this position is probably rampant throughout internal software groups where that organization is not selling a software product.
Here is why not having that position hurts: Understanding the problem and the research that lies behind the possible solutions.
Anyone on our project team would say that we spent a massive amount of time and energy around understanding the core problems and why we chose to do this project in the first place and that it made them a little bit nervous or uncomfortable. We spent perhaps six out of nine months spent evaluating our own internal assumptions, better understanding the life of our actual users and boiling down a large backlog of issues we had been tracking to a smaller list of core problems we could attack in a more holistic method. We purposely refrained from talking in terms of a solution during these times.
On one hand, it is probably difficult for software teams to spend this much time evaluating the problem instead of focusing on the solution, because it is more difficult to show observable progress when it comes to research. At the end of the day, most product owners and managers want to see mock-ups, what things are going to look like - they want to see software.
But so much of software isn’t about the software at all. It is about how people use it and how they are made more productive, enabled to do something they could not do before, and so on. So if you’re going to write or update software to fix a problem, shouldn’t you fully understand this starting point?
When people approach us with the problem and the solution in the same hand, we immediately see a red flag; we need to know how we got from this particular problem to this particular solution and why that is so. We seem to do a much better job when we better understand the problem, have a sense of context in drafting potential solutions, and validating those with our stakeholders.
It reminds me of this:
Ty: Just be the ball. Be the ball. Be the ball. You’re not being the ball Danny.
Danny: It’s hard when you’re talking like that.
We can’t be the ball when we’re already talking about solutions and next steps.