DevTool Case Study · Erdeniz Tunc

01 Status

Assignment case study

This is an assignment case study for a data infrastructure / devtool product prompt. The research process, interviews, synthesis, and positioning work are real. The product is not a live client engagement or shipped product, and there is no launch, adoption, usage, or business impact claim.

02 Summary

This case study shows how I turned customer research into positioning and messaging for a technical data infrastructure product.

The assignment was to find 10 companies that could use the product, explain why they were good fits, and design a landing page. Instead of jumping straight into visual design, I started by interviewing people doing the actual data work.

From 5 structured interviews and 5 desk-researched companies, I mapped 3 repeated pain clusters, separated 4 ICP segments, and translated customer language into landing page messaging and UX decisions.

Devtool research process from customer interviews to positioning and landing page decisions — ProcessThe work moved from customer interviews to pain clusters, ICP segmentation, and positioning decisions.

03 Problem

The product promise was clear on paper: unify fragmented data infrastructure across ingestion, orchestration, transformation, and quality. The unknown was whether customers actually cared about that promise.

For technical products, weak positioning usually starts when teams describe what the product technically does instead of what customers are trying to escape. The useful output was not a generic landing page; it was evidence-based positioning built from real customer language.

04 Riskiest Assumption

What needed to be validated

The riskiest assumption was that a unified data platform would matter as a category-level promise. I needed to find pain specific enough that the solution became obvious, and language sharp enough to become positioning.

05 My Role

Research design
Structured the interview flow around current workflows, breakpoints, tools, and workarounds.
Customer interviews
Ran 5 interviews with data engineers, data scientists, analysts, and product/data team leads.
Pattern synthesis
Grouped raw interview notes into repeated pain clusters and segment-specific language.
ICP analysis
Validated patterns against 5 additional companies using public research signals.
Messaging translation
Turned research into positioning, value propositions, and landing page UX decisions.

06 Research Flow

Phase 1: qualitative interviews
Talk to people doing the work and ask how their data workflows actually break.
Phase 2: theoretical ICP analysis
Research additional companies through LinkedIn, websites, product pages, and public positioning signals.
Phase 3: design translation
Convert customer language into segment-specific messaging, page structure, and UX decisions.

07 Interview Findings

The strongest insight came from customer language. One data engineer described their stack as custom ingestion plus Airflow plus dbt: three tools, three maintenance burdens, and three points of failure.

That became the first major pain cluster: fragmented infrastructure. Other interviews surfaced reactive data quality, where teams only discovered bad inputs after dashboards broke, and custom ETL overhead, where every client or use case required new transformation work.

Fragmented infrastructure
Teams were stitching together ingestion, orchestration, transformation, and quality across separate tools.
Reactive data quality
Bad inputs were discovered after they reached dashboards, customers, or production analysis.
Custom code overhead
Teams were writing bespoke ETL and transformation logic for each client, schema, or workflow.

08 ICP Segmentation

The 10-company analysis produced four useful ICP segments. The same product could be relevant to each segment, but not through the same story.

Mobile Gaming
Lean teams need production-grade analytics without hiring more data engineers.
FinTech and RegTech
Reliability, governance, lineage, and blocking quality controls matter more than speed alone.
AI and SaaS
Custom ETL, mixed SQL/Python workflows, and schema changes create repeated operational bottlenecks.
E-Commerce and Logistics
Fragmented tools, manual exports, inventory sync delays, and operational reliability drive urgency.

09 Messaging Decisions

Value-first hero
Lead with the customer outcome: reliable data, faster deployment, and less operational complexity.
Quantified proof
Use specific claims like cost reduction, faster insights, and less tool sprawl instead of vague speed and reliability copy.
Segment-specific tabs
Let FinTech see compliance, Gaming see analyst enablement, AI/SaaS see mixed workloads, and E-Commerce see reliability and cost savings.
Progressive disclosure
Keep the top-level story simple, then expose technical depth for buyers who want implementation detail.
Pain-point empathy
Describe the current broken workflow before introducing the product as the fix.
Trust signals
Place proof points where they answer specific buyer concerns around compliance, quality, and operational reliability.

Devtool landing page hero section focused on reliable data and reduced complexity — Value-first heroThe hero leads with customer outcomes instead of product mechanics.

Devtool landing page quantified claims section with cost reduction and faster insights — Quantified claimsSpecific numbers make the promise easier to evaluate than generic benefit copy.

Devtool landing page sector-specific personalization tabs for different customer segments — Segment tabsDifferent customer segments get different proof and language for the same product.

Devtool landing page progressive disclosure section showing simple steps with deeper technical detail — Progressive disclosureThe page stays simple at first glance while still giving technical buyers depth.

Devtool landing page pain point empathy section describing fragmented tools and maintenance burden — Pain-point empathyThe page mirrors the broken workflow before introducing the solution.

Devtool landing page footer trust signals for compliance, quality controls, and reliability — Trust signalsProof points answer the buyer concerns that came out of the research.

10 What This Proves

Research before design
I can resist premature design work and use interviews to discover what the page should actually say.
Customer-language positioning
I can turn raw customer phrasing into sharper messaging instead of sanitizing it into generic product copy.
Segmented GTM thinking
I can separate customer types by pain, urgency, and buying logic rather than forcing one message onto everyone.
UX from evidence
I can connect design choices, such as tabs and progressive disclosure, back to specific research findings.

Get in touch →See all work →

Previous case

Optifeed Product Development Model →

Back to

All work