Prompt
Draft A Data Tool Proof-Of-Concept Plan
Use this when you want a structured test plan for a new tool with scope, success criteria, and evaluation steps.
How to use it
- Copy the prompt and paste it into ChatGPT, Claude, Gemini or any other AI.
- Replace every {{placeholder}} with your own details, or let the AI ask you for them.
- Use the follow-ups below to go deeper.
Role You are a data architect who plans and evaluates data infrastructure changes. Optimise for a proof-of-concept plan that is tightly scoped, measurable and ready for a go or no-go decision.
Context you provide
- {{tool_name}} - tool under evaluation
- {{business_problem}} - problem it should solve
- {{current_stack}} - existing databases and pipelines
- {{poc_time_box}} - duration available
- {{success_criteria}} - agreed measurable outcomes
- {{data_profile}} - sample volume, types and sensitivity
- {{integration_points}} - systems it must connect to
- {{constraints}} - budget, security, compliance, skills
- {{stakeholders}} - decision maker and affected teams
- {{decision_date}} - when the go or no-go call happens
Instructions
- Ask for any missing inputs, then restate the PoC objective in one sentence.
- Name the decision the PoC informs and its owner.
- List what is in scope and out of scope.
- Convert {{success_criteria}} into pass and fail thresholds.
- Define test scenarios for functionality, performance, integration, security and day-two operations.
- For each scenario give the method, owner, data and evidence artifact.
- Build a week-by-week schedule inside {{poc_time_box}} with weekly checkpoints.
- List assumptions, risks, mitigations and early exit triggers.
- Close with a go or no-go recommendation template and next steps.
Output format Markdown. A short overview, a criteria table, a scenario table, a schedule table and a risk list. Under 700 words. Plain business language. No vendor marketing claims, no pricing negotiation and no contract terms.
Guardrails
- Do not invent benchmark figures, standards numbers or compliance certifications. Mark any assumed value as [assumption].
- Flag where security review, legal, procurement or a licensed professional must sign off.
- Tell the user to verify version-specific limits in the vendor's own documentation and manual.
Example {{tool_name}}: a columnar analytics warehouse; {{business_problem}}: nightly reporting runs too slowly; {{poc_time_box}}: four weeks; {{decision_date}}: 30 June.