The MEASURABLE CONSTRAINTS Framework: Never Write a Vague Prompt Again

You sit down on Monday morning. Slack is already on fire. You need a weekly status review, a PRD outline for the new feature, and a stakeholder update — all before standup. So you type into Claude:

"Write a good weekly review for my engineering team."

Claude responds instantly. Twelve paragraphs. Confident tone. Nice formatting.

Then you actually read it.

"Leverage cross-functional synergies to drive alignment on transformative outcomes." "Empower teams through robust, scalable processes." "Delve into actionable insights."

None of it is factually wrong. None of it is useful. You spend 15 minutes rewriting everything. Multiply that by 5 prompts a day, 5 days a week, 50 weeks a year — that's roughly 300 hours of editing AI output. At a PM's hourly rate, that's the $1,000 problem.

Here's what's actually happening: AI fills ambiguity with clichés. When you ask for "a good PRD," the model doesn't know what "good" means to you. It defaults to the statistical average of every PRD in its training data — and the average PRD is full of filler. The fix isn't a better model. The fix is better instructions.

Specifically: measurable constraints.

The MEASURABLE CONSTRAINTS framework is a prompt-writing discipline where every instruction is a binary check. It passed or it failed. No judgment calls. No "this feels about right."

Here's what MEASURABLE stands for:

The framework answers one question: "How do I know if this AI output is any good?" If it passes all your binary constraints, it's good. If it doesn't, you know exactly what to fix.

This is the difference between hoping AI output is useful and knowing it's correct.

Let's see what this looks like in practice. Here's a real PM task — generating a weekly team review — done the old way and the MEASURABLE CONSTRAINTS way.

Before: The Standard PM Prompt

Using the reference document I uploaded as a guide for tone and structure,
generate this week's review based on these 5 things:
1. [What shipped]
2. [What's blocked]
3. [What you learned]
4. [What's coming next]
5. [Anything else]

Match my writing style. No generic business language.

This looks reasonable. It references a tone document. It gives structure. But look closer: "Match my writing style" is not measurable. "No generic business language" is not specific. The model gets to decide what counts.

What you'll get: A 5-paragraph output that sounds "professional" but drifts into AI-voice within two sentences. The blocked items will be phrased as "opportunities." The shipped items won't have dates.

After: The MEASURABLE CONSTRAINTS Prompt

Generate my weekly review based on these inputs:
{{YOUR_5_BULLETS_HERE}}

Measurable Constraints:
1. FORMAT: Exactly 4 sections — Shipped, Blocked, Learned, Next Week
2. LENGTH: Each section is 1-3 sentences. Total under 250 words.
3. PROHIBITION: Zero occurrences of: delve, unlock, leverage, robust, elevate,
   empower, seamless, transformational
4. INCLUSION: Every Shipped item includes a concrete metric or date
5. ACTIONABILITY: The Blocked section ends with "Decision needed:" or "Next step:"
6. PROHIBITION: No speculation about things not in my input bullets
7. FORMAT: The Learned section starts with "Discovered:" not "We learned that"

Use my uploaded voice document for tone and structure.

Every constraint answers a binary question. "Is there a metric in every Shipped item?" Yes/No. "Are there any banned words?" Yes/No. "Does the Learned section start with 'Discovered:'?" Yes/No.

Run both prompts side by side. The constrained output will be shorter, more specific, more useful, and consistent across weeks. The standard prompt output will be verbose, vague, and slightly different every time.

That consistency matters. If your weekly review changes format each Friday, your team stops reading it. Predictable structure = predictable value.

Format constraints define the structure of the output. They answer: "What does this look like when it's done?"

Format is the highest-impact constraint category because it forces the model into a box. When Claude knows it must produce exactly 4 sections, it allocates content differently than when it's free to ramble.

Format constraints you can use today:

• Section count: "Exactly 3 sections: Problem, Solution, Next Steps"
• Section order: "Output must follow this order: Background → Analysis → Recommendation"
• Naming rules: "Each section header must start with a verb"
• Structural templates: "Every feature spec follows: User Story → Acceptance Criteria → Edge Cases → Dependencies"
• List specifications: "Use numbered lists for steps, bullet points for options"
• Table requirements: "Competitor analysis must be a table with columns: Company, Feature, Pricing, Differentiator"

Format constraint in practice — the PRD outline:

Format Constraint:
- Exactly 5 sections: Problem Statement, Success Metrics, User Stories,
  Technical Constraints, Release Plan
- Problem Statement is exactly 2 sentences
- Success Metrics is a 3-row table: Metric, Current, Target
- User Stories follow the format: "As a [role], I want [action] so that [outcome]"

Now you can check: 5 sections? Yes/No. Problem Statement is 2 sentences? Yes/No. Every user story follows the template? Yes/No.

Format constraints are the scaffolding. Get them right, and the content has nowhere to go but into useful structure.

Our constraint-based prompting guide goes deeper on format, quality, and scope constraint categories with more PM-specific examples.

Quality constraints define standards the output must meet. They answer: "How do I know this is good enough to use?"

The key insight: quality constraints must be evals-ready. That means they double as your review checklist. You do not re-read the output and "get a feeling." You run down the list and check boxes.

Quality constraints for PM outputs:

The banned word list — a PM's quality starter kit:

delve, unlock, leverage, robust, elevate, empower, seamless, transformational,
streamline, optimize, synergy, holistic, cutting-edge, best-in-class

Copy that list into every prompt where tone matters. It catches 80% of AI-voice problems before you read a single sentence. When you're ready to scale, check out our 15 battle-tested PM prompts — every one ships with quality constraints built in.

Quality constraints are where the framework separates from conventional "prompt tips." Tips are vague. Constraints are binary. "Write clearly" is a tip. "Every paragraph is 3 sentences max" is a constraint.

Scope constraints define what the model should NOT do. They answer: "Where does this output stop?"

This is the most overlooked constraint category — and the one that prevents the most damage. AI models are completion engines. Given an open field, they will complete it. Scope constraints tell the model where the field ends.

Scope constraints that prevent PM disasters:

• "Do not invent metrics. If data is unavailable, write '[DATA NEEDED]'." — Prevents hallucinated numbers in your stakeholder presentation.

• "Do not propose solutions. Identify problems only." — Critical for discovery-phase prompts where you want analysis, not premature feature ideas.

• "Do not reference teams, people, or company names not in the input." — Prevents the model from fabricating context.

• "If the input does not contain enough information for a section, leave it blank — do not guess." — The polite way to say "I'd rather have a gap than a lie."

• "Do not use first-person plural ('we,' 'our,' 'the team') unless the input identifies who 'we' is." — Prevents the model from speaking for your organization.

Scope constraint in practice — the competitor analysis prompt:

Scope Constraints:
- Analyze only the 3 competitors named in my input
- Do not add competitors based on your training data
- If a data point is unavailable, mark it "Unknown" — do not estimate
- Do not recommend which competitor to copy or avoid
- This is a factual analysis, not a strategy document

Without scope constraints, the model will happily add a fourth competitor, estimate that competitor's pricing, and end with a recommendation paragraph that sounds authoritative but is entirely made up.

This is the most common failure mode I see from PMs new to AI. They add format and quality constraints, get a polished output, and don't notice the model invented two data points. Scope constraints are your guardrails. For more on what AI consistently gets wrong in PM documentation, see our 10 tested PM prompts — each one includes scope boundaries that prevent the most common failures.

You do not need to write new constraints for every prompt. The highest-leverage PM activity in AI is building a constraint library — reusable constraint blocks for your recurring tasks.

Here's how to start, organized by PM task category:

Weekly Status Reviews

FORMAT: Exactly 4 sections — Shipped, Blocked, Learned, Next Week
LENGTH: Each section 1-3 sentences. Total under 250 words.
PROHIBITION: Zero banned AI words (see list)
INCLUSION: Every Shipped item has a metric or date
ACTIONABILITY: Blocked ends with "Decision needed:" or "Next step:"
SCOPE: No speculation about items not in my inputs

PRD Sections

FORMAT: User Story → Acceptance Criteria → Edge Cases → Dependencies
LENGTH: Each user story is 1-2 sentences. AC is bullet list.
INCLUSION: Every story references at least one persona from the input
PROHIBITION: No implementation details (language, framework, architecture)
QUALITY: All acceptance criteria are testable (can be verified by QA)
SCOPE: Do not add user stories beyond the scope described in the problem brief

Stakeholder Updates

FORMAT: TL;DR (2 sentences) → Context → Decision Required → Timeline
LENGTH: Entire update under 150 words
PROHIBITION: No internal tool names or engineering jargon
INCLUSION: Timeline must include a specific date, not "next week" or "soon"
QUALITY: A stakeholder who skipped all meetings this week should understand this update
SCOPE: Do not assign blame or speculate about team capacity

User Research Synthesis

FORMAT: Theme → Evidence Count → Representative Quote → Implication
INCLUSION: Representative quote uses the customer's actual words from the input
PROHIBITION: Do not editorialize quotes ("the customer expressed frustration")
QUALITY: Every theme is supported by at least 2 data points from the input
SCOPE: Do not propose solutions — themes and implications only

Competitive Analysis

FORMAT: Table — Company, Feature, Pricing, Differentiator, Source Date
INCLUSION: Source Date must reference when the data was collected
PROHIBITION: No "probably," "likely," "estimated" unless marked as assumption
QUALITY: At least 3 differentiating factors identified per competitor
SCOPE: Analyze only competitors named in the input

Save these blocks. Store them in a Claude Project, a Notion page, or a text file. When you need a weekly review, paste the block. When you need a PRD section, paste the block. Each time you use them, tweak one constraint to make it tighter.

Over a month, your constraint library gets sharper. Over a quarter, you're spending zero time writing prompt structure and all your time on the actual thinking.

Constraint Density Rule: Target 5-7 constraints per prompt. Fewer than 3 and you're back in vague territory. More than 10 and the model starts dropping constraints — which is worse than having fewer, because you won't know which ones it ignored.

If you want a structured way to build your first constraint library, here's the Constraint Builder Worksheet — a simple 4-step process.

Step 1: Pick a recurring task. Weekly review, PRD section, stakeholder update, competitive brief. Pick the one you do most often.

Step 2: Write your current prompt. Actually copy-paste what you type into Claude or ChatGPT today. Don't edit it. Be honest.

Step 3: Run it through the Constraint Gap Analyzer:

Step 4: Rewrite with 5-7 measurable constraints. Test it. Run the constraint checker: go down your list and mark each one PASS or FAIL. If all pass, the output is verifiably good. If any fail, adjust that constraint and re-run.

That's the entire method. No theory. No "AI whisperer" mysticism. Just: name what you want, make it binary, check if it passed.

When Constraints Alone Aren't Enough

The MEASURABLE CONSTRAINTS framework gives you control over AI output quality. But constraints work best when combined with two other practices: domain language engineering (teaching the AI your company's specific vocabulary) and prompt chaining (breaking complex PM tasks into sequential AI calls). Those are covered in the full course.

Want to go deeper? The AI-First PM course has 10 modules, 33 sessions — you build your own AI workflows, not just read about them. Module 1 is entirely dedicated to prompt architecture, including the full MEASURABLE CONSTRAINTS system, domain language engineering, and building your own prompt grader.

Explore the AI-First PM Course →