A term that tends to confuse the first time you hear it is "pain points," as in "Tell me the pain points of your sales process, and we'll use them to design our new sales application." In this example, pain points might include things like "complex paper quotation forms" or "difficulty getting price quotes." Essentially, thinking about pain points is a way to tease discussion points and ultimately requirements from someone, a useful trick in IT where you're often trying to design new systems and processes for business or functional areas where you may have limited content knowledge.
The pain of pain points
While there's nothing wrong with using pain points to drive a discussion, they're often focused on symptoms and immediate need, rather than root causes and long-term growth. Imagine if doctors only focused on pain points. Aspirin might immediately fix the pain in your head, but leave the brain tumor undiagnosed; or, a one-time prescription might soothe a troubled stomach for a few days, while a diet change could potentially alter one's life for the better. Pain points also tend to focus on the negative, highlighting dysfunctional areas of a process or technology rather than unexploited opportunities.
The Art of the Possible
It may seem like a semantic game initially, but rather than focusing on pain points, try exploring the Art of the Possible (AOTP). AOTP is what you could accomplish without today's constraints, be they technology, process, organization, or economic climate. With a focus on pain points in our sales application, we might tweak some process steps, automate some existing forms, and perhaps enable some approval workflows. Shifting the focus to AOTP, we might conclude that our sales application is unnecessary, and the organization ultimately needs to abandon and redesign its current sales process.
AOTP allows you to consider the optimum solution to a problem without being constrained by today, a useful exercise if you are in search of innovation or ways to offer dramatic value. As Henry Ford is supposed to have said: "If I asked customers what they wanted, they would have told me 'a faster horse.'" Solving pain points is largely a commodity business; dramatically reshaping something and bringing compelling value is far more interesting.
The magic happens in the middle
As you gain momentum in discussing AOTP, avoid immediately dismissing suggestions that seem outlandish, or impossible given the constraints you're currently working with. Let AOTP discussions occur with a "blank slate" of sorts, as you want to keep ideas flowing rather than impose constraints that may prove to be invalid. With a docket of unconventional ideas, you can now shift the discussion back to the pragmatic, using tools like pain points. Somewhere between the two approaches you will often find high-value requirements and ideas that would have been missed had the discussion focused solely on one area or another.
In IT in particular, where we tend to have a solution-driven focus, it's easier to talk about pain points, since they can be fit neatly into one of the solutions in our toolkit. However, removing the constraints of tools and technologies, and any other constraints, allows for far more creative problem solving. It's also a more interesting process for our peers who are providing us with their requirements. It's rare that they're asked to consider what they could do in an unconstrained environment, and an IT leader who can help bring this perspective will be perceived as far more valuable than yet another person traipsing through their door asking about the day's pain points.
Patrick Gray works for a global Fortune 500 consulting and IT services company and is the author of Breakthrough IT: Supercharging Organizational Value through Technology as well as the companion e-book The Breakthrough CIO's Companion. He has spent over a decade providing strategy consulting services to Fortune 500 and 1000 companies. Patrick can be reached at firstname.lastname@example.org, and you can follow his blog at www.itbswatch.com. All opinions are his and may not represent those of his employer.