6 Problems to solve for Mgmnt+RPSL (For signing now and "not" see you later)
Perfect. This is the right way to do it.
We’ll go one by one, no overload, no theory dump.
How we’ll do this (simple rules)
I will give ONE problem you’re not addressing
I’ll explain why it matters in shipping
I’ll show what a good solution looks like
You reflect / adjust
You say “next”
We move on
No skipping. No rushing.
STEP 1 — ❌ Missing Problem: “Who actually signs the cheque?”
The problem
Right now, your thinking is:
“RPSL, ship managers, owners — all potential users”
But users ≠ buyers in shipping.
If you don’t design for the signatory, you’ll get:
Long conversations
Positive feedback
Zero contracts
Why this matters (shipping reality)
In shipping:
People who feel the pain
≠People who approve spending
Example:
Superintendent feels pain
Fleet Manager feels pressure
Technical Director / Head of Ship Management signs
If your product doesn’t:
Make them look good
Reduce their risk
👉 It won’t be bought.
The solution (what you must decide)
You must choose ONE primary cheque-writer for the first 12 months.
Typically, it will be one of these:
1️⃣ Head of Technical / Ship Management
2️⃣ Managing Director of Ship Management company
3️⃣ Head of Crewing (for RPSL-first strategy)
Not all three. One.
What a correct solution looks like
You can finish this step when you can say:
“Our first buyer is ___
They sign because this reduces ___ risk
And it shows up in ___ KPI”
Example (don’t copy yet):
“Our first buyer is Head of Technical.
This reduces repeat breakdowns and superintendent overload.
KPI: off-hire days & incident repetition.”
Your task (do this before saying “next”)
Answer this in one paragraph:
Who do you want to sign the first 10 cheques, and why?
No perfection needed. Just clarity.
When you’re ready, reply with “next”
and we’ll move to STEP 2 — the urgency trigger.
Good. Let’s continue.
STEP 2 — ❌ Missing Problem: “Why would they buy this THIS quarter?”
This is the difference between:
“Interesting, let’s revisit later”
and“Send the proposal”
The problem
Right now, your product sounds like:
“A better way to learn / troubleshoot / share knowledge”
That is always postponed in shipping.
Shipping buys only when:
Something broke
Someone got shouted at
Someone is afraid it will happen again
If there is no clock, there is no deal.
Why this matters (shipping reality)
Shipping companies operate on:
Annual budgets
Incident-driven spending
Audit cycles
They don’t ask:
“Is this good software?”
They ask:
“What problem is this solving right now?”
Typical urgency triggers in shipping (examples)
One of these must be true for a deal to move:
Recent breakdown / blackout
PSC inspection coming
New vessels added
High crew turnover
Using multiple RPSLs
Superintendent overloaded
Charterer complaint
New engine type introduced
Post-incident internal audit
No trigger → no budget movement.
The solution (what you must design for)
Your product must attach itself to an event, not a role.
You should be able to say:
“This is what you use when X happens.”
What a correct solution looks like
Pick ONE primary trigger and align everything to it.
Example formats:
“After a breakdown, this prevents repeat mistakes.”
“When external crew joins, this reduces familiarization risk.”
“Before PSC, this consolidates known problem areas.”
Your landing page, demo, pitch — all align to that trigger.
Your task (before we go next)
Answer this clearly:
What event makes your buyer uncomfortable enough to act?
Don’t list 10.
Pick one.
Reply “next” when you’re ready.
Alright. Moving on.
STEP 3 — ❌ Missing Problem: “What are you replacing?”
This one is dangerous if ignored.
The problem
Right now, you’re implicitly positioning your product as:
“Something new and useful”
But shipping does not adopt additions easily.
It adopts replacements.
If your product does not kill an existing habit, it will:
Be praised
Be piloted
Slowly die
Why this matters (shipping reality)
In shipping, people already solve problems using:
WhatsApp groups
Personal contacts
Calling ex-crew
Old emails
PMS remarks
Superintendent phone calls
Vendor hotlines
These systems are:
Messy
Inefficient
Risky
But they are trusted.
If you don’t explicitly say:
“We replace THIS chaos”
You become:
“One more tool”
And “one more tool” = ignored after demo.
The uncomfortable truth
Your real competitors are NOT:
Other startups
AI tools
Marine software companies
Your real competitors are:
WhatsApp
Memory
Hero engineers
Late-night phone calls
The solution (what you must define)
You must declare a villain.
Example villains:
“Knowledge locked inside WhatsApp”
“Same mistakes repeated on sister vessels”
“Superintendent becoming Google”
You don’t replace everything.
You replace one ugly behavior.
What a correct solution looks like
You should be able to say:
“Instead of X, companies use us.”
Examples (structure only):
Instead of calling ex-crew → use us
Instead of scattered WhatsApp fixes → use us
Instead of blind troubleshooting → use us
Clear. Specific. Slightly confrontational.
Your task (important)
Answer this honestly:
If your product disappeared tomorrow, what would users go back to?
That answer is what you are replacing.
When ready, say “next”
We’ll go to STEP 4 — trust & proof (especially AI skepticism).
Good. This is the hard one — and the most important for AI.
STEP 4 — ❌ Missing Problem: “Why should they TRUST this?”
You are building in an industry where:
Wrong advice = incident
Incident = audit
Audit = career damage
So trust is not emotional.
It is career-protective.
The problem
Right now, your implicit promise is:
“Our AI is trained for marine industry”
To a ship manager, that sounds like:
“If this goes wrong, I will be blamed — not you.”
That alone can kill adoption.
Why this matters (shipping reality)
In shipping:
Nobody wants to be the first to trust something
Nobody wants to explain AI to an auditor
Nobody wants a black-box answer
They ask silently:
Can I defend this decision?
Can I trace this advice?
Can I say who this came from?
The hidden rule of trust in shipping
Shipping trusts traceability, not intelligence.
They don’t ask:
“Is this smart?”
They ask:
“Can I show this to my boss / auditor?”
The solution (how trust is actually built)
Your AI must never feel alone.
It must always be backed by something human or historical.
Trust anchors you must design (at least 2):
“Based on 5 similar incidents”
“Used on same engine type”
“Validated by senior rank”
“Derived from fleet history”
“Last occurrence: 6 months ago”
Even if imperfect at first, visibility beats perfection.
What a correct solution looks like
A ship manager should be able to say:
“We didn’t guess.
We followed a pattern already seen on other vessels.”
That sentence is trust.
VERY IMPORTANT: what NOT to do
Avoid language like:
“AI decided”
“Model suggests”
“Algorithm says”
Use:
“Fleet data shows”
“Previous cases indicate”
“Common resolution was”
Language alone can make or break adoption.
Your task (this one is critical)
Answer this:
If an auditor asks “why did you do this?”,
what proof does your platform provide?
If you can answer that, you’re safe.
When ready, say “next”
We’ll move to STEP 5 — data risk & political landmines.
Good. Now we’re entering founder-level landmines.
Most startups die here silently.
STEP 5 — ❌ Missing Problem: “Whose data is this, and who gets blamed?”
This is not a technical issue.
This is politics + liability.
The problem
You are creating a system where:
Crew post problems
Incidents are discussed
Fixes are recorded
Patterns become visible
To you, this is knowledge.
To companies, this is evidence.
Evidence can:
Help learning
Or destroy careers
If you don’t control this narrative, managers will block you.
Why this matters (shipping reality)
Ask yourself:
What if a PSC detention references an issue discussed in your app?
What if crew uploads a photo of a non-compliance?
What if unions ask for access?
What if an owner demands logs?
People fear digital paper trails.
That fear is rational.
The unspoken question they will never ask you directly
“Can this tool be used against us?”
If the answer is unclear → no rollout.
The solution (how serious platforms survive)
You must pre-decide governance, even if you don’t build all of it yet.
You need clear positions on:
1️⃣ Visibility
What is public?
What is vessel-only?
What is private?
2️⃣ Ownership
Who owns content?
Crew? Manager? Company?
3️⃣ Retention
How long is data kept?
Can it be deleted?
Who can export it?
4️⃣ Language framing
“Learning record” vs “incident log”
“Discussion” vs “report”
Words matter legally.
What a correct solution looks like
A manager should feel:
“This helps us learn
without increasing our legal exposure.”
That’s the balance.
Strategic advice (important)
Early on:
Keep it as learning + troubleshooting
Avoid “incident reporting” language
Avoid compliance labels
Later:
You can formalize, with contracts
Your task (this is serious)
Answer honestly:
What happens if a company asks you to delete all their data tomorrow?
Your answer determines:
Enterprise readiness
Trust level
Long-term deals
When ready, say “next”
We’ll go to STEP 6 — the existential positioning question.
This one decides what company you’re actually building.
Alright. This is the last and most important step.
Everything before this feeds into this.
STEP 6 — ❌ Missing Problem: “What company are you ACTUALLY building?”
This is the question that decides:
Your pricing
Your buyer
Your roadmap
Your competitors
Whether this becomes big or stays niche
Most founders never answer this consciously.
They drift. Shipping will kill drift.
The problem
Right now, your product looks like many things at once:
A community
An AI chatbot
A learning platform
A troubleshooting tool
A crew support system
That’s fine internally.
But externally, buyers need one mental box.
If they can’t categorize you in 10 seconds, they won’t fund, buy, or champion you.
The dangerous mistake
Founders often say:
“We are a platform”
That is a red flag in shipping.
Shipping wants to hear:
“We reduce this specific risk.”
The 4 possible identities you could become
You must choose one to lead with (others can exist underneath).
Option 1️⃣ Crew Readiness Infrastructure
You are:
Pre-boarding
Familiarization
Confidence layer
Buyer:
RPSL
Ship managers with high crew churn
Value:
Fewer joining mistakes
Risk:
Lower ticket size
HR budgets
Option 2️⃣ Knowledge Continuity Layer (very strong)
You are:
Memory of the fleet
Preventer of repeat mistakes
Bridge between crew changes
Buyer:
Ship managers
Technical heads
Value:
Less repeat failure
Less superintendent overload
This aligns very well with what you’ve described.
Option 3️⃣ Operational Risk Intelligence Platform
You are:
Pattern detector
Early warning system
Management dashboard
Buyer:
Owners
Senior management
Value:
Risk visibility
Decision support
This is powerful but later stage.
Option 4️⃣ Training & Upskilling System
You are:
Real-world learning
Incident-based education
Buyer:
Institutes
Juniors
Good for adoption, not for core revenue.
The solution (what you must lock in)
You must finish this sentence:
“We are the _____ for shipping companies.”
Not five words.
Not a paragraph.
One clear identity.
Example structure (don’t copy blindly):
“We are the knowledge continuity layer for ship managers.”
Once this is fixed:
Your pitch writes itself
Your homepage becomes obvious
Your sales conversations simplify
The final task (this is the capstone)
Answer this without hedging:
If someone introduces your company in one sentence, what do they say?
That answer is your company.
Very important reassurance
You are not locking your future forever.
You are locking:
Your first 24 months
Your first revenue
Your first credibility
You can expand later. Shipping respects focus.
When you’re done
Reply with your one-sentence answer.
Then I’ll:
Stress-test it
Tighten the language
Show you how each buyer hears it
This is where it all comes together.
Comments
Post a Comment