Problem-People-System (PPS)
Diagnose a systems request by problem and people first, never jump straight to the tool.
- Difficulty
- Easy
- Time to result
- ~days to results
- Steps
- 3
- Confidence
- 95%
PPS is Austin Hay's diagnostic order-of-operations for any tooling or systems request. When someone brings a challenge, resist the instinct to solve it with a tool. Instead work backwards: name the problem, identify the people involved, and only then design the system. It prevents automating the wrong thing and building solutions nobody needed.
Origin
Coined by Austin Hay, head of marketing technology at Ramp, from his martech consulting and Reforge teaching. He uses it at Ramp and in every consulting engagement.
Core principles
- 01People jump straight to the system because it feels like action; that is where mistakes are made.
- 02A tool is only meant to solve a problem, so the problem must be defined before the tool.
- 03Understanding the people surfaces confounding factors that change whether you should automate at all.
- 04Once problem and people are clear, designing the system becomes easy.
How to run it
- 1
Name the problem
State the discrete issue the requester is actually trying to solve, in their words, before touching any tool. Example: a sales manager wants to stop a painful manual onboarding process every time they hire.
Pro tip Watch for requests phrased as a system action ('just give me admin permission to the tool') and translate them back into the underlying problem.
- 2
Identify the people
Map everyone the problem touches and what each needs. Does the sales manager need CRO permission? Do sellers need training? Is there a confounding factor that means you should NOT just automate this?
Watch out Skipping this step is how teams automate a process that should not have been automated because a hidden stakeholder or constraint was missed.
- 3
Design the system
Only now choose or build the system solution. With the problem and people understood, the correct tooling and configuration usually becomes obvious.
In the wild
A sales manager asks to remove the pain of onboarding new hires. Applying PPS, Hay first defines the problem (repeated manual onboarding), then the people (does the manager need CRO permission, do sellers need training, is there another confounding factor), before deciding what to automate.
→ Understanding people and problem first reveals whether automation is even appropriate, and makes the eventual system design straightforward.
Common mistakes
Jumping straight to the system
Most people skip problem and people and immediately ask for a tool or admin access, which leads to automating the wrong thing or granting risky permissions to solve a problem that was never properly defined.
Is it for you?
Best for
Marketing technologists, product-ops, and systems owners fielding constant 'can you just set up this tool' requests inside a growing company.
Not ideal for
Trivial, low-stakes requests where the problem, people, and solution are already obvious and unambiguous.
From the transcript
“then there's this PPS framework that I I talk about a lot which is problem people and system so whenever there's a challenge that comes…”
“usually because people just jump straight to the system they're like hey there's this problem I just need to solve it with the tool”
“once you have an understanding of the people and the problems that you're trying to solve then it's really really easy to design the system…”
From the episode
The ultimate guide to Martech
Austin Hay (Reforge, Ramp, Runway)