Find product ideas inside repeated manual decisions

Start with the decision someone is tired of reconstructing by hand.

That has become one of the filters I use when deciding whether a problem is worth building around. I am less interested in whether a task can be digitised than whether a person keeps having to rebuild the same judgment from scattered records, unwritten rules, and memory.

The distinction matters because many tools record activity without helping with the next decision.

A spreadsheet stores the number, a CRM stores the status, a project board stores the task, and a chat thread stores the conversation. None of those records necessarily tell the person what should happen next, why the current state matters, or which rule applies when the normal path changes.

The product opportunity often appears in that gap.

Protocol started with a decision, not a fitness dashboard

Protocol began because I was tired of turning my workouts into an office job.

I had a structured routine with real progression rules: increase the weight when a target was met, hold it when the result was incomplete, regress after repeated failures, alternate sessions in the right order, and remember what happened the last time I performed the exercise.

Excel could store the history, but it could not run the programme.

Between sets, I still had to check the previous session, remember the rule, interpret the result, decide which load came next, and make sure the following workout stayed in sequence. Logging the data was only the first half of the job. The repetitive decision remained mine.

That frustration became Protocol.

The product puts the thinking into the routine once, then uses the logged training state to apply the rules while the athlete trains. The user still owns the plan and can change it. Protocol removes the repeated administrative interpretation that was getting between the plan and the workout.

The slogan came from that exact job: train hard, think less.

I did not start by asking how to build a better workout tracker. I started with the decision I was tired of making again and again.

Gestalt began with a different reconstruction problem

Gestalt came from service design and workflow mapping rather than training, but the frustration had the same shape.

I could map a process with a team, enter one subprocess to inspect the detail, and then lose the wider route we were trying to understand. A flat diagram could record the boxes and arrows. It became much less useful once the work had nested paths, exceptions, approvals, and dependencies that changed what the wider workflow meant.

The team could still make sense of it while everyone was in the room. Someone remembered why the handoff worked differently for one customer, which approval sat outside the documented route, or how a local workaround connected back to the parent process.

Once the room emptied, the map stopped carrying enough of the decision.

That became Gestalt: a visual system-mapping tool that lets someone inspect a nested part of the workflow without losing the relationship back to the whole. The same map can then support different operating artifacts instead of becoming a static workshop record.

Protocol and Gestalt solve different problems. One runs training rules for an athlete, while the other keeps depth and context connected inside a workflow map. Both started where a recording tool left a person repeatedly reconstructing what should happen next.

That pattern is more useful to me than starting with a list of features.

Manual work is not automatically a product opportunity

Repeated effort can be irritating without deserving software.

Some decisions happen too rarely to justify a permanent tool, some depend on judgment that should remain deliberately human, and others only feel difficult because the underlying workflow has never been named. The remainder may be fixed by changing one rule, removing one approval, or making an existing system easier to use.

Building software too early can make the problem harder to see.

The team begins discussing screens, integrations, permissions, dashboards, and automation before it has established whether the repeated decision is stable enough to encode. The product then formalises a workaround that should have been removed, or turns one experienced person’s habits into policy without testing whether those habits should govern anyone else.

This is why I do not treat every manual step as inefficiency.

The useful question is whether the person is applying repeatable structure to a recurring decision, and whether moving part of that structure into a product would improve the result without taking away the judgment that still matters.

Five tests for a decision worth building around

I use five tests before I become interested in the software.

1. The decision returns often enough to learn from

Frequency matters because a product needs repeated use to reveal whether its model is right.

A decision made once a year may still be important, but it will produce a slow and weak learning loop. A weekly or daily decision gives the builder repeated evidence: where the rule holds, where users override it, which inputs are missing, and whether the output actually reduces work.

The recurrence does not have to be high-volume consumer behaviour. A smaller number of consequential B2B decisions can be enough when the pain, process, and outcome are visible.

2. The inputs can be named

A useful product needs to know what the person is looking at before deciding.

For Protocol, that includes the routine rules and training history. For a service exception, it might include the original commitment, current status, evidence, approval rights, and available next routes. For a product prioritisation decision, it might include customer evidence, delivery constraints, commercial commitments, and the tradeoff already accepted.

If nobody can name the inputs, the product is likely to hide the uncertainty rather than resolve it.

This does not mean every input has to be structured perfectly on day one. It means the team can explain which facts shape the decision and distinguish them from the surrounding noise.

3. Some part of the judgment can become an inspectable rule

The product does not need to automate the entire decision.

It may only need to surface the relevant state, apply a known threshold, preserve the sequence, identify a missing input, or present the available choices before a person decides. That bounded support can remove substantial work while leaving exceptions and final judgment with the user.

This is usually more useful than promising that AI or automation will replace the decision-maker.

The system should be able to show why it recommended the next action, which rule it used, and where the user can challenge it. A product that only returns an answer may save time, but it also creates a new reconstruction problem when the answer is questioned.

4. The consequence of a wrong decision is visible

The best opportunities are not only frequent; they matter.

An incorrect training progression can create a poor session or increase injury risk. A missed customer exception can break a promise, delay delivery, or produce an unnecessary refund. A product decision made without the right evidence can create rework across design, engineering, sales, and support.

Visible consequences make the product easier to evaluate.

The team can ask whether the recommendation reduced delay, prevented a repeated error, improved the quality of the next action, or made the decision easier to defend. Without that consequence, the product may create activity without proving that anything improved.

5. The user can stay in control

A product becomes dangerous when it removes the friction that was protecting a consequential decision.

Some steps are slow because the workflow is poorly designed. Others are slow because somebody needs to inspect evidence, exercise judgment, or take responsibility. Good software should know the difference.

That means giving the user a visible rule, an override, a record of what changed, and a route for handling the case that does not fit. The product can carry repetitive interpretation without pretending the person no longer matters.

I care about this in both products. Protocol runs the athlete’s own plan rather than replacing it with an unexplained coaching decision. Gestalt helps a team inspect and challenge the workflow rather than presenting the map as unquestionable truth.

The user should gain agency as the system becomes more capable.

Look for the unwritten route inside the business

This is the question I have started carrying into conversations with founders and operators in Dubai and across the UAE: what part of the business still works because one person knows the route nobody has written down?

If that person disappeared for a week, which decision would slow down first?

It might be an approval that always returns to the founder, an exception the operations lead resolves from experience, a customer promise that support has to interpret, or a product judgment scattered across sales calls, delivery constraints, and old roadmap decisions.

The opportunity is not the existence of manual work. It is the repeated dependence on one person to reconstruct the state, apply the same judgment, and explain the outcome to everyone else.

That dependence can point to several different interventions.

The answer might be to document the route, remove a step, or run a focused diagnosis of the product surface and the operating decisions behind it. It might call for a small internal utility rather than a company, or reveal a durable product opportunity that deserves its own model, interface, ownership, and learning loop.

The diagnosis comes before the build.

That is also where this argument meets the Ocarina thesis about summonable software. Some needs deserve a permanent product. Others need a disposable tool generated for one bounded job. Repetition is part of how the tool earns permanence, but repetition alone is not enough; the decision, consequence, and user control still have to justify what is being built.

Build the smallest decision loop that can prove the idea

Once the pattern is visible, the first version should be smaller than the imagined product.

Choose one recurring decision, name the inputs, and encode only the rule that is already understood. Keep the person who currently owns the judgment inside the loop, record the result and the override, then watch whether the work becomes easier without making the decision more fragile.

That first loop can reveal that the product is worth expanding. It can also reveal that the real issue was elsewhere: unreliable data, conflicting ownership, an unstable policy, or a workflow the organisation was not prepared to standardise.

Either result is useful.

This is why I often begin product work with a focused diagnosis of the experience and the decision behind it rather than a predetermined build. The client should be able to leave with a better route even when the answer is to fix the workflow internally, use an existing tool, or decide the problem does not deserve software yet.

Products should earn their next phase in the same way consulting engagements should.

The most interesting product opportunities are often already running. They are running manually, unevenly, and inside the head of the person everyone calls when the normal route stops working.

Find that decision before you design the dashboard.