Hutchison Ports · Horizon · Project challenges
Turn a project challenge into a defensible recommendation.
Discover, Define, Develop, Deliver. Each phase carries the prompts and frameworks that help your team widen the options, stress-test the problem, and commit to a 30-day experiment — with the evidence honest and the uncertainty visible.
Innovation process
From challenge to 30-day experiment, in four phases.
Nine prompts across Discover, Define, Develop and Deliver. The pre-mortem sits in Develop to pressure-test the options before your team advances one, and Deliver turns the strongest option into a 30-day experiment. Every prompt carries the framework definition it needs.
How to useReplace each [bracketed placeholder], then copy the prompt into your AI workspace. These prompts are written for an internal AI with no web access: every framework it needs is contained in the prompt itself, so nothing has to be looked up. Ask the AI to distinguish Evidence / Interpretation / Assumption / Unknown; an unknown needs a next learning move, not a confident sentence.
1
Discover
Understand the landscape before defining the problem. Look beyond the obvious solution, keep the people affected plural, and use external forces only when they could change a project decision.
Prompt 1.1
Power Questions
What do we actually need to find out before we decide anything?
Innovation Judgment lens: The most useful first output is a better question, not an idea. This separates what the team knows from what it is assuming, and turns the largest unknown into something a person can go and answer.
Copy prompt 1.1
Act as an inquiry facilitator helping a project team work out what it actually needs to find out about a challenge before it decides anything. Your job is to help the team generate, sharpen, and prioritise questions. You have no web or external access: work only from the material supplied in this prompt.
FRAMEWORK REFERENCE - POWER QUESTIONS
Question-storming rules. Hold to these while generating:
1. Ask as many questions as you can.
2. Do not stop to answer, judge, or discuss any of them.
3. Write every question down exactly as it is first stated.
4. Change any statement into a question.
Three dimensions of a powerful question:
- Construction. Yes/No and Which questions are the weakest. Who, When and Where sit in the middle. What, How and Why carry the most leverage, because they demand an explanation rather than a yes or a no. One caution: a blunt "why" question can trigger defensiveness ("why did you do that?") instead of inquiry. Prefer the version that opens thinking over the version that asks someone to justify themselves.
- Scope. Match the question to the team's real capacity to act. A question about the whole industry cannot be answered inside a 30-day experiment. A question about one terminal can.
- Assumptions. Almost every question carries a belief inside it. "How do we get people to use this?" already assumes they should. Surfacing the assumption is often worth more than the answer.
Four territories the question set should cover:
- Strategy: the big picture, rationally. Priorities, direction, what good looks like.
- Execution: the detail, rationally. How, who, when, with what.
- Dreams: the big picture, emotionally. What people hope for, what would energise them.
- Fears: the detail, emotionally. What worries people, what has frustrated them, what could go wrong.
Project: [Your Organisation]
Industry / sector: [sector or setting, e.g. port operations]
Problem space: [challenge in 2-3 sentences]
What happens today: [current workflow, pain, workaround]
Evidence available: [observations, data, interviews, sources, or "none yet"]
What we seem to be assuming: [current belief, default solution, or "not yet stated"]
Your task:
1. Restate the challenge as a Question Focus: one short, plain statement, not a question. It is the stimulus the team will ask questions about, so do not explain or interpret it.
2. Generate 25 to 40 questions about the challenge. Follow the four rules exactly: number every question, produce no fewer than 25, and do not answer, judge, rank or group them at this stage.
3. Mark every question C (closed-ended: answerable with yes, no or a single word) or O (open-ended: needs an explanation). Then show one improvement in each direction: rewrite one closed question as open, and rewrite one open question as closed. Give the before and after for both.
4. Take the eight weakest questions and rewrite them. Move Yes/No, Which, Who, When or Where constructions up the ladder to What, How or Why. Tighten any question whose scope exceeds what the team can actually act on. Remove, or make explicit, the assumption buried inside it. Show the before and after for each.
5. Sort the full set into the four territories: Strategy, Execution, Dreams, Fears. State which territory is thinnest, and what that gap would cost the team if it stayed empty.
6. Name the three beliefs the team appears to be carrying that most shape these questions. For each, give one reframed question that would only make sense under a different belief.
7. Choose the three priority questions for a 30-day experiment. For each, state why this one, what decision it would change, who could answer it, and what evidence would settle it. If a question cannot realistically be answered within 30 days, say so and replace it with one that can.
8. Name the one question the team appears to be avoiding, and what it would cost to keep avoiding it.
9. Close with a 48-hour action plan. For each of the three priority questions: the single next action, who is responsible, and by when.
Label decision-relevant claims as [EVIDENCE], [INTERPRETATION], [ASSUMPTION], or [UNKNOWN]. Do not invent facts about the market, the people involved, technical capability, cost, or the organisation. Do not answer any of the questions you generate. The value of this prompt is the question set itself, and a clear route to answering the three that matter most.
Prompt 1.2
Persona and Deep Empathy
Understand the person, the recent episode, and the tension - not a fictional profile.
Innovation Judgment lens: A plausible persona is not evidence. Use this to separate what is observed about an actor from what is inferred, then design questions that could change your mind.
Copy prompt 1.2
Act as a design researcher helping a project team understand the people at the centre of a Innovation Judgment challenge. You have no web or external access: everything you need is contained in this prompt, and you must work only from the material supplied inside it.
FRAMEWORK REFERENCE
An empathy map separates what an actor Says, Thinks, Does, and Feels. Use each category only as [EVIDENCE] when supplied material supports it; otherwise treat it as an [ASSUMPTION] or [UNKNOWN], not as a fact about a fictional person.
Jobs-to-be-Done separates three kinds of progress an actor may seek: a functional job (the practical task), an emotional job (the feeling or state they want), and a social job (how they want to be seen by others). It is a lens for questions, not proof of motives.
First state what sources you can access. Separate [EVIDENCE], [INTERPRETATION], [ASSUMPTION], and [UNKNOWN]. If no behavioural evidence is supplied, do not create a vivid fictional persona; create an interview plan and a clearly labelled persona hypothesis instead.
Organisation: [Your Organisation]
Problem space: [challenge]
Primary actor: [role most affected]
Other actors who may enable, block, operate, or own exceptions: [roles]
What we know: [quotes, observations, data, or "starting from scratch"]
Your task:
1. Build a compact actor profile: goals, friction, workarounds, functional/emotional/social jobs, and tensions. Add a claim label to each decision-relevant point.
2. Identify the top three unmet-need hypotheses in this format: "[Actor] needs a way to [do X] because [tension]." Mark the evidence or assumption behind each.
3. Name the other actor most likely to disagree with the primary actor, and the question that could surface the disagreement.
4. Write an 8-question, 30-minute interview guide. Start with a recent real episode, then probe trigger, sequence, workaround, consequence, authority, hand-off, and exception. Avoid questions that ask the person to validate our solution.
5. End with the observation that would most change the team's next decision, and what this research will NOT establish.
Prompt 1.3
PESTLE Horizon Scan
What external forces could make today's answer fragile tomorrow?
Innovation Judgment lens: This is not a generic trend list. Every force must alter a decision, dependency, adoption condition, trust boundary, or test. Do not generalise from a city, country, or region without a source.
Copy prompt 1.3
Act as a innovation strategist running a decision-relevant PESTLE horizon scan. You have no web or external access: everything you need is contained in this prompt, and you must work only from the material supplied inside it.
FRAMEWORK REFERENCE - PESTLE
Political: government priorities, public policy, or geopolitical conditions. Economic: incentives, costs, liquidity, income, or market conditions. Social: behaviour, norms, trust, expectations, or demographic shifts. Technological: capabilities, infrastructure, standards, or adoption patterns. Legal: binding rules, responsibilities, permissions, or liability. Environmental: physical, climate, resource, or sustainability conditions.
Use only the dimensions that could change the decision. PESTLE is a filter for decision fragility, not a request to generate a generic trend list.
You have no web or external access. Work only from the material supplied below. Where a force cannot be evidenced from that material, record it as [UNKNOWN] with the precise question the team must answer. Do not infer how a named country, city, region, group of people, regulator, or organisation behaves from generic geography.
Industry / sector: [sector]
Market(s) / geography: [exact scope]
Problem space: [challenge]
Time horizon: [30 days / 12 months / other]
Current hypothesis: [what the team is considering]
Available sources: [files, notes, or data you have supplied, or "none"]
Your task:
1. Start with: "This decision becomes materially different if..." Name up to three conditions.
2. Examine only the PESTLE dimensions that could change one of those conditions. For each force, show: evidence/source or unknown; tailwind, headwind, or wild card; affected actor/workflow; precise decision it could change; and what would disconfirm it.
3. For every geography in scope, distinguish what is verified from what cannot be transferred from another market. State the exact local question still to answer.
4. Summarise the one force to design for, the one risk to monitor, and the one weak signal worth tracking. Each must include a decision link.
5. End with no more than three research actions, ranked by the consequence of being wrong.
Avoid trend lists and unsupported regional claims.
2
Define
A brilliant solution to the wrong problem is still a failure. Stress-test the How Might We statement until a real actor, evidence, tension, and boundary are visible.
Prompt 2.1
The HMW Stress Test
Human, specific, evidence-based, assumption-free, and ambitious enough.
Innovation Judgment lens: A coherent HMW can still hide an unsupported leap. The test requires evidence, exposes the solution smuggled into the question, and states what would make the team rewrite it.
Copy prompt 2.1
Act as a Innovation Judgment facilitator reviewing a How Might We statement before ideation. You have no web or external access: everything you need is contained in this prompt, and you must work only from the material supplied inside it.
FRAMEWORK REFERENCE
A How Might We statement is an open question that names an actor, a desired outcome, and a tension or obstacle. It describes a problem or opportunity; it does not contain the answer. A useful pattern is: "How might we help [actor] achieve [outcome] despite [tension]?"
The 5 Whys is a short chain of "why does this happen?" questions used to distinguish an observed symptom from a plausible mechanism or deeper condition. Stop the chain when the next answer is unsupported, speculative, or outside the team's control.
First state what evidence you can access. Label decision-relevant claims [EVIDENCE], [INTERPRETATION], [ASSUMPTION], or [UNKNOWN]. Do not mistake a competitor claim, feature request, or internal target for proof of a problem.
Current HMW: [paste current statement]
Context and affected actor(s): [context]
Evidence or observations: [what was seen, heard, or measured]
Constraints / decision boundary: [scope]
Your task:
PART 1 - THE STRESS TEST
For each test, give Pass / Partial / Fail, claim label, and a concise reason:
1. Human - does a real actor recognise the outcome or tension?
2. Specific - could a team learn something meaningful within the stated scope?
3. Evidence-based - what observation or behaviour supports the problem?
4. Assumption-free - does it describe the problem rather than presuppose an app, AI, process, or feature?
5. Ambitious enough - would solving it make a meaningful difference?
PART 2 - ROOT CAUSE CHECK
Use a short 5 Whys ladder. Stop when the next answer is unsupported or outside the team's control. Mark where the current HMW is operating: symptom, mechanism, or root condition.
PART 3 - REFRAME
Write three materially different versions:
A. Tighter and more specific.
B. More human and empathy-led.
C. More systemic or ambitious, without smuggling in a solution.
For each, state the evidence gap and what would make the team reject it.
End with the version worth taking into ideation, or recommend the smallest evidence-gathering move first.
3
Develop
Go wide before going deep. Borrow mechanisms, generate genuinely different routes, then use the pre-mortem to surface what could make the strongest-looking option fail.
Prompt 3.1
Forced Associations: Borrowing Brilliance
What principle from another domain could create a different project bet?
Innovation Judgment lens: Borrow a mechanism, not a brand's feature. The point is to expose a different theory of the problem and test the limit of the analogy before you copy anything.
Copy prompt 3.1
Act as an innovation strategist using forced associations to create wider solution options. You have no web or external access: everything you need is contained in this prompt, and you must work only from the material supplied inside it.
FRAMEWORK REFERENCE
A forced association deliberately links the current problem to a practice from an unrelated domain. The transferable unit is a mechanism: a repeatable practice, feedback loop, incentive, hand-off, control, recovery pattern, or operating principle. It is not an instruction to copy a famous brand's feature or claim that another organisation performs better. The test is whether the mechanism creates a genuinely different theory of the problem in this context.
First state what you can access. Label decision-relevant claims [EVIDENCE], [INTERPRETATION], [ASSUMPTION], or [UNKNOWN]. Do not claim that an external organisation's internal process, capability, or performance is known without a source.
HMW statement: [finalised HMW]
Industry / context: [sector and constraints]
Evidence and key assumptions: [paste]
Your task:
1. Select five different domains. Include one from nature/biology, one from sport/performance, and one from arts/entertainment. If you cannot verify a named example, describe a domain-level mechanism rather than inventing a case.
2. For each, identify one practice or principle that could transfer. State: mechanism; why it might fit; limit of analogy; what would make it unsafe or irrelevant here.
3. Generate two concrete ideas for each mechanism. Each must name the actor, workflow change, value hypothesis, dependency, and exception or failure path.
4. Select three ideas that are materially different, not merely different interfaces. For each, write a concept card: what it is; what it intentionally does not solve; assumption to earn; smallest safe test; result that would change the idea.
5. End with the most seductive but least-supported idea, and the evidence it would need before further investment.
Prompt 3.2
Crazy Eights: 25 Solutions
Quantity before quality. Five categories of genuinely different moves.
Innovation Judgment lens: Go wide, but prevent 25 variations of the same feature. Each category changes the mechanism, workflow, service, partner, or theory of the problem.
Copy prompt 3.2
Act as an innovation facilitator running a Crazy Eights sprint. Generate volume and variety before evaluation. You have no web or external access: everything you need is contained in this prompt, and you must work only from the material supplied inside it.
FRAMEWORK REFERENCE
Crazy Eights is a divergent-ideation exercise: generate many distinct options before judging them. An option is distinct only when it changes at least one of the actor, mechanism, workflow, value exchange, partner role, automation boundary, or theory of the problem. Renaming the same feature, screen, or process does not create a distinct option. Do not evaluate, rank, or choose a winner until the full option set exists.
Organisation: [Your Organisation]
HMW statement: [finalised HMW]
Known constraints: [constraints, risk boundary, or "not yet known"]
Evidence and key assumptions: [paste]
Generate exactly 25 distinct solutions in five categories of five:
1. INCREMENTAL - improve the existing experience.
2. PROCESS AND SYSTEM - change hand-offs, decisions, incentives, or information flow.
3. TECHNOLOGY-ENABLED - use technology only where a capability is supplied or clearly labelled as an assumption.
4. CROSS-INDUSTRY BORROWING - adapt a mechanism from another domain; name the mechanism, not an unsupported feature claim.
5. BOLDER BETS - change the value exchange, responsibility, partner role, or operating condition.
Rules:
- Each idea gets a 3-5 word name and one-sentence description.
- Each idea must identify the actor and the change it makes.
- At least five ideas must challenge a fundamental assumption about the default solution.
- At least three ideas must change the workflow, service, commercial model, or partner relationship rather than add an interface.
- Do not score or select winners yet.
After the 25 ideas, run a distinctness check. Group any ideas that are merely variations and replace duplicates. Then name the three assumptions that appear most often across the list and the evidence each would need.
Prompt 3.3
Innovation Judgment Pre-Mortem
Assume the project failed. Make failure useful now.
Use the original stance: This is not a risk checklist or an approval exercise. First imagine the bet failed, then define the bounded conditions under which it could become a trusted, high-value capability. The final human judgment cannot be delegated.
Copy prompt 3.3
You are my rigorous Innovation Judgment red team, operating-model designer, and evidence-oriented research partner. Your role is not to approve the project, dramatise risk, or make it sound good. Your role is to make the project more trustworthy, more useful, and more likely to earn adoption.
FRAMEWORK REFERENCE
Treat the framework reference below as self-contained. You have no web or external access: work only from the material supplied in this prompt.
A pre-mortem assumes a proposed bet has already failed, then works backward to identify the failure mechanisms that normal optimism may hide. The failure horizon is the project-specific story of how that failure occurred by the stated decision timeframe. The opportunity horizon is the bounded, credible success story that becomes possible through better sources, clearer hand-offs, visible human judgement, and useful learning - not broader autonomy or unsupported capability. The Challenge Cabinet uses distinct stakeholder roles to surface different questions; it must not claim those people actually think or feel something without evidence. The 72-hour pre-flight is a short set of permitted tests that can change the next decision immediately.
We will create productive urgency and credible hope. First, assume the project failed. Then identify the bounded conditions under which it could become a trusted, high-value capability. I remain accountable for context, verification, escalation, and judgement.
FIRST: ACCESS AND CLAIM BOUNDARY
You have no web or external access and cannot retrieve or verify citations. State what is present in the material supplied below, and treat every external fact, capability, policy, control, threshold, percentage, cost, or date as [UNKNOWN] until the team supplies it. Never claim to have verified a capability or read a source you cannot see here. Label every decision-relevant statement exactly once:
[EVIDENCE] directly supported by the brief or material supplied below.
[INTERPRETATION] plausible failure mechanism or trade-off; state the uncertainty.
[ASSUMPTION] belief to test; name the test that could earn or reject it.
[UNKNOWN] missing fact; state the question, best source type, owner role, and decision it informs.
PROJECT BRIEF
Project / workflow name: [name the workflow, not the technology]
Owner / working team: [roles]
Intended outcome and current friction: [paste]
Proposed project bet: [paste]
Approved / trusted sources: [paste]
Data boundary and exclusions: [paste]
Human checkpoint, exception owner, and escalation: [paste]
Success measure / baseline / decision timeframe: [paste, or "not yet defined" - the experiment window is 30 days]
Known assumptions, dependencies, or constraints: [paste]
WHEN I SAY RUN THE PRE-MORTEM, RETURN:
1. Boundary declaration: what is known, inferred, hypothesised, and unknown.
2. Failure horizon: a 150-word project-specific failure story, labelled claim by claim. Explain how rework, confusion, risk, non-adoption, or loss of trust happened. Do not invent vivid details.
3. Challenge Cabinet: affected user; buyer/economic owner; operations/service owner; risk/compliance owner; technical/integration owner; partner/supplier; executive sponsor; person not consulted. For each: challenge question; early signal; evidence demand; change/opportunity now.
4. Risk and resilience ledger: six decision-useful failure mechanisms with likelihood, earliest observable signal, evidence needed, bounded condition that reduces risk, named human role, and the decision it would change.
5. The uncomfortable truth: the single failure condition with the greatest damage and hardest recovery, why reasonable people could minimise it, and the human decision that cannot be delegated.
6. Three assumptions to earn, exactly in this format: "[ASSUMPTION] We believe [X]. We will know we are wrong if [Y] happens by [timeframe or validation condition supplied by us]."
7. Opportunity horizon: a 120-word trusted-success story, followed by three bounded improvements: safer v1; reusable pattern; higher-leverage redesign. For each: opportunity; conditions required; evidence to earn; unwise if.
8. 72-hour pre-flight: no more than four immediate tests with approved inputs, named human owner, decision informed, red flag, and next action.
9. Executive decision memo: Proceed with bounded test / Revise before test / Park pending evidence; non-negotiable condition; highest-value opportunity; human decision that cannot be delegated; result that would change the recommendation.
10. Red-pen claim audit: list every unsupported proper noun, capability, connector, policy, technical control, threshold, percentage, cost, date, or external comparison introduced. Replace it with [UNKNOWN] and a research action. If none remain, state: "No unsupported specifics remain."
The aim is not to feel better about the project. The aim is to make it better: clearer in its source boundary, more useful in its workflow, safer in its human hand-off, and more ambitious only where evidence earns the right.
4
Deliver
You have options. Now sort, test, and explain them without creating false certainty. Choose a provisional bet, state what it depends on, and commit to a 30-day experiment that will decide it.
Prompt 4.1
How / Now / Wow / Ciao Sorting
Not every good idea is a ready idea. Sort by impact, originality, feasibility, and evidence.
Innovation Judgment lens: Sorting is a conversation, not a magic score. The prompt requires the team to separate a high-impact idea from a well-supported, testable one and to name the assumptions hidden in feasibility.
Copy prompt 4.1
Act as a pragmatic project portfolio manager helping a team prioritise ideas with the How / Now / Wow / Ciao framework. You have no web or external access: everything you need is contained in this prompt, and you must work only from the material supplied inside it.
FRAMEWORK REFERENCE
WOW: an idea with meaningful impact/originality and enough evidence or feasibility for a bounded next move. NOW: a feasible quick win with limited originality or impact. HOW: an attractive idea that is not yet feasible or depends on conditions the team has not earned. CIAO: a low-value, poor-fit, duplicate, or unsupported idea to deprioritise. These are qualitative discussion categories, not mathematical scores or proof of a business case.
First state what evidence is available in the material supplied. Label claims [EVIDENCE], [INTERPRETATION], [ASSUMPTION], or [UNKNOWN]. Do not invent feasibility, impact, demand, budget, timeline, or regulatory approval.
HMW statement: [paste finalised HMW]
Ideas to sort: [paste ideas with one-line descriptions]
Context and constraints: [paste]
Evidence / assumptions / dependencies: [paste]
Your task:
PART 1 - SORT THE IDEAS
For every idea, assess impact/originality and feasibility as High / Medium / Low only when supported; otherwise use Unknown. Sort into:
- WOW: high impact/originality and feasible enough for a bounded next move.
- NOW: feasible quick win with limited originality or impact.
- HOW: attractive but dependent on conditions the team has not yet earned.
- CIAO: low value, weak fit, or a duplicate of a stronger option.
For every assessment, state the evidence, assumption, or unknown behind it.
PART 2 - PORTFOLIO RECOMMENDATION
Identify up to three WOW, two HOW, and three NOW options. For each selected idea show: actor outcome; value hypothesis; key dependency; risk or exception; smallest credible test; result that would make us revise or stop.
PART 3 - 30-DAY EXPERIMENT PLAN
The programme runs a 30-day experiment. For the strongest provisional bet, provide: days 1-10 - what to test; days 11-20 - what behaviour or evidence to seek; days 21-30 - the decision rule (advance, adapt, or stop). Use only the measures and validation conditions supplied below. If a measure is missing, name the validation condition instead of inventing a target.
End with the single biggest internal obstacle and the human decision that cannot be delegated.
Prompt 4.2
Pitch Sharpener
Make the reasoning clear, the uncertainty honest, and the ask easy to evaluate.
Innovation Judgment lens: Do not make the idea "undeniable." Make the logic traceable. A good pitch leads with the decision, states what is evidenced and unknown, and tells the audience what would change the recommendation.
Copy prompt 4.2
Act as an executive communications coach helping a project team make a clear, evidence-aware decision request. You have no web or external access: everything you need is contained in this prompt, and you must work only from the material supplied inside it.
FRAMEWORK REFERENCE
The Pyramid Principle leads with the answer or decision request, then supports it with a small number of distinct, mutually reinforcing points. In this prompt, the three supports are: evidence, trade-off or risk boundary, and learning plan. Objection handling means naming a reasonable concern clearly, responding with the evidence or unknown that is actually available, and stating the next action that could resolve it. It is not spin or a demand to make the idea sound certain.
First state what material you can access. Label decision-relevant claims [EVIDENCE], [INTERPRETATION], [ASSUMPTION], or [UNKNOWN]. Do not replace uncertainty with confident language. Do not turn an unverified benefit into a quantified promise.
Provisional bet: [what it is, how it works, and the problem it addresses]
Audience: [who is being asked to decide]
Decision / ask: [approval for research, bounded test, resources, sponsorship, or other]
Evidence, unknowns, and key trade-offs: [paste]
Likely concerns: [paste]
Time available: [3 minutes / 15 minutes / one page]
Your task:
PART 1 - PITCH STRUCTURE
Use the Pyramid Principle:
- The headline decision and ask.
- Three supporting points: evidence; trade-off or risk boundary; learning plan.
- What we know, what we do not know, and the condition that would change the recommendation.
- What happens next if the audience says yes.
PART 2 - LANGUAGE SHARPENING
Rewrite the pitch for this audience. Replace innovation jargon with the relevant actor outcome and decision. Replace vague benefits with sourced evidence, explicit assumptions, or a proposed test. Keep the ask proportionate to uncertainty.
PART 3 - OBJECTION PRE-EMPTION
Identify the five most likely objections. For each: state the objection in the audience's language; give an honest response; mark what is evidence versus assumption; say whether it belongs in the pitch or Q&A; and name the evidence that could resolve it.
PART 4 - THE ONE-MINUTE VERSION
Write a 60-second spoken version that includes the decision, the evidence, the key uncertainty, the bounded next move, and the ask.
End with one coaching note: where could this pitch slip into certainty theatre, and how should the team correct it?