I Help Technical Teams Find the Better Route Through Stuck R&D Problems
Robust Solutions Pro is built around a simple idea: before a team commits months, people, equipment, or capital to a technical path, it should be clear that the path is aimed at the right problem.
About Dr. Alec Zhou
I am a technical R&D leader and problem-framing consultant with experience in product development, formulation, process improvement, scale-up, simulation, and regulated technical environments.
My work focuses on helping teams see the problem differently before they invest heavily in the first plausible route.
In many R&D and technical operations settings, the team already has intelligence, commitment, data, and a defensible plan. The missing piece is often not effort. It is the frame.
A team may be investigating a cause that will not change the decision. A trial may validate a proxy rather than the final requirement. A product route may look blocked only because the product has been defined too narrowly. A process-improvement project may be stuck because the team is testing slowly from the wrong part of the map.
I help teams step back, open up the problem space, and identify the route most likely to produce a useful technical decision.
Why I Focus on Problem Framing
Technical teams are often trained to solve the problem in front of them. But in complex R&D, product, process, and scale-up work, the problem in front of the team is not always the problem worth solving first.
Good teams can choose narrow routes
Once a plan looks technically reasonable, alternatives outside that frame can become hard to see.
Evidence can answer the wrong question
A test can be well designed and still fail to change the decision the business actually needs to make.
Better levers are often hidden
The useful move may be a different starting condition, direct performance test, simpler control point, or changed product definition.
The Work Begins Before the Solution
I do not start by asking how to execute the current plan faster. I start by asking whether the current plan is the route worth taking.
Experience Behind the Work
My background combines hands-on technical development, R&D leadership, product and process problem solving, and decision-focused technical analysis.
Product and formulation development
Experience with formulated products, active distribution, sensory constraints, supplier variation, product formats, and regulated development questions.
Process improvement and scale-up
Experience with drying, mixing, process control, pilot decisions, physical trials, and practical routes from development to production.
Simulation and modeling
Use of modeling and simulation to reduce slow trial-and-error, narrow the design space, and identify what should be tested physically.
R&D documentation and evidence
Support for organizing technical reasoning, investigation paths, evidence, learning, and decision logic in a clear and defensible way.
How I Think About Technical Problems
The public description is simple. The private work is more detailed. I help teams look for the part of the problem that changes the route.
Where is the team standing?
The available options depend on where the problem has been framed. A narrow starting point can hide better paths.
What would change the decision?
The next test, trial, analysis, or purchase should produce evidence that changes what the team can do.
What lever is being missed?
A better route may come from changing a dependency, testing performance directly, moving a boundary, or redefining the product path.
Selected Problem-Framing Patterns
These are the types of shifts I look for in technical work. They are drawn from anonymized experience and simplified for public discussion.
From cause to action
When root cause may be historical, external, or difficult to reverse, the better route may be changing the product’s dependence on that cause.
From proxy to requirement
When a trial validates an intermediate variable, the key question is whether that variable actually controls the final requirement.
From blocked route to new definition
When a product route looks blocked by capital, regulation, or market constraints, redefining the product function can open a lower-cost path.
From slow trials to guided learning
When experiments are too slow for broad trial-and-error, modeling or structured analysis can help identify what matters before physical testing.
How I Work With Teams
The goal is not to criticize the existing plan. Most existing plans are reasonable from where the team is standing. The goal is to widen the view before the next commitment is made.
Respect the work already done
Existing tests, experience, hypotheses, and team judgment matter. They are the starting point, not something to dismiss.
Make assumptions visible
Many technical routes depend on assumptions that have become so familiar they are no longer questioned.
Move toward useful action
The output should help the team decide what to test, what to stop, what to change, or what to investigate next.
What I Do Not Put on the Public Website
The website explains the value of problem framing and shows simplified examples. It does not publish the detailed internal method, client-specific analysis, formulas, process details, or confidential technical strategy.
Public enough to understand the value
The examples show how reframing changes the technical route before more time, money, or capital is committed.
Private enough to protect the work
Detailed problem analysis, client information, technical data, and internal reasoning remain confidential.
Professional Boundaries
Some technical problems connect to tax, regulatory, legal, or intellectual-property questions. I keep those boundaries clear.
SR&ED: I support the technical side of R&D work, including problem framing, investigation logic, evidence, learning, and technical documentation. I do not provide tax, accounting, legal, eligibility, filing, refund, or CRA opinions.
Intellectual property: I can help explore technical alternatives and constrained routes. I do not provide patentability, infringement, freedom-to-operate, or legal opinions. Those require qualified IP counsel.
Have a Technical Problem That May Need a Better Route?
Send a short, non-confidential summary of the problem, the current path, and the decision your team is trying to make.
Start the Conversation