In simpler terms, it’s a case of defining scope for the business at the beginning. External variables that cannot realistically be influenced by the business (like getting this guy a better paid job) are outta scope. Lowering the expense of the car maintenance could very well be in scope.

Does that sound about right?

Thanks for the great question, and tangible example!

“Too far” can be defined a couple ways, depending on if you’re thinking about it “as a business” or “for a user.”

As a business, if your strategy / vision / positioning (in the market) is that you offer solutions to make the cost of vehicle ownership lower, then that’s where you would stop. Imagine if a rental-car company outsourced “car maintenance” to your company, so that they could focus on distribution, marketing, and rental-services. Yes, tire-inflation is part of it, but everything that makes it cheaper to operate the vehicles is “fair game.” Things like “we (as a rental car company) don’t have enough revenue” would be outside of your (self-defined) scope.

When focusing on “for a user” – picking the right abstraction level becomes a focus on “can I make a difference?” If your (scope of) product development does not include helping users get higher-paying jobs, then that is an abstraction level that is “too high.”

Really, it is the same analysis as the business-version.

However, when you’re thinking about longer-term strategy, it is useful to think “too abstractly” about the current problem on which you are focusing. When you’re ready to grow beyond your current product, one direction for growth is to solve “other problems” for your current customers. The abstraction may help you find those “other problems.”

Does that help?

But, if we are getting picky about the example you reference, Scott….

“The article goes on to describe a problem manifestation*, labels it as a problem ”

Then couldn’t you get abstract on your oft-cited tyre example and say that “my car is too expensive to maintain” is a problem manifestation of the problem “the job I do ain’t paying enough money to cover all my bills (including my expensive car maintenance”.

Defining “expensive” in appendix?

I’ve seen the same thing start to propagate through a very “inside out” organization. In some of the meetings, after starting to focus on the problem statements, when people asked “do we need to worry about…” with a very solution-centric perspective, I was able to say “if we decide to solve problem X” and have people nod their heads.

The PITA factor can be a very real one with people who are focused on controlling “what do I have to do?” instead of “what needs to be done?” I’ve had some success with embedding a cause and effect diagram directly into the problem-statement section of the BRD. That gives those solution-focused people the opportunity to absorb the eureka! perspective offline, save face, and bring a changed perspective back into the team dynamics.

Just by introducing overarching problem statements to the initiation phase has been a quick win and is making stakeholders, product managers and sponsors think “requirements” rather than “solutions”.

It’s a challenge getting them to that right level of abstraction as you said and I often feel like I’m being a real pain in the @ss constantly asking “so what?” and “why is that a problem” but it’s worth it to get to that “eureeka” moment.

Keep up the good work, loving the articles.

The Demon – Sunny Scotland