Framework vs. Process: Why the Distinction Actually Matters
I see these terms used interchangeably all the time in engineering organizations. I do it too.
In my Pierce the Design Fog’s glossary, I define the ADEPT Team Framework as “a process for team collaboration during concept development.” But throughout the book, I call it a framework. So, which is it?
The truth is: it’s both. And that’s actually the point.
Here’s what I mean
A process is a prescribed series of steps you follow to get from A to B. It’s sequential, often documented with specific methods, and usually has clear inputs and outputs. Think: your design review process with its required documentation and sign-offs, your change management process with specific approval gates.
A framework is a structure for thinking. It’s a set of principles, phases, or organizing concepts that guide your work without dictating exactly how you do it. Frameworks give you the “what to consider” without rigidly prescribing the “how.”
You already know frameworks, you just might not call them that
Stage-Gate is a framework. It gives you phases (stages) and decision points (gates), but doesn’t prescribe exactly how you do the work within each stage. That’s why different organizations implement Stage-Gate very differently. Some have 3 gates, some have 7; documentation requirements vary wildly. It’s a framework.
Agile is a framework. It gives you principles and ceremonies, but teams adapt how they execute. That’s why you have Scrum, Kanban, SAFe, and dozens of other implementations. They’re all working within the Agile framework but with different specifics.
But here’s the key: Within Stage-Gate, you might have very specific processes. ”Our Gate 3 review requires these 7 documents in this format, reviewed by these 5 people.” Within Agile, your team might have a specific process for daily standup. ”Every morning at 9am, these 3 questions, under 2 minutes each.”
Frameworks contain processes. Processes live inside frameworks. Just like ADEPT.
ADEPT lives in the middle ground
Align-Discover-Examine-Prioritize-Teamwork gives you a repeatable sequence, but within each phase, you have flexibility in how you execute:
- Align on a goal for your meeting—but you choose how
- Discover ideas—I promote brainwriting, but other discovery methods work too
- Examine those ideas for common understanding—format is flexible
- Prioritize through multi-voting or rating scales—you pick what fits
- Teamwork follow-up like notes and tracking—you decide your documentation approach
And here’s the framework flexibility in action
Sometimes ADEPT looks like A-DEP-DEP-T—you Align once, then cycle through Discover-Examine-Prioritize multiple times for items related to the same goal using the same priority criteria.
Sometimes it’s A-DDD-EPT—you need multiple discovery prompts before you’re ready to examine and prioritize.
If ADEPT were a rigid process, that adaptability wouldn’t be possible. But because it’s a framework, you can flex the sequence to match what your team actually needs in the moment.
Yet I also provide specific instructions
In the book, I walk through activities with clear steps: “follow these steps to use the ADEPT Team Framework for X exercise.” That sounds like a process. And it is, for that specific exercise. You can have processes within a framework.
Think of it this way: ADEPT is the framework, or the overall structure and principles. Within it, you might follow a specific process for ideation, or a specific process for multi-voting. Those are repeatable, prescribed steps. But the framework tells you when to use them and gives you permission to adapt when needed.
The visual frameworks you use within ADEPT are pure framework territory:
- The Concept Space Model helps you map possibilities
- The Benefit-Impact Template organizes customer evaluation
- The Symptom-Impact Template structures problem analysis
- Process Flowcharts capture use processes
These are thinking tools, not step-by-step instructions.
The mistake I see most often?
Teams either over-process everything (47 prescribed steps for ideation that kill innovation) or reject all structure because “processes are bureaucratic” (chaotic meetings where nothing sticks).
The Design Fog lifts when you find the middle ground: enough structure to create rhythm and shared expectations, enough flexibility to adapt to what each project actually needs.
So, is ADEPT a process or a framework?
It’s a framework that contains processes and adapts like a framework should. The distinction matters because teams misuse both when they don’t understand the difference.
Call it what you want but be intentional about how you use it. Make sure your team understands when to follow prescribed steps and when to adapt guiding principles. That clarity is what actually lifts the Design Fog.