Strong positioning for devtool & technical products is is based on evidence from real customer interactions.
In this process for a data infrastructure product, I walk through how I moved from guessing to validation, and how I translated raw insights from customer interviews into concrete messaging, UX decisions, and a customer-centric landing page.
You can apply this framework if you are working on technical products, especially DevTools, where clarity and trust matter more than feature depth.
This is a practical guide to turning customer research into positioning and conversion-ready messaging.
- Introduction & Context The Assignment The assignment was “find 10 companies that could use a data infrastructure platform, explain why they’d be good fits, and design a landing page.”
Why I Started with Research, Not Design Most people make some guesses and then just jump straight into Figma and start designing. I first identified potential companies and started scheduling interviews. By the fourth day, I had something far more valuable than a website:
A clear understanding of who had which problems and how they described those problems in their own words, and I built my entire strategy around that.
- The Research Framework Two-Phase Approach Here’s what I knew: The platform unified fragmented data infrastructure (ingestion, orchestration, transformation, quality) into one tool. It promised speed, reliability, and reduced complexity.
Here’s what I didn’t know: Whether anyone actually cared about that.
The goal: Find pain so specific that the solution becomes obvious.
Phase 1: Qualitative Interviews (5 companies) Talk to people doing the actual work (data engineers, scientists, analysts) Map current workflows, pain points, workarounds Listen for language patterns Phase 2: Theoretical ICP Analysis (5 companies) Identify high-potential targets through desk research LinkedIn, company websites, product pages Look for signals that indicate pain Phase 3: Design Translation Turn customer language into UX decisions Create segment-specific value propositions Build conversion-optimized landing page 3. The Interview Process Interview Methodology I conducted five in-depth customer interviews. In each conversation, I followed the same flow:
“Walk me through your current workflow.” “What breaks?” “How do you fix it?” “What tools are you using?” These were not sales-like conversations. Instead of sounding like a door-to-door salesperson, the interviews were structured as natural discussions around day-to-day work, technology, recurring problems, and possible solutions. I intentionally left any mention of the product I was researching until the very end. The goal was to understand the customer.
Key Quotes & Pain Points Discovered The “Trainwreck” (Fragmented Infrastructure) Person 1, a data engineer at a travel tech company, gave me the quote that would become positioning gold:
“We use custom ingestion + Airflow + dbt. 3 different tools. It’s a trainwreck.”
Not “suboptimal.” Not “could be improved.” Trainwreck. That’s customer language. That’s what converts.
His team had built their own data ingestion platform, added Airflow for orchestration, added dbt for transformations. 3 systems. 3 maintenance burdens. 3 points of failure. When you need to modify a pipeline, you’re touching 3 different codebases. When something breaks, you’re debugging across 3 systems.
Reactive Data Quality Person 2, a data scientist at an AI company selling B2B analytics, described a different pain:
“Bad input causes extreme analysis results. I only discover issues when dashboards break.”
Think of it like this. Data just flows into the system with no checks at the start. Nothing stops it if it’s wrong. Everyone just hopes it’s fine. Then, hours later, someone notices something is off because a client dashboard shows numbers that make no sense.
For a company that sells analytics to customers, this isn’t just an internal bug or a technical inconvenience. If clients start seeing wrong data, they stop trusting the product. And once trust is gone, the business is at risk.
Custom ETL Overhead Person 3, building ML models for enterprise clients, had yet another bottleneck:
“We write custom ETL for every client. Data formats vary wildly. If an integration tool could solve the transformation part, that would be huge.”
Each client stores data differently. Different schemas, different formats, different sources. His team’s solution was to write custom transformation logic for every single client. Python scripts, SQL queries, Airflow DAGs. Not scalable and also not maintainable.
Manual Work & Infrastructure Burden Person 4, a digital marketing specialist in hospitality tech, represented non-technical users:
“I pull data from multiple sources, but it’s not 100% automated. Some platforms require manual extraction. I only know something’s broken when dashboards stop updating.”
Automated where possible, manual exports where necessary, manual fixes when things break. Reactive problem detection. The “just ask a data engineer” model doesn’t scale.
Person 5, a lead product manager of a data team from one health tech company, had solved automation but faced a different challenge:
Data quality was handled through Airflow scripts, but automation itself was never the real issue. The potential real cost came from maintaining the infrastructure around it. Scripts had to be owned, pipelines monitored, infrastructure managed, and failures debugged. Over time, engineering effort drifted away from business logic and toward simply keeping the system running.
- Pattern Recognition & Segmentation Three Pain Point Clusters 5 interviews. 3 distinct pain point clusters emerged:
Fragmented Infrastructure Reactive Data Quality Custom Code Overhead Pain Point 1 - Fragmented Infrastructure
Using 3+ separate tools (ingestion, orchestration, transformation) High maintenance and operational overhead Multiple points of failure Interviews: Person 1 (travel tech company), Person 5 (lead data PM) Pain Point 2 - Reactive Data Quality
No proactive validation Issues discovered only after reaching production/dashboards Manual intervention required Interviews: Person 2 (AI company), Person 4 (hospitality tech company) Pain Point 3 - Custom Code Overhead
Writing custom ETL/transformations for every client/use case Mixed SQL+Python workload requirements Not scalable Interviews: Person 3 (AI/ML company) The Desk Research Validation With three pain point clusters validated, I needed to test the pattern against companies I hadn’t interviewed. Five companies. Public research only. LinkedIn, company websites, product descriptions.
A property management SaaS company running predictive budgeting algorithms and billing error prediction caught my attention. Financial predictions based on data meant wrong data equals lost money and lost trust, a clear FinTech/RegTech fit where blocking quality controls and SOC2 certification would be mandatory, not optional.
A logistics company promising 99.8% order accuracy across multi-channel operations validated the E-commerce pattern. When your SLA is 99.8%, reactive data quality isn’t acceptable. One error breaks the promise. They needed proactive controls to block bad data before it reached operations.
A mobile gaming studio describing themselves as “data-driven dreamers” with a rapidly growing portfolio fit the Gaming/E-commerce segment perfectly. Small, distributed team needing production-grade analytics without hiring more engineers, the classic analyst enablement problem where self-service pipelines would unlock growth.
A fintech company offering securitization services with AI-powered risk assessment had SOC2 compliance mentioned prominently on their homepage. Zero error tolerance for financial data combined with regulatory requirements meant they’d pay premium pricing for built-in governance, RBAC, lineage tracking, and blocking quality controls.
An e-commerce company with an “always affordable pricing” strategy across eight product categories needed real-time pricing decisions. Fast access to inventory, sales, and competitive data was critical. They couldn’t wait days or weeks for new dashboards, 4x faster insights and removing engineering bottlenecks would directly impact their competitive advantage.
Mapping Pain Points to Customer Types These three pain points mapped to four distinct customer types.
Mobile Gaming companies obsess over pain point #1 (fragmented tools + operational costs) with emphasis on analyst enablement. FinTech & RegTech companies obsess over pain point #2 (reactive quality). AI & SaaS companies obsess over pain point #3 (custom code overhead). E-Commerce & Logistics companies obsess over pain point #1 (fragmented tools) with emphasis on operational reliability. 5. The ICP Segmentation Ten companies analyzed (5 interviews + 5 desk research). Four distinct customer segments emerged:
Segment 1: Mobile Gaming Small, distributed teams need production-grade analytics without hiring more engineers — the classic analyst enablement problem where deployment speed and cost efficiency unlock growth.
Segment 2: FinTech & RegTech When you’re handling financial data or regulatory compliance, “fast” is nice but “never wrong” is mandatory. Priority: Highest — premium pricing potential due to mission-critical reliability needs.
Segment 3: AI & SaaS Custom ETL for every client and mixed SQL+Python workloads create operational bottlenecks. Priority: Strong product fit for mixed workloads and automated transformations.
Segment 4: E-Commerce & Logistics High data warehouse costs, long deployment times, and manual operational overhead block growth. Priority: Volume opportunities — many companies fit this profile.
Priority & Value Prop Matrix Mobile Gaming Core Pain: High DWH costs eating revenue. Lean teams can’t afford dedicated data engineers. Weekly silent data errors break analytics.
Value Proposition: 88% DWH cost reduction. Data analysts deploy production pipelines without hiring engineers. New game setup in 20 minutes instead of days.
Impact: A mobile gaming company reduced DWH costs from $50k to $6k monthly while scaling from 2 to 8 games. Setup time: 20 minutes per game.
FinTech & RegTech Core Pain: Mission-critical data reliability with zero margin for error. Billing error tolerance is zero. Regulatory compliance nightmares. Schema changes break B2B customer integrations.
Value Proposition: Blocking quality gates at every step (ingestion included). SOC2 Type 2 certified. Private VPC & on-premises deployment for regulated environments. Automatic data lineage for compliance. Impact analysis prevents customer-facing breaks.
Potential Impact: A property management SaaS company relies on blocking quality gates for their billing error prediction engine. A fintech securitization company uses blocking quality gates to ensure RegTech compliance without manual audits.
AI & Custom SaaS Core Pain: Repeated custom ETL code for every client. Input data quality issues cause extreme AI outputs. Schema changes ripple into production models undetected, breaking customer metrics.
Value Proposition: Standardized SQL + Python mixed workloads eliminate ETL repetition. Automatic impact analysis flags schema changes before they break downstream. Quality checks validate AI inputs before training.
Potential Impact: An AI company standardized data pipelines across 50+ clients, reducing custom ETL by 90%. Another AI/ML company uses mixed SQL/Python workloads to combine analytics and ML in one platform.
E-Commerce & Logistics Core Pain: Scattered marketing data (Shopify, Stripe, Google Ads). Manual CSV uploads and script running. Inventory sync delays cost revenue.
Value Proposition: Powered by ingest tool (open-source): ingest 100+ sources with one command. Shopify, Stripe, Google Ads, PostgreSQL, MySQL, IBM DB2. No manual scripts, no CSV hell.
Potential Impact: A logistics company unified data across PostgreSQL, MySQL, and IBM DB2. An e-commerce company automated marketing analytics from Shopify + Google Ads. A fintech startup eliminated manual CSV workflows, achieving 4x faster insights.
- Translating Research Into Design This is where the fun part begins. Turning customer language into UX.
Design Decision 1: Value-First Hero Section The mistake most companies make: Leading with product features or company name.
What I did: Led with customer outcome.
Headline: “Reliable data. 10x faster, 90% less complexity.”
Why this works:
“Reliable” addresses Person 2’s pain (reactive quality in AI company) “10x faster” addresses deployment speed pain “90% less complexity” addresses Person 1’s “trainwreck” (travel tech company) Supporting copy: “Stop wrestling with fragmented tools” direct quote language from interviews.
Design Decision 2: Quantified Claims Bad copy: “Fast and reliable data platform”
Good copy: “88% cost reduction. 4x faster insights. 90% less tool sprawl.”
Why:
Specific numbers = verifiable claims “88% cost reduction” came from a real customer (from company’s case study sources) “4x faster” came from analyst enablement feedback “90% less tool sprawl” came from counting Person 1’s 3 tools → 1 platform (travel tech company) Design Decision 3: Sector-Specific Personalization The problem: Four segments don’t care about the same things.
The solution: Interactive sector tabs
Mobile Gaming, FinTech, AI/ML, E-commerce.
How it works:
Mobile Gaming tab: “Analysts build pipelines without engineers. Deploy in minutes, not months.” FinTech tab: “SOC2 Type 2 certified. Blocking quality controls. Zero errors.” AI/ML tab: “Native SQL+Python. Automated schema mapping. Mixed workloads.” E-commerce tab: “88% cost reduction. 4x faster insights. 99.8% accuracy.” Personalization increases engagement. FinTech visitors see compliance. Gaming visitors see analyst enablement. AI companies see mixed workload support. E-commerce sees cost savings. Same product, different language.
Design Decision 4: Progressive Disclosure The problem: Technical buyers want depth. Non-technical buyers want simplicity.
The solution: Three-step flow (Connect → Transform → Trust) with expandable details.
Surface level: Simple 3-step visual One click deeper: Expandable sections with technical details Result: Reduces cognitive load while allowing deep dives for technical buyers
Design Decision 5: Pain Point Empathy The problem: Generic “features” sections don’t resonate.
The solution: Lead with the customer’s current pain state.
Copy structure:
Problem: “You’re using custom ingestion + Airflow + dbt. Three tools. Three maintenance burdens.” (Person 1’s exact language from travel tech company) Solution: “Unified ingestion, orchestration, transformation, and quality in one platform.”
Why this works: Customers see themselves in the problem description immediately. “That’s us” = instant recognition.
Generic benefit statements sound like marketing. Specific metrics sound like truth.
Design Decision 6: Trust Signals Placed strategically:
SOC2 Type 2 certification (for FinTech segment) Customer logos (social proof) “Blocking by default” quality controls (addressing reactive quality pain) Deployment speed metrics (addressing operational overhead)
Why it works: Each trust signal directly addresses a pain point from interviews.
Every design element traced back to a customer quote or pain point.
- Learnings & Reflection Customer language is positioning gold.
When someone says “trainwreck,” use it. Don’t sanitize it into “suboptimal infrastructure.” Different segments need different stories; one value proposition for everyone is a value proposition for no one. Quantifiable claims beat vague benefits every time. “88% cost reduction” means everything. Lead with pain, not product. “Stop wrestling with fragmented tools” converts better than “Unified data platform.” Internal jargon kills conversion. The real output was four validated ICP segments (Mobile Gaming, FinTech & RegTech, AI & SaaS, E-Commerce & Logistics), customer quotes that became positioning language, and confirmation of product differentiators. You can’t get this from desk research alone. You get it from listening. Your customers will teach you what your product actually does, not what it technically does, but what it does for them. Person 1 (from the travel tech company) didn’t care about “unified data infrastructure.” He cared about ending his trainwreck. That’s product-market fit in one word. 8. The Replicable Framework If you’re doing customer-driven discovery for a technical B2B product:
Phase 1: Research Phase Qualitative Interviews (5–10 people)
Target: People doing the actual work (not executives) Ask: Current workflow, pain points, tools, workarounds Listen for: Specific language patterns, emotional intensity, quantifiable impacts Theoretical ICP Analysis (5–10 companies)
Use: LinkedIn, company websites, product pages Look for: Signals that indicate pain (compliance mentions, “data-driven” language, job postings for data roles) Phase 2: Analysis & Segmentation Pattern Recognition
Map pain points across interviews Identify clusters (3–5 distinct pain point groups) Look for segment-specific language patterns ICP Segmentation
Group companies by pain point cluster Define what each segment cares about (and doesn’t care about) Create segment-specific value propositions Phase 3: Design Translation Copy & Messaging
Use customer language verbatim in headlines Quantify every claim with customer data Create segment-specific messaging UX Decisions
Translate pain points into design elements Build personalization mechanism (tabs, pages, dynamic content) Progressive disclosure for technical depth Validation
Test messaging with 2–3 people from each segment A/B test headlines Measure: time to value, conversion rate, engagement This framework applies to any technical product & devtools.
The methodology:
customer interviews → pain point mapping → ICP segmentation → design translation.
Repeat until you can explain your product using only customer language.