Case Study
I built a team's first strategic framework — and it prevented a costly product mistake.
At InsideSales, I established a Jobs-To-Be-Done framework from scratch through site visits, cross-functional workshops, and sentiment analysis. The framework became the team's shared language for every product decision — including the decision to kill a standalone product before it wasted resources.
You can't design a fix for "clunky."
The ProblemNPS data
Users consistently described Playbooks as slow, clunky, and inefficient. But no prior strategic discovery work had been done. The team had complaints — not understanding.
To make changes that would actually resolve the inefficiency perception, I needed to understand who our users were and what they were trying to accomplish. Only then could I tie vague complaints to specific scenarios where the product was failing them.
From site visits to shared language
The MethodI partnered with a designer on contextual inquiries, observing reps at work using Playbooks. Then I facilitated a cross-functional workshop with customer success, product, engineering, and sales. We read hundreds of data points aloud, grouped them through affinity mapping, and refined JTBD statements until we had unanimity.
Physical synthesis, shared ownership
Workshop
Evolved JTBD map — affinity groupings with sticky notes showing user quotes and needs mapped to workflow stages.
"Keep My Records Timely and Accurate" — one of the highest-friction jobs, broken into sub-tasks with user verbatims.
Finalized JTBD flow — the rep's daily workflow from "Structure My Day" through task execution, contact, and record management. Refined until unanimous, then digitized.
Three jobs accounted for most of the pain.
Sentiment AnalysisI manually coded every data point by whether the associated job was being satisfied or not. Filtered to jobs with 10+ supporting data points:
Jobs with fewer than 10 data points excluded. "Prioritize tasks" had the most data points (28) and moderate satisfaction, suggesting a broad but not acute problem.
Where the product met needs — and where it didn't
Feature Mapping
Each card maps a JTBD to the Playbooks features that serve it. Dense cards = well-covered jobs. Sparse cards = gaps worth investigating.
Research that says "don't build this" is still valuable research.
What It PreventedThe Data App
InsideSales wanted to monetize its CRM data as a standalone product. Using the JTBD framework to scope the investigation, I ran concept research with sales reps. The research killed the product before it wasted engineering resources.
I tested a PM-designed concept for a standalone "Data App" with outbound prospecting reps. Five clear problems emerged:
- 1Divorced from the main product, it was seen as feature-poor and not worth buying separately.
- 2The information was redundant — reps could already find it in LinkedIn or ZoomInfo.
- 3Trust was too low — the existing data product had such poor reputation that a data-only product made reps hesitant.
- 4Privacy concerns — non-users were uncomfortable with "collective intelligence" sharing.
- 5The one promising element (org chart tool) still wasn't viable standalone.
I recommended killing the standalone Data App and redirecting toward a concept that incorporated the org chart idea within the existing product — which became a successful subsequent project. The JTBD framework gave the team a shared language to evaluate the proposal against user needs rather than internal enthusiasm.
A shared language for every product decision
Lasting Impact"What 'Job' is this feature meant to help with? And will it actually help them do their job?"
— The evaluation question I helped PMs and designers ask before every product or feature proposal
If we had a clear answer in existing research, we could jump straight into explorative design and testing. If we didn't, I helped the team understand the underlying problem first — which often led to deviations from the initial proposal and greater product adoption. The framework informed multiple subsequent projects and became the team's default evaluation lens.
Reflections
LearningsCross-functional ownership
When product, engineering, CS, and sales all participated in creating the JTBD statements — reading data points aloud, debating groupings, refining language — they owned the framework. It wasn't "the researcher's framework" imposed on the team; it was a shared artifact everyone had built together. That ownership is why it persisted across project cycles.
Physical artifacts create shared memory
The sticky notes, the printed data points, the wall-sized affinity maps — these created a tactile shared experience that digital-only synthesis doesn't replicate. Participants remembered specific data points and grouping debates months later.
What I'd change
I would have built a more systematic process for keeping the framework updated. The iterative evolution happened, but it was opportunistic — I updated the map when new research happened to touch relevant areas. A quarterly review cadence with the product team would have kept the framework more current and maintained its visibility in planning conversations.
The bigger lesson
Strategic research doesn't have to produce a feature recommendation to be valuable. The most durable output wasn't any single product decision — it was a shared language and evaluation framework that made every subsequent decision faster and better grounded. The JTBD map was used more often to challenge proposals than to generate them.