My first major automation project was the moment I realized how critically important it is to define the project scope correctly from the very beginning.
The client wanted “an automation for classifying tickets.”
I thought: “Easy job, I’ll finish it in a week or two.”
But after two days of work, I realized that:
- There was no properly built database to train an LLM model that could classify tickets in Zendesk.
- The client hadn’t provided any working rules or reasoning behind why certain actions were done in a particular way.
- Then it turned out the client wanted this automation to classify all types of tickets, not just one.
- In the following meetings, it became clear they also wanted additional actions to be performed once a ticket was classified, and so on. You get the idea.
The project became five times larger than the initial assignment.
Not because the client was lying — but because neither I asked the right questions, nor did he know what was important to share.
And, to be honest, that’s not his job.
For that mistake, I paid with months of unpaid work.
I repeat — months of unpaid work.
You might ask why I continued…
Because worse than working for free is breaking your word and not delivering what you agreed to.
That experience ultimately led to the creation of the HARDEN Method™ — a methodology that not only describes the steps for building a solution but also guarantees predictability and stability throughout the entire process.
Because in automation — just like in any software project — the devil is in the details.
And if you miss it during the Discovery phase, he’ll bite you during Delivery!
🔍 Where It All Begins
When a client tells you what they want to automate, the natural reaction of every excited creator is to jump straight into solutions:
- “I can do it in n8n!”
- “We’ll add a webhook here!”
- “We’ll send the data to Supabase!”
Sound familiar?
That impulse is good — it shows enthusiasm, expertise, and a genuine desire to help.
But there’s a problem.
Imagine going to a doctor who, without even examining you, immediately starts prescribing treatment.
- He hasn’t asked what exactly hurts.
- He hasn’t asked how long it’s been happening.
- He hasn’t checked for other symptoms.
- He doesn’t order any tests.
The result?
The treatment might be wrong. Or incomplete. Or unnecessarily expensive.
It’s the same with automation.
Before designing the solution, you need to understand reality.
Not what the client thinks is happening — but what is actually happening.
That’s where the two documents that save projects from surprises come into play — and they’ve become an integral part of how we work with clients today.
📄 PDD (Process Design Document) – The Map of Reality
Think of the PDD as an X-ray of the business process.
Before operating, you need to inspect the contents.
- Where are the problems?
- What’s working?
- What’s not?
The PDD is the document that provides insight into the client’s business operations.
It answers the questions that nobody wants to ask — but everyone must:
Who does what, and when?
Not “the team handles requests,” but “Maria receives an email at 9 AM, copies it manually into Excel, then sends it to Ivan for approval.”
What systems are used?
Not “CRM and spreadsheets,” but “Gmail, Google Sheets, an old Excel file on Maria’s desktop, and sometimes the WhatsApp group.”
Where is time lost, and what are the most common errors?
Not “sometimes there are delays,” but “30% of emails aren’t processed because they land in spam, and Maria only checks her inbox twice a day.”
What are the ROI levers — the points where automation would bring the most value?
Not “we’ll save time,” but “if we automate email data extraction, we’ll free 8 hours per week = 32 hours per month = half a person.”
This is Phase 1 – Discover in the HARDEN Method™ — the moment where we map reality, constraints, and opportunities.
Without a properly built PDD, every next step is like shooting in the dark.
⚙️ SDD (Solution Design Document) – The Architecture of the Future
If the PDD is the X-ray, the SDD is the surgical plan.
Once we understand the process, it’s time to design the solution — not randomly, but with a clear structure.
The SDD describes how the new system will work.
Not “we’ll make an automation,” but “here’s exactly what will happen, step by step, data by data, error by error.”
It answers questions like:
- How will the data be structured? What tables will we use? How will they be linked? What keys will each record have? Example: Each email becomes a row in a Supabase table “Requests” with 7 columns: ID, sender_email, subject, body, status, created_at, assigned_to.
- Who can do what? What roles and permissions exist? Example: Maria sees all requests, Ivan only the ones assigned to him. The automation can only change the request’s status, not its content.
- What happens in case of errors? Empty email? Duplicate? Supabase not responding? Example: If the email has no subject, it’s marked as “needs_review” and a notification is sent to Maria.
- How will success be measured? Not “it’ll work faster,” but concrete KPIs: Example: Processing time decreases from 15 minutes to 30 seconds, errors drop below 2%, 95% of emails are processed automatically without human intervention.
This is Phase 2 – Design in the HARDEN Method™.
Here, the PDD becomes a concrete technical framework for development.
Without an SDD, you have an idea.
With an SDD, you have a plan.
💡 PDD + SDD = A Stable Project
Many people think automation “just gets done” — you click a few buttons, connect some apps, and you’re done.
But let’s break that myth with a simple question:
Would you build a house without a plan?
Probably not.
You’d hire an architect to draw where the walls, doors, and systems will go.
Then an engineer would turn those drawings into concrete specifications — how many bricks, how thick the insulation, where the pipes go.
Automation works the same way.
Even when it appears to be “just connecting tools,” every automation is software.
It has logic.
It has data moving between systems.
It has potential errors and dependencies.
And just like a house — if you don’t start with a clear plan, you risk building something that looks ready from the outside but doesn’t work inside.
That’s why software companies spend dozens of hours planning before writing a single line of code.
Not to complicate things — but because experience has taught them that without a clear map of reality and a solid technical plan, projects fail.
In that world, two roles are key:
The Project Manager – dives into the business, asks questions, and maps what’s happening now. They create the PDD, the document that says “this is today’s reality.”
The Product Owner – takes that map and turns it into an action plan. They create the SDD, the document that says, “This is how tomorrow’s solution will look.”
The PDD is the foundation.
The SDD is the architecture.
Together, they ensure the project won’t collapse at the first change, won’t end up twice as expensive, and won’t leave the client disappointed.
So yes — I may sound like a broken record (for a reason) — but this exact approach is what we must bring into the world of automation.
Because if we want our projects to be stable, measurable, and profitable, we must stop pretending automation is something different from software.
It is software — and it deserves the same level of professionalism.
🧩 When the Scope Is Wrong
In my practice, I’ve seen two main scenarios when the project scope wasn’t properly defined:
- The project evolves and becomes much larger than the initial assignment because new dependencies appear along the way.
- The project underwent significant changes because the initial understanding of the process was either shallow or inaccurate.
In both cases, the result is the same — costs go up, and trust goes down.
My first lesson on how expensive a scope mistake can be came from the very project that started this story — the Zendesk ticket classifier.
Looking back, it’s obvious: the scope creep started at the very first meeting.
Not because the client was unclear, but because I wasn’t prepared to ask the right questions.
I didn’t realize that behind the phrase “we want an automation that classifies tickets” was an entire forest of scenarios, dependencies, subtypes, and “if… then…” rules.
First, it was one ticket type. Then seven.
Then each of those seven had between six and eight subtypes, each requiring a different action.
Ultimately, I had to manually classify tens of thousands of tickets to train the model and identify patterns.
The biggest paradox?
No one had lied.
No one (including me) knew how much we didn’t know.
In the end, the automation was rebuilt three times from scratch.
The budget — unchanged.
The timeline — tripled.
The reason?
No framework, no process, no PDD or SDD.
📉 What Really Went Wrong
- There was no Discovery framework. I had no checklist and relied only on “conversation.”
- Communication was wrong. I was speaking with an employee who was showing tasks, not a decision-maker.
- Hidden dependencies. Zendesk had internal scripts and business rules that were undocumented.
- No change management. Each “small addition” grew into massive scope creep.
The result?
Months of unpaid work — rebuilding the same thing again and again simply because the foundations were missing.
🧠 How to Avoid This
After that project, I introduced one iron rule:
Never start an automation without PDD and SDD.
This isn’t bureaucracy — it’s a bulletproof vest for every project.
Even if the client comes with a ready idea, we always start fresh.
Because between “I want automation” and “I know exactly how my business process works today,” there’s a massive gap.
And our job is to close it.
🚩 Warning Signs of Incomplete Discovery
- The client talks about the result (“send an email”) but not the process (“who sends it, when, and why”).
- It’s unclear who makes decisions in the process.
- API access and limitations haven’t been tested.
- There’s no person who understands why the business works a certain way, only how.
- The client says, “This is easy,” without evidence.
🎯 Killer Questions That Always Reveal Hidden Risks
- “Describe step by step what happens from the moment a request arrives until it’s completed.”
- “What happens if something goes wrong?”
- “Who makes the decision in this step — a person or a system?”
- “Are there exceptions to this rule?”
- “How often do these rules change?”
- “What does success look like? How will we know the automation works?”
These questions rarely yield perfect answers — but they always reveal where the risks lie and where deeper analysis is required.
⚙️ What Changed at Marinext AI
After that project, we introduced an internal Discovery Checklist that every automation must go through.
PDD and SDD became mandatory.
Without them, we don’t start the Build phase.
They don’t just define the technical requirements — they represent the psychological comfort of both sides.
No one guesses. Everything is transparent, signed, and traceable.
🎯 Success Formula: The HARDEN Method™
PDD and SDD stand at the core of the first two phases of the HARDEN Method™ — Discover and Design.
They’re not just documents.
They’re mechanisms for control, predictability, and trust.
| PHASE | GOAL | DOCUMENT |
| Step 1: Discover | Reveal reality, processes, constraints, ROI points | PDD |
| Step 2: Design | Define the new solution — logic, data, roles, fallback scenarios | SDD |
The HARDEN Method™ was born out of real pain — months of lost work and nights rebuilding the same thing for the third time.
Today, it’s not just a process — it’s a guarantee of predictability.
You may not have a perfect project.
But you’ll have one that doesn’t fall apart.
