The "Ugly" Workaround: Why Your Next Big Feature is Hiding in a Manual Hack

You’re looking at your roadmap, trying to decide which high-impact feature to build next. You’ve looked at the "competitor gap," you’ve read the support tickets, and you’ve...

A
Written by Albert
Read Time 4 minute read
Posted on March 5, 2026
The "Ugly" Workaround: Why Your Next Big Feature is Hiding in a Manual Hack

You’re looking at your roadmap, trying to decide which high-impact feature to build next. You’ve looked at the “competitor gap,” you’ve read the support tickets, and you’ve even run a few surveys. You’re looking for a “new” idea that will finally unlock growth.

But here is the background anxiety: surveys are just a collection of opinions, and competitors are often just as lost as you are. You’re worried that you’re about to spend three months building something that people say they want but won’t actually hire.

The mistake is looking for what’s missing. You should be looking for what’s already there—specifically, the “ugly” hacks your customers have invented to survive.

The Diagnosis: Demand is a Behavior, Not an Opinion

In Advanced JTBD (AJTBD), we look for Compensatory Behaviors. These are the manual workarounds, the “taped-together” spreadsheets, and the messy Slack workflows that users create because existing tools aren’t getting the job done.

When a customer hacks a solution, they are providing the ultimate evidence of demand. They aren’t just saying they have a problem; they are investing their limited energy to fix it.

  • The Opinion: “I wish this app had a better reporting tool.”
  • The Compensatory Behavior: “I spend two hours every Friday morning manually copying data from your app into a Google Sheet so I can create a specific chart for my boss”.

If you build for the opinion, you’re guessing. If you build for the behavior, you are automating a transformation that is already happening.

Reframing: Finding the Gap in the Job Graph

To move from uncertainty to clarity, you must stop viewing your product as a static set of features and start viewing it as a piece of a Job Graph—the sequence of goals the brain generates to solve a need.

A compensatory behavior is a “Level 1 Product Job” failure that blocks a “Level 2 Core Job”. When you find a user exporting data to Excel just to reformat it, they are performing a “Meaningless Step” or a “Tax Job”.

Your goal isn’t just to “add a feature.” Your goal is to kill the job.

  1. Identify the Hack: Where are users leaving your app to get something done?
  2. Map the Upstream/Downstream: What triggered the hack (Upstream), and what is the final outcome they need (Downstream)?
  3. Automate the Progress: Build the solution that eliminates the manual step entirely, collapsing the Job Graph and reducing the user’s energy debt.

Practical Application: Auditing for Hacks

Stop asking “What should we build?” and start asking “What are you doing right before and right after you use our tool?”

  • Audit your “Exports”: If people are frequently downloading CSVs, they aren’t just “saving data.” They are moving it to a place where they can actually make progress. Find out what happens in that CSV.
  • Look for “Non-Consumption”: Find people who looked at your product and went back to their old way. Don’t ask why they didn’t like you; ask what specific part of their “Same Old” felt safer than switching.
  • Interview for the Timeline: Ask users about the “First Thought” that led to a workaround. If they aren’t hacking a solution, the “Push” of the struggle isn’t strong enough yet.

Moving to Clarity

Building on intuition is a gamble. Modeling your market based on the mechanics of compensatory behavior is a strategy. When you name the specific hack the user is already performing, your product stops being an “option” and starts being a necessity.

BHAG AI helps you escape the “abyss of the unknown” by using AI + Advanced JTBD to model these complex Job Graphs and identify the high-leverage compensatory behaviors in your market. We help you find the unmet demand that users are already proving with their messy workarounds.

Stop building for what they say. Start building for what they do.