How do I define strategic requirements to solve problems at work?

When you’re struggling to finish a task, improve an experience, or solve a problem, ideally, the same struggle wouldn't be repeated.

You pause and ask yourself:

"What’s causing this issue? What needs to change?"

Photo by Vitaly Gariev on Unsplash

That’s problem framing.

It’s the process of turning scattered observations into clarity, direction, and actionable insight — making sense of all the information you’ve gathered.

The answers don’t appear right away, but framing the problem gives you the strategy to break down complexity into something manageable.

Problem framing is the skill of defining what’s actually wrong, not just what’s visible on the surface.

Problems can also be messy. They can look like blockers or resource gaps.

So, how can you make sense of all the information?

Photo by Vitaly Gariev on Unsplash

You start by identifying the problem in plain language and asking what outcome is being disrupted.

Examples of Problem Framing Questions:

• What is happening?

• Why does it matter?

• Who is affected?

• What outcome is blocked or at risk?

How Problem Framing Takes Shape

Defining a problem forms through patterns.

As you gather insights (user feedback, operational data, observations, conversations), information clusters start to form.

Some pain points repeat while others vary wildly across teams. Some even signal deeper issues.

Think of this like organizing puzzle pieces:

Through this practice, you'll find:

• Signals (patterns that appear consistently)

• Noise (details that don’t define the problem)

• Gaps (missing information that shapes understanding)

Once the pieces start forming a picture, you can better define the problem.

Photo by Campaign Creators on Unsplash

Example Pt 1

A team’s new-hire onboarding consistently misses critical steps:

• Equipment arrives late.

• Access permissions aren’t set.

• New hires report confusion about first-week priorities.

Managers use different checklists or no checklist at all, which causes repeated delays and extra work.

Instead of:

1. “People forget steps.”

2. “Equipment is late.”

3. “Managers do things differently.”

This problem can be reframed to:

1. What needs to be true for onboarding to go smoothly every time?

Identifying Signal, Noise, and Gaps in the Example

Now, apply problem framing to define what matters.

Signals (patterns that point to the real problem)

• Critical onboarding steps are consistently missed.

• New hires experience confusion during their first week.

• Delays and rework happen across multiple teams.

These signals repeat across people and situations, indicating a systemic issue.

Noise (details that don’t define the core problem):

• Which specific piece of equipment is late.

• Which manager forgot which step.

• Individual explanations for why a task wasn’t completed.

These feel urgent, but don’t explain why the problem keeps happening.

Gaps (what’s missing and needs clarification):

• Is there a shared definition of a “successful onboarding”?

• Who owns each step of the onboarding process?

• What information or tools do managers need to execute onboarding consistently?

Photo by Vitaly Gariev on Unsplash

Why This Matters

When signals, noise, and gaps are clearly separated, the problem becomes easier to define.

Late equipment or forgetful managers aren't the core issue. The absence of a clear, shared onboarding system is. By fixing this, we can ensure critical steps happen every time.

Sometimes an issue looks isolated until you discover it’s part of a larger system.

This is where interactions and structure come into play:

• Interaction — how one issue influences another.

• Structure — whether problems connect, overlap, or compete.

Ask:

“Does this issue change or trigger another?” → That’s interaction.

“Can both issues exist at the same time?” → That’s structure.

Together, they help determine whether there are:

• Independent problems

• Shared root causes

• Mutually exclusive constraints

• Multiple overlapping issues that feed one symptom

Photo by UX Indonesia on Unsplash

Once the problem is clear, you can define what’s needed.

There are 4 types of requirements to consider.

Types of Requirements

1. Functional → What the solution must do

2. Operational → How it must perform in real workflows

3. User → What people need, expect, or struggle with

4. Constraint → What must not change (budget, tools, compliance)

Example Pt 2

You’re tasked with redesigning the onboarding process to eliminate delays, rework, and duplicate requests.

From earlier problem framing, one issue stands out: Onboarding data is entered manually across multiple systems, creating inconsistencies and missed steps.

For onboarding to work every time, the following must be true:

Functional Requirements

• New hire information is entered once and used across all onboarding systems.

• Equipment orders and system access are automatically triggered from the same data.

Operational Requirements

• One standardized onboarding checklist governs when and where data is entered.

• Each data entry step has a clearly assigned owner.

User Requirement

• New hires and managers receive confirmation that the required information was successfully submitted.

Constraint Requirement

• The process works within existing HR and IT systems and complies with security policies.

Real-world problems don’t live in neat categories.

Two issues can happen side by side but not affect each other. Sometimes these issues can collide, and other times, they coexist and shape the environment together.

To group these issues, there are three ways to classify problems: Independent, Exclusive, and Inclusive.

Independent Problems

Two issues that don’t influence one another.

Example: Slow Wi-Fi at HQ doesn’t affect missing documentation in a shared drive. They both operate independently of each other, with no interaction.

Exclusive Problems

If one situation is true, the other cannot be.

Example: If a new employee's contract was never signed, it can't simultaneously be “pending approval.”

If condition A if true, condition B is impossible. If condition B is true, condition A is impossible.

Inclusive Problems

Problems that coexist and shape each other.

Example: Low staffing + unclear process documentation. Both can happen. Both exacerbate each other. Both problems coexist and amplify each other.

Example Pt 3

As you're developing the new onboarding process, you come across the old onboarding rules and requirements.

You discover the patterns when you compare the documents to what hiring managers have reported to you:

1. The new hire equipment is late, not because of the vendor, but because no one knows the correct order window.

2. IT access is missing because managers notify IT at different times.

3. Checklists vary because everyone keeps separate versions.

These problems are inclusive because they affect each other and stem from unclear ownership. This means that to improve the onboarding processes as a whole, we will need a solution that addresses the unclear ownership.

When One Insight Changes Everything

New information can shift how you define a problem.

This is called conditional understanding, when framing adjusts when conditions change. This can also be called reframed understanding.

Example:

During onboarding, new employees repeatedly submit duplicate requests for equipment and software access.

At first glance, it looks like a behavior issue:

• New hires aren’t following instructions.

• Requests are being submitted multiple times.

• IT and operations teams are doing unnecessary rework.

So the initial assumption becomes: “People aren’t paying attention.”

Photo by Vitaly Gariev on Unsplash

The New Insight

You later discover that the confirmation email for submitted requests sometimes fails to send.

From the new hire’s perspective, they:

• Submit a request.

• Receive no confirmation.

• Assume it didn’t go through.

• Submit the request again.

This new insight changes the problem entirely.

A phone buzzing with a notification when a request is submitted represents a new, context-changing behavior.

That’s how insight becomes action.

The Logic Behind Better Decisions

Frameworks don’t guarantee perfect decisions but they do help you reason through them.

You’re using problem framing whenever you:

• Compare priorities → Which issue blocks the most value?

• Manage risks → What happens if we don’t fix this?

• Plan solutions → What must be true before a fix works?

• Avoid costly rework → Did we confirm the right problem?

Photo by Jakub Żerdzicki on Unsplash

Example Pt 4

Based on the information, overlaps, and requirements, you design the onboarding process, starting with small targeted actions.

Solutions

1. Create a single shared onboarding checklist stored in a central place.

2. Add a mandatory 10-day equipment order buffer.

3. Assign one owner for IT setup, removing variation across managers.

4. Add a “Ready for Day 1” confirmation step so nothing is missed.

These solutions address the real insight: the old onboarding process failed because ownership was unclear.

By designing solutions that target the underlying requirements, you save time and energy while turning a chaotic workflow into a consistent, manageable process.

Defining strategic requirements and how they transform information is a skill at the heart of many fields.

Shifting from “What’s happening?” to “What needs to be true?” turns repeated problems into purposeful solutions — and, more importantly, saves you time and energy.

Photo by AbsolutVision on Unsplash

Ready for the next step?