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 worfklow processes.
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.
A client example
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 business 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.
Why optimizing business workflows early pays off
People and organizations are busy, leaving little room for internal reflection and meaningful optimization. Making time for analysis is critical, whether done early when it’s cheaper or later under pressure. Avoiding the root cause of pain only delays the inevitable, often worsening the problem over time. Ignoring core issues may lead to irreparable challenges that become much harder to resolve later. Avoid the temptation of temporary fixes or the “more duct tape” approach.
When working with customers on process optimization, we often see a tendency to repeat outdated practices. Many justify unnecessary complexity with the common excuse: “because we’ve always done it that way.” While tools do matter, they are not the root issue. No tool, regardless of sophistication, compensates for poor application or underlying inefficiencies.
Consider learning a skill like speaking French or playing golf—buying expensive tools won’t guarantee progress. Tools only amplify effectiveness when properly applied. We encourage customers to upgrade their tools while addressing the deeper sources of inefficiency. Eliminating pain points fully, rather than simply reducing symptoms, creates lasting improvements.
The fixation on tools dominates the business world. Requirements documents often list functions, features, and settings in exhaustive detail. Rarely do they prioritize time, attention, effectiveness, or measurable results. However, these outcomes represent the true goals—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 business workflows. Analysis of the underlying causes of pain paired with the right tools for the job leads to results.