Open Up the Problem Before You Lock In the Technical Path
I help R&D, product, process, and scale-up teams step back from the first plausible route, see options they may not know are available, and choose the path most likely to change the decision.
What Problem Framing Does
Problem framing is not wordsmithing. It is the technical discipline of deciding where the team is standing in the problem, what paths are visible from that position, and whether the current route is the one worth committing to.
It opens the map
Capable teams can become trapped inside the first reasonable frame. Framing helps reveal questions, routes, and levers that are hidden by the current plan.
It tests the route
A plan can be technically defensible and still not change the decision. Framing asks whether the work will produce evidence the team can actually act on.
It finds better levers
The best next move may not be the deepest investigation. It may be a direct test, a simpler control point, a changed dependency, or a different product route.
When Problem Framing Matters Most
Problem framing is most useful before a team commits serious time, people, equipment, or capital to a technical path that already looks reasonable.
Before a long investigation
When the team is preparing to spend weeks or months finding a cause, but it is not yet clear what decision the answer will change.
Before an equipment purchase
When a trial looks successful, but the team needs to know whether the system acts on the final requirement or only on a proxy.
Before a scale-up or process change
When physical trials are slow, expensive, or inconclusive, and the team needs a clearer way to decide what should be tested first.
Before a product route is abandoned
When the original route has become too costly, too slow, or too capital-heavy, but a different definition of the product may still preserve the opportunity.
The Core Question
The question is not only “What caused the problem?” The better question is often: “What route will change the decision fastest, with the least unnecessary cost and disruption?”
The Questions I Help Teams Answer
These questions are simple to ask, but difficult to answer well when a team is already inside a technical route.
- Are we solving the right problem?
- Are we locked into the first plausible route?
- What paths are we not seeing?
- What would this investigation actually change?
- Is this trial validating the final requirement or only a proxy?
- Is the root cause findable, removable, and worth removing?
- Is there a simpler lever we should test first?
- What evidence would make the next decision clearer?
Problem Framing in Action
These anonymized examples show how better framing can change the technical route before more time, money, equipment, or disruption is committed.
From Troubleshooting History to a Controllable Process Lever
Situation: A product that had run well for years began failing a dimensional requirement.
Conventional route: Investigate what changed across equipment settings, room conditions, mixing times, operators, and past records.
Reframing: Instead of asking only what changed, I asked what the measured requirement was physically made of.
Better lever: The final dimension could be expressed as starting dimension plus change during processing. The starting condition had been treated as fixed, but it was actually a controllable process habit.
Outcome: The dependency was changed in one shift, without capital spending, formula change, or major disruption.
From Failed Raw-Material Lot to Decision-Changing Lot Testing
Situation: A formulated product failed two batches before pilot, and the issue was traced to a main raw material.
Conventional route: Buy specialized equipment, characterize the failed lot, and identify what made it different.
Reframing: I asked what decision would change if the root cause were found.
Better lever: The real decision was not whether the failed lot could be explained. It was which available lot would work in the formulation.
Outcome: The work shifted to direct formulation testing of available supplier lots, answering the business decision faster and at lower cost.
From Precision Equipment to Final-Product Control
Situation: A regulated formulated product needed more uniform active distribution.
Conventional route: Purchase a high-precision spraying system after a successful supplier trial.
Reframing: I reviewed what the trial had actually proven. It showed spray precision, not final product uniformity.
Better lever: The final requirement depended on distribution through the bulk product, not only precise application to a surface.
Outcome: The team avoided a costly equipment path and used a simpler mixing route with dosing controlled by weight loss.
From Regulatory Barrier to Design Boundary
Situation: A cannabis extract format allowed far higher THC per package than edibles, but sugars and sweeteners were not allowed.
Conventional route: Treat bitterness and regulation as a market barrier.
Reframing: Instead of asking how to use sweeteners, I asked what could perform the sensory function without being classified as sugar or a sweetener.
Better lever: The regulation became a design boundary rather than a dead end.
Outcome: A compliant route was found to address bitterness and improve product acceptance.
From Capital-Heavy Beverage to Lower-Capital Drink Format
Situation: A company wanted to develop a cannabis-infused drink using nano-emulsion technology.
Conventional route: Continue toward a ready-to-drink beverage path that required larger partners and higher capital.
Reframing: I reframed the definition of a drink. A drink did not have to be sold as a ready-to-drink liquid.
Better lever: A powder drink-mix format could preserve the consumer use case with much lower capital requirements.
Outcome: The team developed a drink-mix route within months, keeping the opportunity alive after the original path lost funding support.
From Month-Long Drying Trials to Simulation-Guided Improvement
Situation: A drying process had long cycle times and mold risk.
Conventional route: Physically test many drying-rack layouts, even though each trial took too long to support fast learning.
Reframing: I reframed the work from trial-and-error layout testing to simulation-guided decision making.
Better lever: Simulations narrowed the design space and identified the most important drying factor to validate physically.
Outcome: The improved route cut drying time by more than 50% and resolved the mold issue.
How a Problem-Framing Engagement Works
The first step is simple and non-confidential. Deeper technical review should happen only after the fit and confidentiality process are clear.
Start with a non-confidential summary
Describe the type of problem, the current path, and the decision the team is trying to make.
Clarify the current route
I review what the team is planning to investigate, test, purchase, change, or abandon.
Open up alternative frames
We look for hidden assumptions, missed levers, proxy variables, better definitions, and routes outside the current frame.
Identify decision-changing next steps
The output is a clearer technical route: what to test, what to avoid, what evidence matters, and what decision the work should support.
Go deeper if the fit is right
A deeper confidential review can follow when more detailed formulas, data, process conditions, drawings, or product information are needed.
What You Receive
The output is not just a discussion. The goal is to make the next technical move clearer, smaller, faster, or more directly tied to the decision.
A clearer problem frame
A sharper description of what problem the team is actually in and where the current frame may be too narrow.
Better route options
Alternative paths that may reduce time, cost, disruption, capital need, or unnecessary investigation.
Decision-focused next steps
A practical view of what evidence should be generated next and what decision that evidence should change.
A Note on Confidentiality
The examples above are anonymized and simplified. Client-specific data, formulas, process details, commercial decisions, internal reasoning, and technical strategy are not shared publicly.
Public examples show the pattern
The public material explains the type of problem-framing shift, not private client details.
Detailed work stays private
Deeper technical review can be handled under appropriate confidentiality arrangements when needed.
Have a Technical Problem That May Need a Better Route?
Send a short, non-confidential summary of the problem, the current plan, and the decision the team is trying to make.
Start the Conversation