Do Not Start with Specs: Use Prompts to Reveal Hidden Assumptions First

It is common for stakeholders to come to PMs with a solution already in mind.

For example, during a meeting, the business team raises a request:

“We want the system to automatically send overdue payment reminder emails, ideally on Day 1, Day 3, and Day 7 after the due date, so we can reduce the manual effort required for payment follow-up.”

At first glance, the requirement seems clear.

The pain point is that manual follow-up for collections takes too much time. The proposed solution is automated email reminders.

So it is easy for PMs to immediately enter feature breakdown mode:

  • When should the emails be sent?
  • Who will provide the email template?
  • How long should the sending records be retained?
  • What should happen if an email fails to send?

With generative AI, PMs may even write a prompt like this:

“I want to build an automated overdue payment reminder email feature. The emails should be sent on Day 1, Day 3, and Day 7 after the payment due date. Please provide the functional specifications.”

AI will quickly generate items such as feature objectives, trigger conditions, sending rules, email templates, sending logs, access control, exception handling, and even database table design.

It looks very efficient.

But here is the problem: AI is simply following the prompt and expanding the specifications. It is not challenging the assumptions behind the requirement.

For example:

Is the payment really overdue because the customer forgot?

Will sending more reminder emails really reduce the manual collection workload?

In my previous article, I shared that the value of AI for PMs is not only in helping us produce documents but also in helping us see the requirements behind requirements.

The same principle applies here.

Before the team jumps too quickly into feature breakdown, we can use AI to help identify the assumptions behind the requirement and avoid spending effort in the wrong direction.

I suggest PMs use the following series of prompts to ask AI to surface hidden assumptions first.

I usually design these prompts using the RTF structure. This is also a simple structure mentioned by Project Management Institute in the course “Talking to AI: Prompt Engineering for Project Managers”: Role, Task, and Format.

Simply put, it means asking AI to play a clear role, perform a clear task, and return the result in a specified format.

Template 1: Surface the Assumptions

Using the RTF structure, we can first ask the AI to analyze the hidden assumptions underlying the business team’s requirement and proposed solution.

The prompt can be written like this:

You are a professional business analyst.

Context:
- Product/project goal: Reduce the overdue payment collection cycle 
and reduce the time spent on manual collection follow-up.
- Target users: Business or individual customers who have received 
an invoice but have not yet paid.
- Existing decision/direction: The system will automatically send 
overdue payment reminder emails on Day 1, Day 3, and Day 7 after the due date.

Please output:
1. The key hidden assumptions;
2. The validation method for each assumption.
3. A Plan B if the assumption does not hold.

Please present the result in a table.

This prompt may produce results similar to the following:

Surface the assumptions behind the requirements and find out the way to validate them. "Surface the assumptions behind the requirements and find out the way to validate them."

The key point of this step is not to produce specifications.

It is to ask: Are we too quick to believe that “email reminders” will solve the problem?

Template 2: Translate Features into Business Goals

Next, I would ask AI to map the features back to business goals.

You are a product and business analysis coach.

Please map the following features to:
1. The real problem to be solved;
2. The business metric;
3. The measurable success criteria.

Features:
- Automatically send overdue payment reminder emails
- Support different email templates for different overdue stages
- Include a payment link in the email
- Record sending time and email open status

Please present the result in a table.

At this point, the requirement is no longer just “build an automated email reminder feature.” It becomes a clearer set of business goals.

Turn features into business goals. "Turn features into business goals."

At this point, the real requirement has already changed.

It is no longer just about building an automated email-sending feature.

It is about increasing the payment rate and reducing manual collection time without increasing customer complaints.

Template 3: Run a Reverse Check Before Development

Finally, before making the development decision, I would ask AI to play the role of an objector.

You are playing the role of an objector.

We are planning to develop an automated overdue payment reminder email feature.
The system will send reminder emails on Day 1, Day 3, and Day 7 after the due date.

Constraints:
- Development timeline: 4 weeks
- Must not significantly increase customer service complaints
- Must comply with personal data and notification consent requirements
- The outcome must be observable and measurable

Please provide a pre-decision checklist from the perspectives of 
data sufficiency, alternative options, risk control, and rollback capability.

The response may look like this:

Do not immediately build the full automation. First, validate whether email is truly an effective channel. Confirm how many overdue customers have historically opened invoice emails. Define complaint rate, unsubscribe rate, and payment conversion rate as observation metrics. If email is not effective, test alternatives such as SMS, LINE, customer service calls, or a one-click payment page.

At this point, the requirement changes from:

"Build automated email reminders."

To:

"Design a measurable experiment to improve payment collection."

This is where AI becomes truly valuable for PMs.

It helps us discover earlier whether we are packaging an unvalidated assumption as a seemingly clear requirement.

PMs do not only make requirements clear.

A more important part of the PM’s job is to make sure the team is not spending effort on the wrong problem.

Have you recently encountered a requirement in which the stakeholder already had a solution in mind?