How to Spot a Broken Workflow Worth Building a Product For

A broken workflow rarely announces itself as a business opportunity. It looks like another email to chase, another invoice to correct, or another spreadsheet someone has to update by hand. The team knows the process is annoying. They may even have built a workaround. But annoyance alone doesn’t prove that a product should exist.

The useful question is not simply, “Is this frustrating?” It is: “Does this frustration happen often enough, cost enough, and affect enough people that they will change their behavior—or pay—to make it go away?” That’s the difference between a complaint and a product opportunity.

A disciplined workflow audit can help you find that difference. By tracing what people actually do, including the patches between their tools, you can uncover problems that are persistent, expensive, and poorly served by existing options. Then problem validation helps you test whether the pain is real beyond your own team before you invest in building.

Frustration Is the Seed, Not the Proof

Many durable businesses begin with someone who is tired of a recurring problem. A founder sees a task taking hours that should take minutes. A service team keeps correcting the same mistake. A customer sends a frustrated email because a routine request has disappeared into a chain of replies.

That frustration matters. People who experience a problem firsthand often understand its messy details better than someone looking at it from the outside. They know which exceptions derail the process, what information goes missing, and which workaround the team trusts even though nobody likes it.

But personal frustration can also distort the opportunity. The problem may be specific to one unusual client, one outdated system, or a company with an unusually high tolerance for manual work. A product built around one team’s preferences can become an expensive custom solution with no repeatable market.

Use frustration to identify where to investigate, not to decide what to build. A useful early hypothesis might be: “Small agencies lose billable time because client approvals and invoice details are spread across email and project tools.” It describes a customer, a costly consequence, and a possible cause. It does not yet assume that the solution must be a new app.

Start With a Workflow Audit, Not a Feature List

A workflow audit is a practical examination of https://www.inc.com/benjamin-laker/why-the-best-business-ideas-come-from-the-messiest-workflows/91350475 how work moves from request to completion. The goal is to capture the real process—not the idealized version in a handbook, a sales deck, or someone’s memory.

Choose one recurring process with a clear beginning and end. For example, follow a client change request from the first email through approval, delivery, and invoicing. Map every step, person, tool, decision, delay, and handoff. Include the exceptions. The “normal” path may look efficient while exceptions create most of the cost.

Questions to Ask During the Audit

What event starts the workflow, and how does the team know it has started?
What information is required, and where does it first appear?
Which tools hold that information—email, invoices, spreadsheets, project software, or chat?
Who copies or re-enters the information, and why?
Where do people wait, follow up, make decisions, or correct mistakes?
What happens when a client changes the request or an approval is delayed?
How often does the process run, and how much time does each run consume?

Observe work where possible. Ask someone to show you the last three examples rather than describe the process from memory. The difference can be revealing: a team might say approvals are tracked in project software, but the actual approval arrives in email, gets forwarded to a manager, and is eventually recorded in the project after delivery.

That gap between the documented workflow and the lived workflow is where many opportunities begin.

Look for Tool Sprawl and Patchwork Workflows

Tool sprawl is not automatically a problem. A team can use several well-connected tools and operate smoothly. The warning sign is the patchwork between them: people manually moving information because the tools do not share context, ownership, or status.

Consider an agency handling a new client project. A request arrives in email. Someone copies the scope into a project board. The account lead asks for approval in another email thread. A contractor records their hours in a spreadsheet. Later, an operations person compares that sheet with the project plan before preparing invoices. Each tool may work as designed. The workflow still depends on memory, copying, and interpretation.

Workflow signal What it may indicate What to investigate The same details are entered more than once Systems do not pass reliable information between steps Which fields are duplicated, and how often do they differ? People search email to establish status The source of truth is unclear or incomplete Who needs the status, and what decision depends on it? Invoices require manual reconstruction Delivery, approval, and billing data are disconnected What causes corrections, delays, or unbilled work? One person acts as the human integration Critical knowledge is concentrated in a coordinator What breaks when that person is unavailable?

Do not jump straight to “integrate everything.” Sometimes the problem is not missing software connectivity. It is unclear ownership, inconsistent inputs, or a process that has never been defined. A new product is unlikely to fix a workflow that has no agreed rules.

Understand the Pressure on Agencies and Productized Services

Agencies often feel workflow friction acutely because their margins depend on delivering repeatable work efficiently. Every extra follow-up, correction, and coordination step consumes capacity that could have gone to client work. At the same time, clients expect responsiveness and visibility, even when the agency’s internal process is stitched together from multiple tools.

Productized services intensify this pressure. Standardizing an offer can make delivery easier to sell, but the operation behind the offer still has to manage intake, exceptions, approvals, handoffs, and invoices. A service can look simple to the buyer while requiring a complicated series of manual decisions behind the scenes.

That makes agency operations a valuable place to look for product opportunities—but not every internal annoyance should become software. Start by separating these cases:

Repeatable coordination: The same people repeatedly move the same types of information between steps.
Unusual client variation: Each project is different, and the workflow changes substantially every time.
Capacity pressure: The process works at low volume but breaks when the team adds clients or service lines.
Policy confusion: People disagree about approval rules, billing triggers, or who owns a task.

The first and third cases may point toward a product, automation, or a better system of record. The second may call for a flexible service operation rather than a rigid product. The fourth usually needs a clearer operating policy before software will help.

Measure the Cost Beneath the Complaint

“This takes too long” is a useful opening, but it is not yet a business case. Estimate the cost in several dimensions. Time is one; rework, delayed cash, missed revenue, risk, and lost customer confidence may matter just as much.

For example, if a team spends ten minutes reconciling each invoice and issues 120 invoices a month, the direct effort is measurable. But if invoice errors also create days of delay, trigger client disputes, or lead to unbilled work, the true cost is larger. Ask for examples and records rather than relying only on broad estimates.

Signals That the Problem May Be Worth Solving

It happens frequently, not just during unusual busy periods.
It has a measurable consequence, such as labor, delay, rework, or revenue leakage.
People already spend money or effort on workarounds.
The workaround depends on a person’s memory or special knowledge.
The problem appears across multiple teams or companies with similar workflows.
The buyer and the person experiencing the pain can be identified.

Look for behavioral evidence. Someone who has created a spreadsheet, hired an assistant, paid for a tool, or built a fragile automation is demonstrating that the problem is important enough to act on. Someone who says “I’d definitely use that” in a casual conversation is offering a much weaker signal.

Use Problem Validation Before Building

Problem validation tests whether a specific customer segment consistently experiences a problem and whether it matters enough to change behavior. It should happen before you commit to a full product build—not after you have designed the interface and need people to confirm your assumptions.

Interview people about recent events. Ask them to walk through the last time an invoice needed correction, a request got lost in email, or an approval delayed delivery. Find out what happened, how often it happens, who got involved, and what the consequences were. Avoid leading with your proposed solution. “Would you use a tool that fixes this?” invites politeness, imagination, and hypothetical enthusiasm.

A Practical Validation Sequence

Define the user and situation. For example: operations leads at small agencies managing fixed-scope monthly services.
Write the problem hypothesis. Name the recurring task, the failure point, and the cost.
Interview several people in the target segment. Compare their actual workflows and recent examples.
Test the smallest intervention. Try a checklist, a concierge service, a lightweight automation, or a manual prototype.
Ask for commitment. Look for a pilot, data access, a scheduled implementation, or payment—not just compliments.
Review the evidence. Decide whether to build, narrow the audience, change the problem, or stop.

A manual pilot is especially useful for workflow products. You can simulate the proposed service behind the scenes and learn which information is essential, where exceptions occur, and what users trust. If the workflow cannot be delivered reliably by a person with a simple process, automating it may only make the confusion faster.

Account for AI-Driven Expectation Inflation

AI has raised expectations. Customers increasingly assume that software can understand an email, extract details, create a task, answer a question, and update an invoice with minimal effort. In some cases, that capability creates genuine value. In others, it makes a demo look impressive while leaving the underlying workflow unresolved.

Be precise about the job AI would do. Does it classify incoming requests, find missing invoice information, summarize an approval thread, or suggest the next action? Then ask what happens when it is uncertain. A wrong interpretation can create more work than manual handling, especially when billing, scope, or client commitments are involved.

The durable product opportunity is usually not “add AI to a messy process.” It is to create a dependable outcome. AI may reduce one step, but the product still needs clear inputs, permissions, status, review, and a way to correct mistakes. The workflow is the product’s foundation; AI is one possible component.

Decide Whether to Build a Product

Before building, compare the problem with other ways to solve it. A clearer process, a better use of existing tools, or a small integration may remove most of the friction. A new product makes more sense when the pain is repeated across a reachable customer group, existing alternatives leave a meaningful gap, and a focused solution can deliver an outcome customers value.

Use these questions as a final screen:

Is the problem frequent and costly for a clearly defined customer?
Can you describe the workflow failure without describing your proposed features?
Have customers shown action, not just interest?
Can the solution work across similar customers without turning into custom consulting?
Can you reach the people who experience the pain and the people who approve spending?
Will the product fit into the workflow people already use, including their email and invoicing habits?

A broken workflow is worth building a product for when its frustration is persistent, its cost is visible, and its pattern repeats beyond one team. A careful workflow audit reveals where work actually gets stuck. Problem validation shows whether that friction matters to a real market. Between the two, you can distinguish a clever feature idea from a business that solves a problem people are already trying—and often paying—to fix.