Introduction
Welcome back to our module on the PULPED framework for validating data solutions. In our last lesson, we navigated the critical topic of 'U' for Unintended Consequences. We learned that even practical solutions can cause harm by amplifying biases, creating negative feedback loops, or interacting with human psychology in unexpected ways. The key takeaway was the need for proactive discovery through methods like red teaming, stakeholder analysis, and monitoring counter-metrics.
Today, we move to the 'L' in PULPED: Logically Sound. This lesson is designed to help you master the learning outcome: Evaluate the logical coherence of a proposed solution, ensuring it directly addresses the problem defined by the SMART question.
A solution can be practical and have no negative side effects, but if it doesn't actually solve the core problem, it is a waste of resources. Logical soundness is the critical check that connects your proposed action directly to the problem you initially set out to solve. It ensures there is an unbroken chain of reasoning from the problem statement to the solution's expected impact.
1. The Foundation: A Well-Defined Problem
Before you can evaluate a solution's logic, you must be absolutely certain you understand the problem. A common failure point in data projects is developing a brilliant solution to the wrong problem.
To avoid this, we must resist the urge to jump to solutions and instead rigorously define the problem.
3 Problem Statement Examples & How to Write Your Own
To understand the importance of this first step, let's review a brief article from BetterUp. It explains what a problem statement is and why it must be established before solutions are considered.
Please read the following sections: Start with 'What is a problem statement?' to get a clear definition. Read the section 'When to use a problem statement' to understand its timing and purpose. Finally, review 'What are the 5 components of a problem statement?'. Focus on the 'five Ws' (who, what, when, where, why) as a framework for analysis. \nThese sections emphasize that a problem statement should be a clear, unbiased explanation of an issue, free of any proposed solutions.
The 'five Ws' framework is an excellent tool for moving from a vague feeling of "something is wrong" to a precise, actionable problem definition. Let's apply it.
Example: Bra Design
- Vague Problem: "Our bras don't fit well."
- Applying the 5 Ws for a Precise Problem Statement:
- Who is affected? Customers with small band sizes (under 34) and large cup sizes (DD+).
- What is the issue? The underwires dig into their sides, and the center gore (the piece between the cups) does not lie flat against the sternum. The desired state is a comfortable fit where the gore 'tacks' (sits flat).
- When does it occur? Persistently, as evidenced by customer service logs and return comments from the past year.
- Where is it occurring? Primarily in our full-coverage underwire styles.
- Why is it important? It drives a 40% return rate for this demographic, erodes brand loyalty, and leaves a valuable market segment underserved.
This detailed statement provides a solid foundation. A solution that doesn't address underwire shape or gore design for this specific demographic is not logically sound, no matter how clever it is.
2. Building the Logical Chain with "If...Then"
Once the problem is clear, we can map out the logic of a proposed solution. A powerful tool for this is the Logic Model, which uses a series of "If...Then" statements to connect actions to outcomes.
Your guide to using Logic Models
The concept of a Logic Model is explained well in this guide from the NHS. It breaks down how to think about programs in terms of a causal chain.
Please read these two key sections: In the 'What is Logic?' part, find the subsection titled 'If... Then'. This is the core concept for building a logical chain. In 'The Logic Model' part, read the subsection 'Principles'. This explains how all programs are 'theories incarnate' and how the 'If...Then' construct helps untangle this theory. \nFocus on how this structure forces you to articulate the expected cause-and-effect relationship at each step.
This "If...Then" structure creates a clear, testable hypothesis about how your solution will work. Let's build one for our second area of interest.
Example: Polyamorous Relationships
- SMART Question (from Module 1): "For a woman in a polyfidelitous relationship with three male partners, can we develop a shared digital calendaring tool that reduces scheduling conflicts by 50% over a three-month trial period, thereby increasing reported relationship satisfaction by at least one point on a 7-point Likert scale?"
- Proposed Solution: A specialized app that syncs four personal calendars, flags conflicts, and suggests alternative time slots.
- The Logical Chain:
- IF we provide resources (app development, server hosting), THEN we can perform activities (syncing calendars, running a conflict-detection algorithm).
- IF we perform these activities, THEN we can deliver outputs (a unified calendar view, automated conflict alerts).
- IF the partners use these outputs, THEN they will achieve the short-term outcome (fewer scheduling conflicts).
- IF scheduling conflicts are reduced, THEN we will see the long-term impact (increased relationship satisfaction).
Evaluating logical coherence means examining each link in this chain. Is it plausible? Are there any gaps?
3. Stress-Testing the Logic for Gaps and Flaws
A logical chain is only as strong as its weakest link. We must actively search for flaws in our reasoning. The same guide on Logic Models provides excellent tools for this.
Your guide to using Logic Models
Now, let's learn how to critique our own logic. This reading will introduce two methods for stress-testing your 'If...Then' chain.
Please read the following: Under 'What is Logic?', find the subsection 'So What? - Hypothesis and Theory'. Focus on the 'Five Whys' tool as a way to probe the core premise of your argument. Under 'Constructing the Model', find the subsection 'The Whole Model - Check and Refine'. The list of questions here (e.g., 'Does it flow reasonably well?', 'Are the inputs sufficient?') provides a fantastic checklist for finding gaps in your logic model. \nThese techniques move you from simply stating your logic to actively challenging it.
Let's apply these stress tests to our bra design example.
- Problem: Underwires dig in for small-band/large-cup customers.
- Initial Proposed Solution: "We will use a wider underwire for these sizes."
Stress Test 1: The "Five Whys"
This technique helps verify the problem's root cause, ensuring the solution is aimed at the right target.
- Why will a wider underwire help? Because it better accommodates a wider breast root, which is common in this body type.
- Why is that important? Because the current narrow wire sits on breast tissue, causing painful digging.
- Why are we using a narrow wire now? It's the industry standard we adopted for simplified sourcing.
- Why was that a bad decision? It prioritized supply chain ease over the anatomical needs of a key customer segment.
- Why is fixing the wire the right solution? Because it addresses the anatomical mismatch, which is the root cause of the discomfort.
The logic holds up. The solution is aimed at the correct root cause.
Stress Test 2: The "Check and Refine" Questions
This helps find gaps in the solution's implementation logic.
- Proposed Solution: "Implement a new manufacturing process using a wider, more flexible underwire for sizes 30-34 DD+."
- Question: Are the inputs sufficient to carry out the activities?
- The "input" is a wider underwire. The "activity" is putting it into a bra. Is the wire the only input needed?
- Logical Gap Identified: A wider wire has a different curve. Simply swapping it into a pattern designed for a narrow wire will cause other fit issues—the cup will likely gape or warp.
- Conclusion: The initial solution is logically incomplete. A coherent solution must include both sourcing a new wire and redesigning the bra patterns (cups, band, gore) to accommodate it. The logic "new wire -> better bra" was flawed because it missed a necessary intermediate step.
4. The Final Check: Alignment with the SMART Question
The ultimate test of logical coherence is simple: does the final "impact" of your logical chain directly satisfy the goal laid out in your original SMART question from Module 1?

Let's revisit our polyamory example:
- SMART Question: Reduce scheduling conflicts by 50% (Measurable) and increase relationship satisfaction (Relevant).
- Solution's Logical Chain ends with: "long-term impact (increased relationship satisfaction)."
- Coherence Check: The end of the logical chain directly aligns with the "R" in the SMART question. The short-term outcome (fewer conflicts) aligns with the "M". The solution is therefore logically coherent with respect to its stated goals.
If the SMART question had been about improving emotional intimacy, a calendar app would be logically unsound, as there's no plausible causal link between scheduling and intimacy. The solution must solve the right problem.
Conclusion
In this lesson, we dissected the 'L' in PULPED, focusing on Logical Soundness. We established that a coherent data solution forms an unbroken chain of reasoning that connects a well-defined problem to a desired outcome.
Key Takeaways:
- Logical coherence begins with a precise problem statement. Use frameworks like the "Five Ws" to move from vague issues to specific, actionable problems.
- Map your solution's logic using "If...Then" statements to articulate the causal chain from inputs and activities to outputs and impacts.
- Actively stress-test your logic. Use the "Five Whys" to confirm you're addressing the root cause and use checklists to find gaps or flawed assumptions in your solution's design.
- The final test is to ensure the ultimate impact of your logical chain directly addresses the goals laid out in your original SMART question.
Preview of the Next Lesson:
We have now confirmed our solution is Practical, considered its Unintended consequences, and verified it is Logically sound. Next, we will tackle the second 'P' in PULPED: Precedent-backed. We will explore how to find and evaluate evidence from past projects to determine if your proposed solution has a track record of success in similar contexts, thereby reducing risk and building confidence in your approach.