When working with our customers, we talk a lot about pain. That is, the sorts of pain your business deals with right now that we can help resolve. We make software for business productivity, so people come to us with some form of pain, hoping that we can help them get to the bottom of it and fix their problems. We focus on understanding the root pain points of business process.
Treat the problem, not the symptoms
This may sound like an obvious approach to helping people, but there’s a key point here: a surprising number of people approach the treatment of pain by addressing the symptom, rather than the cause. Think of a doctor’s mission in treating a patient with back pain. Her first order of business is not to immediately pump in the drugs. Rather, she starts by asking questions:
- How long has it been hurting?
- Did you put any strain on your back?
- Have you had these problems in the past?
The key to helping people is to dig in and figure out the underlying sources of pain.
Let’s take this to a business context. Businesses come to us with common problems in their data collection, reporting, and decision-making process. But I’m continually shocked at how many approach the problem from the wrong end. It’s commonplace for a conversation to start out with an analysis of tools and functions — “what does this do?” rather than “why do we need to use it?” Features and functionality are absolutely critical to understand at some stage of your process, but not the first step.
When we work on Fulcrum, we’re always putting our product decisions through that filter first. “What underlying pain will this solve?” as opposed to immediately digging into technical specs and the “how” of the problem solving process. Once we’ve decided to do something for the right reason, the “how” part will happen with minimal problems.
Here’s a story to put this all in context —
We were sitting with a customer to build a pilot app with Fulcrum for a damage assessment project. They wanted a tool for completing some inspection forms that fed a fairly complex workflow for the data in collection, budgeting for supply delivery, scheduling, and progress reporting. We sat down together at a whiteboard to prototype a survey, with the Fulcrum app designer open, and to figure out what needed to go in their initial inspection survey. Within about 5 minutes of group discussion and hands-on building, the conversation went from “what needs to be on this form” to a much deeper discussion on process. As we added fields to the survey, for each one we asked the “W” questions — Why do you need to capture that? How does it get used? Who needs to use that to make decisions? After about the first dozen survey pieces, their operations and analysis teams were in a deep discussion about value, time, attention, and a true analysis of the “why” of their process. Many people would call this “arguing”, but it was valuable! The only way to get to the bottom of the process was to hash it out. That didn’t obviate the need for tools, far from it. It made the end result much more effective once deployed. Rather than taking the medication to reduce the immediate pain of their process, they were actually understanding their process better.
People and organizations are busy, and the number of great opportunities for internal reflection and optimization are few. But making time for this sort of analysis is critical and will have to be done eventually — either up front when it’s cheaper, or under duress 8 months into the project with so much inertia that it’s hard to fix. The trouble with treating the symptoms and not the cause of pain is that you’re just kicking the can down the road. You’re going to have to deal with those causes eventually, and by the time you do they may have metastasized into a major irreparable problem. Don’t go with the “more duct tape” solution.
What we see so often in working with customers on process, where Fulcrum fits into the flow, is the tendency to do “what we did yesterday”, or to justify the complexity of a process with that classic line: “because we’ve always done it that way”.
Tools do matter, to be sure, but they aren’t the first problem. No matter how fancy and complete your tools are, they’re only as good as how they’re applied. Your first step in learning how to speak French or how to play golf shouldn’t be to buy 35 books or to spend $3,000 on your first set of clubs. Tools don’t get you to your goals on their own. I encourage our customers not only to improve their tools to amp up their game, but also to take a hard look at their underlying pain and how we can fully eliminate it, not just reduce the fever.
The fixation on tools is all over the business world. Look at any requirements document and you usually see a list of checkboxes, a bulleted list of buttons it needs, options, settings — a laundry list of functions. You’ll rarely see the reference to time, attention, correctness, effectiveness, or results. But these are the real objectives, the “ends” rather than the “means”. As I mentioned in another recent post, people too often look to technology to resolve their human-induced problems. Tools can certainly help bridge gaps, but shouldn’t be forced to solve everything (because they won’t). Perhaps a problem is really a training issue. Perhaps your field operations staff haven’t been trained with the knowledge to understand the impact of their actions. Maybe they need to know “here’s how we use this data, this is why it’s important” vs. “this field is always required”.
Our job is to help companies optimize their processes through better data and workflow. Analysis of the underlying causes of pain paired with the right tools for the job leads to results.