PTENES
MODULE 1.2

🔧 The work that doesn't change: find the real constraint and prescribe a solution

The title changed. The work didn’t. Consulting is diagnosis + prescription — and anyone who confuses a symptom with the real constraint delivers a solution to the wrong problem.

6
Topics
~40
Minutes
Base
Level
Method
Type

AI has changed the consultant’s toolbox, but it hasn’t changed the work itself: come in, diagnose the real constraint, and prescribe the simplest solution that works. Anyone who skips diagnosis and goes straight to their favorite tool delivers the right answer to the wrong question.

Input client, operations Diagnosis real constraint (not the symptom) Prescription simplest solution AI or no AI Result improved business AI = a tool, not a destination

Illustrative diagram — the consultant’s workflow hasn’t changed with AI.

1

🩺 Consulting = diagnosis + prescription

The most useful model for thinking about a consultant’s work is the doctor: nobody hires a doctor to bring them a list of medications — they hire one to find out what’s wrong and recommend the right treatment. The tool (the medication) comes after the diagnosis.

⚕️ The two halves of the work

  • •Diagnosis — understand the operation, identify the real constraint, and separate symptoms from causes.
  • •Prescription — recommend the simplest solution suited to the identified problem. That may or may not be AI.

Consultants who skip diagnosis and go straight to prescribing (usually the tool they know best) deliver the right solution to the wrong problem.

Listen

understand before proposing

Identify

the constraint, not the symptom

Prescribe

with the right tool

Validate

result vs. problem

2

🔍 Real constraint vs. symptom

What the client asks for is rarely the problem. It’s the visible symptom of a deeper constraint. Treating the symptom delivers short-term results — and keeps the problem alive to come back and demand attention later.

✓ What the consultant is looking for

  • ✓Asks "why is this happening?" before proposing a solution
  • ✓Maps the process to find where the flow gets stuck
  • ✓Distinguishes what the client wants from what the client needs
  • ✓Validates the constraint hypothesis with data before taking action

✗ Common pitfalls

  • ✗Accepting the client’s request as the problem definition
  • ✗Proposing a solution in the first meeting, before understanding the operation
  • ✗Solving the most visible symptom, which isn’t the bottleneck
  • ✗Confusing client urgency with problem importance

💡 Golden question

Before any proposal, ask: "If we solve this, will the problem the client brought us actually go away?" If the answer is "probably not," you still haven’t found the constraint.

3

🧩 Theory of Constraints applied to operations

Goldratt’s Theory of Constraints (ToC) says what every consultant needs to internalize: every operation has exactly one dominant constraint at any time. Improving anything other than the bottleneck doesn’t improve the system’s results.

1

Identify the constraint

Step 1 of 5

Where does the system stop? Which step builds up a queue, makes the next step wait, or has less capacity than demand?

2

Explore before investing

Step 2 of 5

Get the most out of the existing constraint without spending more. Eliminating waste at the bottleneck often solves the problem without any new system.

3

Make everything subordinate to the bottleneck

Step 3 of 5

All other steps serve the bottleneck—not the other way around. Automating what isn’t the bottleneck creates waiting inventory, not results.

4

Raise the constraint

Step 4 — only if necessary

Now's the time: invest to increase the bottleneck's capacity. This is where AI, automation, or hiring comes in—after you understand the constraint, not before.

📊 Why this matters for the AI consultant

Most AI proposals offer solutions for non-bottlenecks. Automating the wrong step doesn’t increase the system’s throughput—it just creates digital inventory in a queue no one reads. Identifying the real bottleneck is what separates the consultant from the tool salesperson.

4

💬 Trust Is the Asset: You’re Hired for Your Judgment

No client hires a consultant to perform tasks they already know how to do. They hire one for judgment: the ability to look at the operation and confidently say where the problem is and what the right solution is — even when the answer is inconvenient.

🤝 What builds trust

  • •Ask uncomfortable questions — someone who never challenges the client is selling validation, not consulting.
  • •Deliver honest assessments — even when the diagnosis doesn’t support the AI proposal.
  • •Recommend what’s right, not what’s bigger — a smaller project done well is worth more than a large project delivered poorly.
  • •Admit what you don't know — clients recognize intellectual humility and value it.

💡 Practical tip

A consultant who delivers a diagnosis saying "this problem doesn’t need AI" rarely loses the client — almost always, they earn the client’s loyalty. The client sees they’re getting real judgment, not a tool pitch. And they’ll call you again when the next problem comes up.

5

🛑 The hammer temptation: when the title distorts the diagnosis

Maslow said: if all you have is a hammer, every problem looks like a nail. The AI consultant risks seeing AI for every problem — not because AI is the right answer, but because it’s the tool they identify with. That’s the most dangerous bias of the label.

✓ Neutral diagnosis

  • ✓Starts with the question: "What's the problem?"
  • ✓Assesses all possible solutions before choosing
  • ✓Chooses AI when it’s genuinely the best option
  • ✓Justifies the choice with objective criteria

✗ Hammer bias

  • ✗Starts with the question: "Where can I use AI here?"
  • ✗Forces an AI narrative onto every situation
  • ✗Ignores simpler, cheaper solutions
  • ✗Sells complexity when simplicity would suffice

⚠️ Attention

Hammer bias isn’t malicious—it’s a natural cognitive distortion in people who specialize in a tool. The antidote is to always start the diagnosis by asking "what is the problem?"—not "how can I apply AI here?".

6

🗣️ Translate technology into business results

The client doesn’t buy a language model, embedding, or RAG pipeline. They buy time saved, errors avoided, revenue generated, or risk reduced. A consultant who talks technology with the client is speaking the wrong language.

🔄 The two-way translator

Technical → Business

  • ✗ "RAG with semantic embeddings"
  • ✓ "Correct automatic answers instead of having to search the manual"

Business → Technical

  • ✗ "I want AI in my customer service"
  • ✓ "Want to reduce response time for repeated questions by 60%?"

💡 The boardroom test

Before presenting any solution, run it through this filter: "If I remove all the technical words from this sentence, what's left?" What remains should be the business outcome the decision-maker cares about — and that’s what goes in the proposal.

📊 Metrics the client understands

  • Time: hours/week recovered per person
  • Cost: operational cost reduction in R$/month
  • Error: % of rework or failures eliminated
  • Revenue: increased conversion or average order value
  • Risk: compliance incidents or fines avoided

🎒 Module summary

✓
Diagnosis before prescription — the medical model: understand the problem before recommending a tool.
✓
The client asks for the symptom — the consultant finds the real constraint behind the request.
✓
ToC as a lens — every operation has a bottleneck; optimizing what isn't the bottleneck doesn't change the outcome.
✓
Judgment is the product — trust is built by being honest, even when the answer isn’t AI.
✓
Speak the client's language — business outcome, not technical architecture.

Next module:

1.3 — The solutions pyramid: deterministic → AI → agents