Case Study 01 · Product Manager · B2B SaaS
Sprint Reporting Automation
"From 3.5 hours of manual work to 20 minutes — every two weeks."
❌ Before DeDeDe
- 3–3.5 hours per sprint to write the review
- Manually copy-pasting from Jira to Notion
- Inconsistent format every sprint
- Often drafted the evening before
- Couldn't delegate — "only I know how"
✅ After DeDeDe
- 20 minutes per sprint — 90% reduction
- Automated export → transform → draft pipeline
- Consistent structure every time
- Ready by Tuesday morning automatically
- Any team member can run it
The Workflow
Context: Joris is a senior PM at a 60-person B2B SaaS company. His team runs two-week sprints and he's responsible for producing a sprint review document shared with the full product department (3 teams, ~25 people). The document includes: a narrative summary, a list of shipped items with impact notes, blockers and their resolutions, and a "what's next" section.
Before DeDeDe, Joris would spend 3–3.5 hours per sprint: half pulling data from Jira, half writing. The output was good, but wildly inconsistent — the format drifted sprint by sprint based on what felt important that week. Stakeholders started asking for a standardised format. That made it take even longer.
How Joris Applied the DeDeDe Method
Step 1 · Deconstruct
Breaking the Workflow to Its Atoms
Joris mapped every action in his sprint review process: what data he pulled (ticket titles, story points, labels, acceptance criteria, comments), what decisions he made (what counts as "shipped", how to group related items, what qualifies as a blocker), and what the output needed to contain. He identified 4 distinct data inputs and 5 structural sections in the final document.
Key insight from the Deconstruct phase: 70% of what he wrote was deterministic — it could be specified in rules. Only 30% required genuine editorial judgment.
Step 2 · Design
Building the Automation Blueprint
Joris designed a three-stage automation blueprint: (1) Data extraction — pull all completed tickets from the sprint in CSV format, (2) Transformation — apply classification rules to group tickets by feature area and flag any with unresolved comments as potential blockers, (3) Document generation — feed structured data into a narrative template that outputs the five-section format stakeholders expected.
The blueprint was written in plain language — no tool-specific syntax. It specified exactly what inputs, transformations, and outputs each stage required.
Step 3 · Decouple
Making It Tool-Independent
The implementation used Jira's CSV export (standard feature, not an API) and a lightweight AI prompt sequence that operated on the structured CSV data. The key decoupling decision: the AI instructions were written to work on tabular data in any format — not Jira specifically. When the company considered switching to Linear six months later, Joris confirmed the automation would work with Linear's CSV export without changes to the blueprint.
📊 Result
Sprint review documentation time dropped from 3.5 hours to 20 minutes. Annualised: 79 hours saved per year — the equivalent of two working weeks. The format became consistent for the first time, reducing stakeholder back-and-forth by an estimated 40%. Three team members can now run the automation independently.
Case Study 02 · VP Product · Scale-Up (Series B)
Stakeholder Update Generation
"My board deck used to take me half a Sunday. Now it's done by Friday morning."
❌ Before DeDeDe
- 4–5 hours/week on executive product updates
- Pulling data from 5 different sources manually
- The "Sunday afternoon tax" every week
- Different narrative every week — hard to compare
- Couldn't delegate — required VP-level context
✅ After DeDeDe
- 45 minutes to review + send — 85% reduction
- Automated data aggregation from all 5 sources
- First draft ready every Friday 07:00
- Consistent structure — easy to track week-over-week
- EA can run the pipeline and flag anomalies
The Workflow
Context: Lena is VP Product at a 90-person fintech scale-up. She reports directly to the CEO and is expected to send a weekly product update to the leadership team every Friday afternoon. The update covers: product OKR progress, key decisions made this week, shipping milestones hit, blockers requiring leadership attention, and a brief "coming next week."
The challenge: the data for this update lives in five places — a roadmap tool, a metrics dashboard, a project management system, a decision log (a shared Notion doc), and her own notes. Pulling it all together required context that only Lena had. The result was a recurring Sunday afternoon commitment that burned 4–5 hours and crowded out strategic thinking.
How Lena Applied the DeDeDe Method
Step 1 · Deconstruct
Identifying the Real Data Requirements
Lena's first discovery during Deconstruct: most of the "VP context" she thought was required was actually data retrieval and formatting — not judgment. She mapped each section of the update to its source, identified the transformation rules that turned raw data into executive narrative, and found that only one section (the "decisions made" section) genuinely required her editorial input.
She also discovered that half her time was spent on data consistency — making sure numbers matched across the five sources. This was a perfect candidate for automation.
Step 2 · Design
The Aggregation-Plus-Narrative Blueprint
Lena's blueprint had two stages: an aggregation stage (pull structured data from each source into a single "weekly data package") and a generation stage (transform the data package into the five-section narrative using consistent format rules). The aggregation stage was designed to surface inconsistencies automatically — if the roadmap showed 80% OKR completion but metrics showed 60%, the system would flag the discrepancy rather than silently choosing one.
Step 3 · Decouple
EA-Operable, Tool-Swappable
The critical decoupling decision: design the aggregation stage as a series of "copy this data into this template" instructions, not a technical integration. This meant Lena's EA could operate the first stage — copy-pasting structured exports into a standardised weekly template — while the AI handled the generation stage from the structured input. When the company switched metrics dashboards, only the export format in the template changed. The generation stage was untouched.
📊 Result
Weekly update time reduced from 4–5 hours to 45 minutes of review and editing. Lena describes the Sunday afternoon block as "gone from my life." The update quality improved — stakeholders noted the increased consistency and began using it as a reference document rather than a reading document. The EA now handles the aggregation stage, freeing Lena for strategic input only.
Case Study 03 · Product Manager · Consumer App
User Research Synthesis
"6 interviews used to take me a full day to process. Now I have a structured synthesis in 45 minutes."
❌ Before DeDeDe
- 6–8 hours to synthesise 6 interviews
- Notes scattered across Dovetail + personal docs
- Theme extraction took most of the time
- Results often too late to influence sprint planning
- Synthesis quality varied by how tired she was
✅ After DeDeDe
- 45 minutes per research batch — 87% reduction
- Standardised interview note format
- Automated theme extraction + evidence mapping
- Insights ready within 24 hours of last interview
- Consistent quality regardless of schedule pressure
The Workflow
Context: Priya is a PM at a 40-person consumer fitness app. She conducts 6–8 user interviews per research round and is responsible for synthesising insights into an "Insights Deck" shared with the product and design team. The deck needs to include: key themes across interviews, supporting evidence (quotes), implications for the product, and a prioritised list of insights by frequency and severity.
The synthesis process was consistently the bottleneck in her research cycle. Interviews would finish on a Thursday; the deck wasn't ready until the following Tuesday. Sprint planning was on Monday. Her insights almost always arrived a day too late.
How Priya Applied the DeDeDe Method
Step 1 · Deconstruct
Separating Observation from Interpretation
The key insight from Priya's Deconstruct phase was identifying the difference between two distinct tasks she had conflated: observation extraction (pulling specific quotes and behaviours from notes) and interpretation (deciding what themes they represent). The first task — pulling structured observations from raw notes — could be automated. The second — applying her product context to decide what matters — required her judgment.
She also identified that her note quality varied significantly between interviews, making automation unreliable. The Deconstruct phase revealed a pre-automation requirement: standardise her note-taking format first.
Step 2 · Design
A Three-Stage Synthesis Blueprint
Priya designed a three-stage blueprint: (1) Note standardisation — during each interview, she now uses a fixed note template (context, direct quotes, observed behaviours, her initial interpretation) that produces consistent, structured input; (2) Observation extraction — AI reads all standardised notes and outputs a structured list of observations tagged by category (friction point, delight, unmet need, workaround); (3) Theme clustering — AI groups observations by similarity, counts frequency, flags contradictions, and generates the first-draft insights deck with evidence attached to each theme.
Step 3 · Decouple
The Note Template as the Portability Layer
The clever decoupling decision: the standardised note template is the portability layer. Because all input goes through the same structured format, the AI instructions in stages 2 and 3 don't need to understand Dovetail, Notion, or any specific research tool. Priya moved from Dovetail to Notion to a simple Google Doc folder during the six months after the workshop — each time, the automation kept working because the input format hadn't changed.
📊 Result
Research synthesis time dropped from 6–8 hours to 45 minutes per batch. Insights now reach the team within 24 hours of the last interview — consistently making sprint planning. Priya reports an unexpected bonus: because the synthesis is faster and less draining, she now runs 40% more research rounds per quarter than before. The quality of her product decisions has measurably improved as a result.