PPS Framework (Problem, People, System)

"Whenever there's a challenge that comes up, I like to first say: what's the problem? Who are the people involved? And what system does it impact? Usually because people just jump straight to the system." — Austin Hay

What It Is

PPS is a three-step diagnostic framework for approaching any technology or systems challenge. It forces you to understand context before jumping to solutions—a critical discipline when people naturally default to discussing tools and systems first.

The framework recognizes that most technology requests arrive as system requests ("I need admin permission" or "Can we implement X tool?") when the real question should be about the underlying problem and the people affected by it. By working through Problem → People → System in order, you make better decisions and avoid implementing solutions that don't actually address the root cause.

How It Works

Step 1: Problem

What is this person actually trying to accomplish?
What is the discrete issue they're experiencing?
Why does this matter to the business?
Is this a symptom or the root cause?

Step 2: People

Who are all the stakeholders affected?
Who needs to approve or be involved in the solution?
Are there competing priorities or political considerations?
What permissions or training do people need?

Step 3: System

Now that we understand the problem and people, what system changes could solve this?
What are the options (build, buy, configure, wait)?
What are the implications of each option?

How to Apply It

When receiving a request — When someone asks for tool access, a new integration, or a system change, pause. Don't start with "yes" or "no." Ask: "Help me understand the problem you're trying to solve."
Map the stakeholders — Before designing a solution, identify everyone affected. Does the sales manager need CRO approval? Do sellers need training? Is there organizational resistance you're not seeing?
Document the PPS analysis — For significant changes, write down your answers to each step. This creates accountability and helps communicate decisions to others.
Use PPS to push back — When you understand the problem and people, you can sometimes propose simpler solutions. "Based on what you're trying to accomplish, you might not need a new tool—you could just..."

Example Application

Request: "I'm a sales manager and I want to make it so that every time I hire somebody, I don't have to go through this tough process of onboarding my staff."

Problem Analysis:

The problem is manual, repetitive onboarding work
This costs the sales manager time on every new hire
It may also create inconsistent onboarding quality

People Analysis:

Does the sales manager need permission from the CRO?
Do the sellers need to be trained on any new system?
Are there IT/security considerations?
Is there a reason the current process exists?

System Analysis:

Only after understanding the above can you design the right system solution
Maybe it's automation, maybe it's a new tool, maybe it's a process change
The solution is now grounded in reality

When to Use It

Tool requests: Any time someone asks for new software or system access
Integration projects: Before connecting systems, understand what problem the integration solves
Stack audits: Review existing tools through the PPS lens—does each one solve a real problem for real people?
Debugging issues: When something goes wrong, PPS helps find root causes

Common Mistakes

Skipping to System: The most common error is immediately discussing tools and configurations
Incomplete People mapping: Missing a key stakeholder who later blocks the project
Solving symptoms: Not digging deep enough on the Problem to find root causes

Source

Guest: Austin Hay
Episode: "The ultimate guide to Martech"
Key Discussion: (01:06:16) Austin introduces PPS as his primary framework for technology decisions
YouTube: Watch on YouTube

Related Frameworks

Tools Solve Problems — The foundational philosophy that PPS operationalizes
Build and Buy — How to think about the System step once you reach it