PEP
The evidence section has to be capable of not supporting your proposal.
What is PEP?
PEP is three slots: Problem, Evidence, Proposal. It is the shape of a recommendation backed by data, and the entire difference between a good one and a bad one sits in the middle slot — specifically in whether the evidence was allowed to disagree.
Almost every data-backed proposal is written backwards. Someone forms a view, then goes looking for the numbers that support it, and the Evidence section becomes a gallery of figures that all point the same way. It reads as rigorous and it is advocacy. The test that makes PEP worth using: could the evidence you gathered have led you to a different proposal? If not, you did not analyse anything. Building that into the prompt — state what in the evidence argues against the proposal, and what would have made you propose something else — is a small addition that changes what comes back, because it forces the model to look at the numbers it would otherwise have quietly dropped.
Where PEP Came From
A modern convention with no author of record
PEP has no documented inventor. It belongs to the same pool of assembled acronyms as RTF, TAG and SCOPE — a compression of how analysts have always been told to write recommendations. Any page naming a founder is inventing one.
Beware the schools version, which is a different PEP
A real collision. In UK education, PEE / PEEL / PEP is an essay-paragraph structure — Point, Evidence, Explain (or Explain and Link) — taught for exam answers. It shares the letters and one word with this framework and it is a different thing: it structures a paragraph of argument, not a business recommendation. Searching for "PEP framework" will return mostly that.
Why Problem comes before Evidence, and Proposal last
The order encodes the honest sequence: you noticed something, you looked, you concluded. A proposal presented first and evidenced afterwards is a different document with the same three sections, and readers can tell — usually because the evidence is suspiciously tidy. Keeping Proposal at the end is a small structural defence against writing the conclusion first.
The 4 Slots, One at a Time
Each slot is a decision. Leave it out and the model still makes it — just without you.
One or two sentences, quantified, with a direction. "Onboarding completion is poor" is a feeling; "41% of users who start onboarding never finish, and the rate has been climbing since March" is a problem — it has a size, a shape and a clock. Include the second-order symptom if you have one, because it tells the reader the problem is already costing something.
The slot the framework exists for. Give the real figures, at the granularity that discriminates between explanations rather than the granularity that describes the problem. And deliberately include the awkward ones: a 61% return rate and a 19% success rate point in different directions, and a proposal that quotes only the first is arguing rather than reasoning.
Singular. A proposal with three parts is three proposals and will be approved in pieces, usually the cheapest piece. Every claim in it should be traceable to a figure above — and if a part of your proposal has no supporting number, that is worth knowing before somebody else notices.
Add it. State what in the evidence argues against the proposal, and what result would have made you recommend something else. It is the cheapest credibility available: a reader who can see you looked for the counter-case stops looking for it themselves, and it converts the document from a pitch into an analysis.
One Task, Before and After
The task: A data-backed proposal about a 24% drop-off at one onboarding step. Both prompts below are scored by our free prompt checker — paste either in and you will get the same number, because the scoring is deterministic.
Write a proposal about our onboarding drop-off.
Seven words. You get a confident three-part proposal — simplify the flow, add a progress bar, send a follow-up email — supported by figures the model chose, none of which discriminate between the three.
Write a data-backed proposal using Problem, Evidence, Proposal. Problem: 41% of users who start our onboarding never finish it, and the rate has been climbing since March. Support tickets from new accounts are up 22% over the same period. Evidence, and this is the only evidence available: drop-off by step is 6% at step 1, 9% at step 2, 24% at step 3, 2% at step 4. Step 3 asks users to connect a data source. Median time on step 3 is 4 minutes 40 seconds against 40 seconds on every other step. Of the users who abandon at step 3, 61% return within seven days and try again; 19% of those succeed. Session recordings of 30 abandonments show 22 users opening a second tab before leaving. Proposal: make step 3 skippable, with the connection deferred to first use of a feature that needs it. The discipline this framework exists for is that the Evidence section must be capable of NOT supporting the Proposal. So state explicitly what in the evidence argues against the proposal, and what evidence would have made you propose something else instead. Write 500 to 650 words for a product lead and an engineering lead who will decide whether to schedule this, in three headed sections plus a short section called What would change my mind. Work through the numbers before you write: the 61% return rate and the 19% success rate point in different directions, and a proposal that quotes only one of them is arguing rather than reasoning. For example, present the drop-off like this: ``` Step 3 (connect a data source): 24% drop-off, against 6%, 9% and 2% at the other three steps. Median time on step: 4m40s, against roughly 40s elsewhere. ``` Ensure every claim in the Proposal traces to a figure in the Evidence, and prioritise the numbers that discriminate between explanations over the ones that merely describe the problem. Do not invent metrics, benchmarks or user quotes, and do not propose a second change - one proposal.
Ninety-one. The section that is not in the acronym — What would change my mind — is doing more for the document's credibility than any of the three that are.
Ninety-one, and cherry-picked evidence scores exactly as well
One check is out of reach, and the failure this framework exists to prevent is invisible to any rubric:
No persona slot. Eight points for adding one, and on our scorer a generic analyst persona earns the same as a carefully drawn one — so the points say nothing about whether it helped.
The whole discipline, and nothing measures it. Six figures that all point the same way score identically to six that genuinely constrain the conclusion. The check is one question you have to ask yourself: could this evidence have produced a different proposal?
The number you did not include is invisible by definition. A proposal quoting the 61% return rate and omitting the 19% success rate reads better and means less.
So the addition worth making to any evidence-backed document, whatever framework you use: a short section saying what would change your mind. It costs four sentences, no scoring system rewards it, and it is the fastest way to tell a reader that they are reading an analysis rather than a case being made.
Copy-Paste Prompt Template
Replace the bracketed placeholders with your specific details.
Problem: [what is wrong — quantified, with a trend, and the second-order symptom] Evidence: [the real figures, at the granularity that DISCRIMINATES between explanations] [Include the awkward numbers — the ones that complicate your case] Proposal: [ONE change, every claim traceable to a figure above] What would change my mind: [what in the evidence argues AGAINST this, and what result would have made you propose something else] [Reader, length, and a fenced sample of how to present the numbers] [No invented metrics, benchmarks or quotes. One proposal, not three]
When PEP Fits — and When It Does Not
- Recommendations built on analytics, where the numbers are the argument.
- Proposals that will be challenged by someone with access to the same data.
- Post-incident and post-experiment write-ups that end in a recommendation.
- Any change request that needs to be scheduled by somebody else.
- Short internal documents — one page, one problem, one proposal.
- Situations with no real data. Without evidence, PEP is an opinion with three headings.
- Multi-part programmes. One proposal per document; three become three approvals.
- Persuasion of a hostile audience — use SCIPAB, which brings them along first.
- Exploratory work where you do not yet have a proposal. Use SCOPE to plan the investigation.
- Long strategy documents. Three slots does not organise anything past a couple of pages.
10 Ready-Made PEP Prompts
Every prompt below was produced by the Frompting generator with PEP selected — not written by hand for this page. Each is scored by our prompt checker; the median is 95/100. Click one to open it, then copy.
A drop-off found in analytics 76
You are a data‑driven strategist tasked with crafting a concise recommendation to address a recent drop‑off identified in analytics. Your recommendation should: - Clearly describe the issue that is occurring, referencing the specific product, feature, or process affected. - Summarize the quantitative evidence, including the key metric that declined, the magnitude of the change, and any relevant time period or segment details. - Propose a concrete change or set of actions aimed at reversing the drop‑off, outlining expected impact, required resources, and a short‑term implementation timeline. Deliver the recommendation in a single paragraph of 150–200 words, written in a professional yet accessible tone. Ensure the argument is logical, evidence‑based, and includes at least one measurable success criterion. [PRODUCT_OR_FEATURE: specify the product, feature, or process experiencing the drop‑off] [KEY_METRIC: specify the metric that declined (e.g., conversion rate, retention rate)] [TARGET_AUDIENCE: specify who will read and act on this recommendation (e.g., product team, marketing leadership)] [IMPLEMENTATION_TIMEFRAME: specify the desired timeframe for the proposed change] If any of the above details are unknown, state your assumptions clearly and ask up to three clarifying questions before finalizing the recommendation. Before writing the final answer, work through the problem step by step and weigh the main trade-offs; present only the reasoned conclusion, not your working notes.
A worsening support metric 91
You are a data-driven support operations analyst. Your task is to develop a concise, evidence-based recommendation to reverse the decline of a key support metric. The recommendation should be written for [STAKEHOLDER_ROLE: e.g., senior support manager, VP of Customer Success] and be under 820 words. Structure your response as follows: 1. Briefly describe the specific support metric that is worsening, including its recent trend and why it matters to the business. 2. Present the most relevant data points, benchmarks, or observations that illustrate the severity and possible causes of the decline. Use a markdown table if multiple figures are needed. 3. Propose a clear, actionable fix or set of fixes, linking each action to the evidence presented and indicating the expected impact on the metric. Quality criteria: - Accuracy: base all statements on the data you provide or on well-known industry standards. - Relevance: each piece of evidence must directly support the proposed actions. - Practicality: recommendations should be feasible for a typical support organization without requiring unknown resources. Boundary: do not suggest changes to unrelated departments or assume the availability of new technology unless explicitly stated. If any essential details (e.g., the exact metric name, current value, target level, or operational context) are missing, state your assumptions and ask up to three clarifying questions before finalizing the recommendation. Before writing the final answer, work through the problem step by step and weigh the main trade-offs; present only the reasoned conclusion, not your working notes.
An investment based on cohort data 89
You are a financial analyst tasked with creating a data‑driven investment recommendation based on cohort performance. First, identify the core business challenge that the investment must address. Next, gather and present the quantitative evidence that supports the analysis, using the following methodologies where appropriate: - Cohort analysis of monthly revenue retention, separating logo churn from revenue churn, and tracking expansion revenue (upsell/cross‑sell) within each cohort. - SaaS unit‑economics calculations, including blended CAC (with S&M headcount), gross‑margin‑adjusted LTV, LTV : CAC ratio, and CAC payback period. - Relevant three‑statement financial metrics (P&L, balance sheet, cash flow) that link to the cohort data. - Market sizing estimates (TAM, SAM, SOM) derived from both top‑down and bottom‑up approaches. Finally, formulate a concise investment proposal that includes: - The recommended amount and structure of the investment. - Expected financial outcomes (e.g., projected ARR growth, LTV improvement, CAC reduction) under base, bull, and bear scenarios. - A sensitivity table highlighting the most impactful assumptions. Deliver the output as a markdown document with three clearly separated sections (challenge, evidence, recommendation). Keep the total length between 350 and 500 words. Quality criteria: 1. All calculations must be shown step‑by‑step and use the most recent cohort data you have. 2. Assumptions should be explicitly stated; if any key inputs are missing, insert a placeholder in the form **[PLACEHOLDER: description of needed input]**. 3. The recommendation should be actionable and include at least one measurable KPI to track post‑investment performance. If any critical data (e.g., cohort size, churn rates, CAC components, market size inputs) are unavailable, state the assumption you are making and ask up to three clarifying questions before finalizing the recommendation. Write this for [AUDIENCE: who will read the output, and how much they already know]. Match the depth, vocabulary and examples to that reader. Before writing the final answer, work through the problem step by step and weigh the main trade-offs; present only the reasoned conclusion, not your working notes.
A process change from cycle time data 89
You are a data‑driven process improvement consultant. Your task is to craft a concise recommendation for a process change that will reduce cycle time, using the supplied cycle‑time data as the sole basis for your analysis. First, describe the specific operational issue that the current cycle‑time performance is causing. Next, present the key metrics, trends, and any comparative benchmarks drawn from the provided data that illustrate the magnitude and impact of the problem. Finally, propose a concrete process change, outlining the steps to implement it, the expected effect on cycle time (with a quantitative estimate), and any required resources or stakeholder involvement. The recommendation is for: [AUDIENCE: role or team that will receive the proposal, e.g., operations manager, production team]. Deliver the output as a single, well‑structured paragraph of 180–250 words. Ensure the argument is logical, the evidence is directly referenced, and the proposal is actionable. Quality criteria: 1. Evidence‑based: every claim about the problem or expected improvement must be tied to a data point. 2. Clarity: the recommendation should be understandable without additional context. 3. Feasibility: include only resources or steps that are realistic for a typical mid‑size operation. Exclude any discussion of alternative frameworks, unrelated metrics, or speculative benefits beyond cycle‑time impact. If any bracketed detail above is left unfilled, choose a sensible value from the context, state that assumption in one line before you begin, and continue — do not ask for it and stop. Before writing the final answer, work through the problem step by step and weigh the main trade-offs; present only the reasoned conclusion, not your working notes.
A pricing change from usage data 95
You are a data-driven pricing analyst. Your task is to craft a concise recommendation for adjusting the price of a product or service based on recent usage data. The recommendation will be read by [STAKEHOLDER: e.g., senior management, product team, investors] and should be under 540 words. Structure your response as a logical flow: first describe the core issue that the pricing change must address, then present the relevant usage evidence that supports the need for change, and finally outline a concrete pricing adjustment proposal with supporting metrics. Include a brief summary (1-2 sentences) at the start that captures the overall recommendation. Quality criteria: 1. Evidence is drawn directly from the usage data you reference. 2. The proposal is specific, actionable, and includes at least one quantitative target (e.g., percentage price increase, new price tier). 3. Language is clear, professional, and avoids unnecessary jargon. Boundary: do not include speculative market trends or competitor pricing unless you have explicit data. If any of the following details are unknown, state your assumption and proceed, or ask up to three clarifying questions before finalizing: - [PRODUCT: brief description of the product or service] - [CURRENT PRICING MODEL: description of how the product is currently priced] - [USAGE METRICS: key usage statistics available, such as average units per user, frequency, or revenue per user] - [BUSINESS GOAL: primary objective of the pricing change, e.g., increase revenue, improve adoption, cover costs] Write this for [AUDIENCE: who will read the output, and how much they already know]. Match the depth, vocabulary and examples to that reader. Before writing the final answer, work through the problem step by step and weigh the main trade-offs; present only the reasoned conclusion, not your working notes.
A staffing change from workload data 96
You are a data‑driven staffing analyst. Your task is to recommend a staffing adjustment that aligns the team’s capacity with the observed workload. First, describe the specific staffing challenge the organization faces, including any constraints such as budget limits, skill requirements, or operational deadlines. Next, examine the provided workload data (e.g., hours logged, task counts, peak periods, productivity rates) and identify any gaps or imbalances between current staffing levels and demand. Summarize the key metrics that illustrate the need for change. Finally, propose a concrete staffing change (e.g., hiring, reassigning, reducing headcount, shifting schedules) that directly addresses the identified gaps. Support your recommendation with quantitative justification, outline expected outcomes, and note any implementation considerations. Deliverable: a concise report of 300–400 words, structured in three paragraphs corresponding to the steps above. Quality criteria: 1. Recommendations are explicitly tied to the data points you analyze. 2. Assumptions are clearly stated, and any missing information is flagged with a placeholder in the format [UNKNOWN: brief description of needed detail]. 3. The report is clear, actionable, and avoids unnecessary jargon. Boundary: Do not include speculative market trends or unrelated organizational policies. Write this for [AUDIENCE: who will read the output, and how much they already know]. Match the depth, vocabulary and examples to that reader. Before writing the final answer, work through the problem step by step and weigh the main trade-offs; present only the reasoned conclusion, not your working notes.
A marketing shift from channel performance 95
You are a data‑driven marketing strategist. Your task is to craft a concise recommendation for shifting the company’s marketing focus based on recent channel performance. First, describe the core issue the current channel mix is creating for the business. Next, present the key performance evidence that illustrates why the existing allocation is sub‑optimal, citing specific metrics such as conversion rates, cost per acquisition, ROI, or engagement trends. Finally, propose a clear, actionable shift in marketing spend or tactics that addresses the identified issue, explaining how it will improve the highlighted metrics and align with the overall business objectives. Deliver the recommendation as a single, well‑structured paragraph of 180–250 words. Ensure the proposal is realistic, data‑focused, and directly tied to the evidence presented. Exclude any speculative opinions not grounded in the provided data. If any essential details are missing, state your assumptions explicitly and ask up to three clarifying questions before finalizing the recommendation. [CHANNEL_DATA: supply recent performance metrics for each marketing channel] [TARGET_AUDIENCE: describe the primary customer segment(s) the marketing efforts aim to reach] [BUSINESS_GOALS: outline the specific outcomes (e.g., revenue growth, lead generation) the company seeks] Write this for [AUDIENCE: who will read the output, and how much they already know]. Match the depth, vocabulary and examples to that reader. Before writing the final answer, work through the problem step by step and weigh the main trade-offs; present only the reasoned conclusion, not your working notes.
A product change from user research 88
You are a product strategy analyst tasked with recommending a concrete product change grounded in user research. Your analysis should flow must: 1. Identify the core issue the product is facing, describing the specific user pain or market gap. 2. Summarize the research evidence that supports this issue, citing the most relevant findings, metrics, or user quotes. 3. Present a single, actionable product change that directly addresses the identified issue, explaining how it leverages the evidence and what impact it is expected to have. The recommendation is for: **[PRODUCT_NAME]** aimed at **[TARGET_USER_GROUP]**. Deliver a concise report of **515-675 words** structured as three short paragraphs (problem, evidence, proposal). Quality criteria: - Clearly articulate the problem in user-centric language. - Base the evidence on concrete data points or direct user feedback; avoid vague opinions. - The proposal must be specific, feasible, and include an expected outcome metric (e.g., increase in engagement, reduction in churn). Exclude any speculative market trends unrelated to the provided research. If any required detail is missing, state your assumption and ask up to three clarifying questions before finalizing the recommendation. Before writing the final answer, work through the problem step by step and weigh the main trade-offs; present only the reasoned conclusion, not your working notes.
An infrastructure change from cost data 95
You are an infrastructure strategy analyst. Your task is to develop a concise, data‑driven recommendation for changing the organization’s technology stack in order to reduce overall costs while maintaining required performance and reliability. First, describe the current cost‑related challenge the organization faces, including any known budget pressures, cost overruns, or inefficiencies. Next, present the quantitative evidence you have (or need) to support the analysis: recent cost breakdowns, usage metrics, capacity trends, and any relevant pricing models. Use a markdown table to summarize the key figures you are working with. If specific numbers are missing, insert a placeholder in the format **[MISSING_DATA: brief description of the needed metric]**. Finally, formulate a concrete proposal that outlines the recommended infrastructure change, the expected cost impact, implementation steps, and any trade‑offs. Present the recommendation in a short executive summary (≈150 words) followed by a bullet list of actionable steps (no more than 6 items). Output must be plain text, total length 250–350 words, and include: - Clear linkage between the identified problem, the evidence, and the proposed solution. - At least one metric showing the projected cost saving (e.g., percentage reduction or dollar amount). Quality criteria: accuracy of calculations, logical coherence, and actionable clarity. Exclude any discussion of alternative technologies not directly compared in the evidence. If any critical information is unavailable, state your assumption explicitly and ask up to three clarifying questions before finalizing the recommendation. Write this for [AUDIENCE: who will read the output, and how much they already know]. Match the depth, vocabulary and examples to that reader. Before writing the final answer, work through the problem step by step and weigh the main trade-offs; present only the reasoned conclusion, not your working notes.
A policy change from incident data 96
You are a data‑driven policy analyst. Your task is to craft a concise recommendation for a policy change that addresses a specific incident pattern within an organization. First, describe the core issue that the incidents reveal, focusing on the operational impact and any risks to stakeholders. Next, present the supporting data: include the total number of incidents, time frame, severity distribution, and any measurable trends or ratios that illustrate the problem’s magnitude. Use a markdown table to summarize the key metrics. Then, formulate a concrete policy change that directly mitigates the identified issue. Explain how the proposal will improve outcomes, reference the data points that justify the expected impact, and outline any required implementation steps or resources. The recommendation should be written for [AUDIENCE: e.g., senior management, compliance team, board of directors] and be no more than 300 words. Quality criteria: - Clear linkage between each data point and the proposed change. - Actionable steps that can be realistically implemented. - Evidence‑based justification without unsupported assumptions. Assume any missing details are unknown; list them as placeholders in the format [PLACEHOLDER_LABEL: brief hint]. If critical information is missing, state your assumptions and ask up to three clarifying questions before finalizing the recommendation. Before writing the final answer, work through the problem step by step and weigh the main trade-offs; present only the reasoned conclusion, not your working notes.
Scores range from 76 to 96. They are shown as generated rather than cherry-picked — a library where every entry scores in the nineties tells you it was curated, not measured.
PEP vs the Alternatives
The narrative version of the same job. SCQA builds an argument and lands on an answer; PEP leads with the problem and lets the numbers carry it.
For a room rather than a page, and for an audience that needs bringing along. SCIPAB opens with agreement; PEP opens with the problem and assumes the reader already accepts it.
The recurring-update sibling. PPP reports progress against commitments; PEP makes a single evidenced case for a change.
What comes before, when you do not have the evidence yet. SCOPE plans the investigation; PEP writes up what it found.
For surveying a position rather than proposing a change. SWOT ends in four lists; PEP ends in one decision.
Five Ways People Get PEP Wrong
The defining PEP failure, and it is nearly undetectable in the finished document. The tell is that every figure points the same way. Ask whether the evidence could have produced a different recommendation — if not, it was selected rather than gathered.
The most common form of the above. A figure that complicates the case is the most valuable thing in the section, because including it is what makes the rest believable.
"Completion is down 12%" describes the problem. "Drop-off by step: 6, 9, 24, 2" discriminates between explanations. Only the second tells anybody what to do.
They will be approved in pieces, usually the cheapest piece, and the evidence will be stretched across all three. One problem, one proposal.
If a component of your recommendation has no figure behind it, that is worth discovering yourself rather than in the review. Require every claim to trace to a number above.
It is not in the acronym, it costs four sentences, and it does more for credibility than any of the three sections that are.
PEP Questions
What does PEP stand for?
Problem, Evidence, Proposal — a three-part structure for a recommendation backed by data.
Is this the same as the PEE or PEEL paragraph structure?
No. PEE / PEEL / PEP in education is Point, Evidence, Explain — a way of structuring an essay paragraph for an exam. It shares letters and one word with this framework and does a different job.
What makes the evidence section good rather than just present?
Whether it could have refuted the proposal. If every figure points the same way, the evidence was selected. Include the numbers that complicate the case — they are what make the rest believable.
Why only one proposal?
Because three will be approved in pieces, and the evidence gets stretched thin across all of them. If you have three changes to argue for, write three documents.
What is the "what would change my mind" section?
A short addition that is not in the acronym: what in the evidence argues against your proposal, and what would have made you recommend something else. It is the cheapest credibility available in an internal document.
When should I use SCIPAB instead?
When you are presenting to a room that does not yet accept the problem. SCIPAB opens with agreement and builds; PEP assumes the reader already knows something is wrong.
Generate a PEP Prompt Instantly
Skip the manual template — Frompting applies PEP to your topic in one click.
Try it FreeFramework Details
| Name | PEP |
| Stands for | Problem-Evidence-Proposal |
| Domain | Strategy & Planning |
| Steps | 3 |
| Access | Pro |