09 EEM vs traditional
EEM vs Traditional
Planning-first models still fit sometimes. This one fits when making is cheap.
The Fundamental Shift
What Makes EEM Different
Traditional frameworks were designed for a world where execution was slow, expensive, and risky. They optimize for certainty before making. EEM is designed for a world where AI makes execution fast, cheap, and reversible.
Traditional Assumption
"Learning happens through planning before making."
Research, synthesis, and alignment upstream so delivery can proceed with confidence downstream.
EEM Assumption
"Learning happens through making."
Execution absorbs uncertainty. Build to learn. Multiple solution variants tested with real stakeholders.
Double Diamond
TraditionalThe Double Diamond (Discover Define Develop Deliver) is perhaps the most influential design framework of the past two decades. It brought rigor and shared language to design practice.
| Aspect | Double Diamond | EEM |
|---|---|---|
| Core Philosophy | Diverge then converge, twice. Separate discovery from delivery. | Execute to learn. Uncertainty collapses through making, not planning. |
| Execution Timing | Execution happens after certainty is achieved (Deliver phase). | Execution is the primary learning engine. Start making early. |
| Output Type | Single converged solution at each diamond's end. | Multiple solution variants for comparison and judgment. |
| Fidelity | Progressive fidelity: sketches wireframes mockups code. | Functional prototypes from the start. Fidelity matches learning need. |
| Stakeholder Engagement | Review concepts and mockups. | Review working software. Click through real flows. |
| Iteration Speed | Sprints or phases. | Hours. Multiple iterations per day. |
When Double Diamond Still Makes Sense
Double Diamond's emphasis on divergent thinking and problem framing remains valuable. Use it when you need deep research to understand a completely new problem space, when execution costs are genuinely high (hardware, physical products), or when your team is learning design thinking fundamentals.
Lean UX
TraditionalLean UX emphasizes hypothesis-driven design, rapid experimentation, and reducing waste. It's the closest traditional framework to EEM's philosophy—but with key differences.
| Aspect | Lean UX | EEM |
|---|---|---|
| Core Philosophy | Build-Measure-Learn cycles. Minimize waste through validated learning. | Execute to learn. AI makes execution cheap enough to explore multiple paths. |
| Hypothesis Testing | Test one hypothesis at a time through MVPs. | Build multiple solution variants simultaneously. Compare real options. |
| Minimum Viable | MVP: minimum features to test a hypothesis. | Multiple prototypes: enough to enable meaningful comparison. |
| Designer Role | Designers create artifacts (even if lightweight). | Designers direct AI agents. Don't create, orchestrate. |
| Execution Cost | Still assumes execution has meaningful cost. Minimize it. | Execution cost approaches zero. Maximize learning instead. |
EEM's Relationship to Lean UX
EEM can be seen as Lean UX evolved for the AI era. Lean UX's principle of validated learning remains, but the economics of execution have changed so dramatically that "minimum" is no longer the constraint—you can build multiple variants, not just one MVP.
Agile / Scrum
TraditionalAgile methodologies revolutionized software development by embracing change and iterative delivery. EEM shares Agile's values but operates at a different speed.
| Aspect | Agile/Scrum | EEM |
|---|---|---|
| Iteration Rhythm | Sprints (typically 2 weeks). | Continuous. Multiple iterations per day possible. |
| Planning | Sprint planning, backlog grooming, estimation. | Minimal planning. Start with variable inputs and execute. |
| Roles | Product Owner, Scrum Master, Development Team. | Product Strategist, Execution Designer, Design System Steward, Production Engineer. |
| Design Integration | Design often runs ahead of or parallel to development. | Design and development merged in Execute stage. |
| Definition of Done | Shippable increment at sprint end. | Multiple testable solutions ready for governance judgment. |
EEM + Agile
EEM doesn't replace Agile—it can operate within Agile teams. The Execute stage might happen during a sprint, with governance reviews at sprint boundaries. The key difference is that EEM's Execute stage produces multiple validated solutions, not a single increment.
Design Thinking
TraditionalDesign Thinking (Empathize Define Ideate Prototype Test) brought human-centered design to mainstream business. Its emphasis on empathy and problem framing remains valuable.
| Aspect | Design Thinking | EEM |
|---|---|---|
| Starting Point | Deep empathy research. Understand users before solving. | Variable inputs. Can start with research, strategy, or hunches. |
| Problem Definition | Define problem clearly before ideating solutions. | Problem understanding emerges through execution. Make to learn. |
| Prototyping | "Fail fast" with low-fidelity prototypes. | Build functional prototypes. Real code, not theater. |
| Testing | Test prototypes with users to validate. | Stakeholders engage with working software. Real feedback on real behavior. |
| Iteration | Iterate based on test feedback. | Continuous iteration. Multiple variants emerge, governance selects. |
What EEM Keeps from Design Thinking
EEM embraces Design Thinking's human-centeredness and iteration. The difference is where learning happens: Design Thinking assumes you learn through research and low-fidelity prototypes before building. EEM says you learn fastest by building real things and seeing how people actually respond.
At a Glance
Framework Comparison Summary
| Framework | Core Idea | Execution Assumption | Output |
|---|---|---|---|
| Double Diamond | Diverge then converge, twice | Execution is expensive; plan thoroughly | Single converged solution |
| Lean UX | Build-Measure-Learn cycles | Execution has cost; minimize waste | MVPs to test hypotheses |
| Agile/Scrum | Iterative delivery in sprints | Execution takes time; work in increments | Shippable increment per sprint |
| Design Thinking | Empathize, define, ideate, prototype, test | Learn through research before building | Validated concept |
| EEM | Execute to learn; governance selects | Execution is cheap; maximize learning | Multiple tested variants |
Fit Assessment
When Does EEM Fit?
EEM isn't always the right choice. Here's when it fits well and when traditional approaches might be better.
EEM Fits Well When...
- Building digital products (web, mobile, software)
- Teams comfortable with AI tools (Cursor, Windsurf, Bolt)
- Existing design system or component library
- Stakeholders who prefer seeing real things over mockups
- Need for speed—competitive pressure or tight timelines
- Culture that values learning over perfect planning
Consider Traditional Approaches When...
- Physical products where prototyping is genuinely expensive
- Completely new problem space requiring deep research
- No design system—brand not yet codified
- Team uncomfortable with code or AI tools
- Highly regulated environments requiring documentation-first
- Stakeholders who need extensive documentation before deciding
Best of Both
Hybrid Approaches
EEM doesn't have to be all-or-nothing. Here are ways to combine it with traditional approaches.
Research EEM Execute
Use traditional research methods to generate inputs, then switch to EEM for rapid execution. Best when entering a new market or user segment.
EEM within Sprints
Run EEM's Execute stage within Agile sprints. Use sprint planning for inputs, EEM for execution, and sprint reviews as governance gates.
Progressive Adoption
Start with one team or project using EEM while others continue traditional approaches. Expand based on results and team readiness.
Ready to Evolve Your Workflow?
Whether you're coming from Double Diamond, Lean UX, or Agile, let's discuss how EEM principles can enhance your team's approach.
Continue exploring: