Mapping Customer Needs to Functional Requirements

Mapping Customer Needs to Functional Requirements

Overview

This section covers applying JTBD methodology to the requirements analysis process in IoT projects, building a bridge between customer needs (business language) and functional requirements (technical language). After completing this section, you will be able to:

• Transform vague business demands into structured functional requirements
• Build a JTBD → Business Requirements → Functional Requirements → Technical Solution mapping chain
• Use the Importance × Satisfaction priority matrix to filter features
• Drive requirements confirmation and solution customization with JTBD in pre-sales scenarios

Prerequisites

Before starting this section, ensure:

• Completed the previous section “JTBD Method Overview & Core Concepts”
• Understanding of the basic IoT tech stack (Sensors → MQTT → Node-RED → Database → Visualization)
• Access to real customer needs or a simulated pre-sales scenario

Key Concepts

The Requirements Gap Problem

One of the most common failure modes in IoT projects is the requirements gap:

What the customer says           →  "We want a smart factory"
What the PM understands          →  "Deploy a sensor monitoring system"
What the engineers build         →  "ESP32 + DHT22 + MQTT + Grafana"
What the customer ultimately sees →  "A bunch of dashboards, but I don't know how to use them..."

The root cause of this gap: there’s no systematic translation mechanism from customer demands to technical implementation. JTBD provides a structured bridge.

Four-Layer Requirements Mapping Model

┌─────────────────────────────────────────────────────┐
│  Layer 1: JTBD (Customer's Jobs)                     │
│  "I want to know immediately when the line has issues"│
├─────────────────────────────────────────────────────┤
│  Layer 2: Business Requirements                       │
│  "Real-time alerts + anomaly classification + tracking"│
├─────────────────────────────────────────────────────┤
│  Layer 3: Functional Requirements                     │
│  "Threshold alert engine + multi-level notifications" │
├─────────────────────────────────────────────────────┤
│  Layer 4: Technical Solution                          │
│  "Node-RED alert flow + Telegram Bot + InfluxDB"     │
└─────────────────────────────────────────────────────┘

Each layer answers a different question:

• Layer 1: Why — Why does the customer need to do this?
• Layer 2: What — What capabilities does the customer need?
• Layer 3: How (Functional) — What features must the system provide?
• Layer 4: How (Technical) — What technology to implement with?

Mapping Workshop

For mapping customer needs to functional requirements, a mapping workshop is recommended:

Participants:

• Customer side: Decision maker + Actual users
• Service side: Product Manager (facilitator) + Technical Lead

Workshop Process:

Step 1: Requirements Collection (30 min)
    → Have the customer describe daily work problems and expectations
    → Use JTBD interview framework to guide

Step 2: Job Statement Extraction (20 min)
    → Extract Job Statements from interview records
    → Customer confirms and prioritizes

Step 3: Business Requirements Breakdown (30 min)
    → What business capabilities correspond to each Job
    → Identify key constraints and success criteria

Step 4: Functional Requirements Mapping (40 min)
    → Translate business requirements into system features
    → Note implementation complexity and dependencies

Step 5: Priority Confirmation (20 min)
    → Filter using Importance × Satisfaction matrix
    → Determine MVP scope and iteration plan

Practice: Complete IoT Requirements Mapping

Case Background

A chemical factory needs to deploy an environmental monitoring system. The customer’s core demands:

• Meet safety regulatory compliance requirements
• Reduce safety incidents caused by environmental anomalies
• Lower manual inspection costs

Step 1: JTBD Extraction

Through customer interviews, extract the following Job Statements:

ID	Type	Job Statement
J1	Functional	When workshop gas concentration exceeds limits, I want to receive an immediate alert, so I can initiate evacuation before an incident occurs
J2	Functional	When I need to submit reports to the safety department, I want compliance reports auto-generated, so I can save time on manual data compilation
J3	Functional	When equipment status changes, I want to trace historical data, so I can analyze root causes of incidents
J4	Emotional	I want to feel confident during my shift, knowing the system is watching everything for me
J5	Social	When the safety department inspects, I want to showcase a professional digital management system

Step 2: Business Requirements Breakdown

JTBD	Business Requirements	Success Criteria
J1	Real-time gas monitoring + Multi-level alerts	Alert received within ≤ 30 seconds of threshold breach
J2	Automated data collection + Compliance report generation	Monthly report generated in ≤ 5 minutes
J3	Historical data storage + Multi-dimensional queries	Support data tracing for the last 12 months
J4	24/7 automated monitoring + Status overview	On-duty personnel need no manual inspections
J5	Visualization dashboard + Demo capability	System showcase ready within 3 minutes during inspection

Step 3: Functional Requirements Mapping

Business Requirement	Functional Requirement	Technical Implementation	Complexity
Real-time gas monitoring	Sensor data collection (1s sampling)	ESP32 + MQ-135 + MQTT	Low
Multi-level alerts	Threshold alert engine (warning/alarm/critical)	Node-RED alert flow	Medium
Multi-level alerts	Multi-channel notifications (SMS/email/audible)	Telegram Bot + Email + Buzzer	Medium
Compliance report generation	Data aggregation + PDF report export	Node-RED + Puppeteer	High
Historical data tracing	Time-series storage + Query API	InfluxDB + Grafana	Medium
Visualization dashboard	Real-time monitoring dashboard	Grafana Dashboard	Medium
Status overview	Device online status + Alert statistics	Node-RED + Grafana	Low

Step 4: Priority Matrix

Use the Importance × Satisfaction matrix to determine feature priorities:

Importance
  High │  [Opportunity Zone]        │  [Must-Have Zone]
       │  Compliance reports        │  Real-time alerts
       │  Incident tracing          │  Concentration monitoring
  Med  │  [Low Priority Zone]       │  [Over-Served Zone]
       │  Device admin backend      │  Multi-channel notifications
       │  Mobile App                │  Large-screen visualization
  Low  │                            │
       └────────────────────────────┼────────────────────────
            Low         Medium        High
                         Satisfaction

Quadrant Interpretation:

• Must-Have Zone (High importance + Low satisfaction): Core features MVP must include
• Opportunity Zone (High importance + Low satisfaction): Competitive differentiation opportunity
• Over-Served Zone (Low importance + High satisfaction): Avoid over-investment
• Low Priority Zone (Low importance + Low satisfaction): Consider for future iterations

Mapping Output

Finalize a structured requirements mapping document:

## Requirements Mapping — XX Chemical Factory Environmental Monitoring

### 1. Project Background
- Customer: XX Chemical Factory
- Core Jobs: Regulatory compliance + Reduce safety incidents + Lower inspection costs

### 2. JTBD List
- J1: Real-time alerts (Functional, Priority: Must-Have)
- J2: Compliance reports (Functional, Priority: Opportunity)
- J3: Historical tracing (Functional, Priority: Opportunity)
- J4: Shift confidence (Emotional, Priority: Must-Have)
- J5: Digital image (Social, Priority: Must-Have)

### 3. MVP Feature Scope
| Feature | JTBD | Complexity | Est. Duration |
|---------|------|-----------|--------------|
| Sensor collection | J1 | Low | 3 days |
| MQTT transport | J1 | Low | 1 day |
| Alert engine | J1, J4 | Medium | 5 days |
| Multi-channel notification | J1, J4 | Medium | 3 days |
| Real-time dashboard | J4, J5 | Medium | 3 days |
| Large-screen display | J5 | Medium | 2 days |

### 4. Phase 2 Features
- Automated compliance report generation
- Historical data traceability analysis
- Mobile App

Requirements Traceability Matrix (RTM)

To ensure every feature traces back to a customer need and every requirement has a verifiable deliverable, use a Requirements Traceability Matrix:

Req ID	JTBD	Business Req	Functional Req	Design Doc	Test Case	Status
R1	J1	Real-time monitoring	1s sampling + MQTT upload	DD-01	TC-01~03	✅
R2	J1	Multi-level alerts	Threshold engine + 3-level alerts	DD-02	TC-04~08	✅
R3	J2	Compliance reports	PDF export + templates	DD-03	TC-09~12	🔲
R4	J3	Historical tracing	InfluxDB + Query UI	DD-04	TC-13~16	✅
R5	J5	Visualization dashboard	Grafana dashboard	DD-05	TC-17~19	✅

Common Mapping Pitfalls

Pitfall 1: Skipping JTBD, Defining Features Directly

❌ Customer says: "We want an IoT system"
❌ Start designing the feature list immediately
✅ First ask: "What job do you want the IoT system to accomplish?"

Pitfall 2: Feature Bloat

❌ "Our system has 50 feature modules!"
✅ "Our system provides complete support for your 5 core jobs"

Pitfall 3: Ignoring Emotional/Social Jobs

❌ Only show technical metrics: "Alert latency < 1s"
✅ Also address emotional needs: "Rest easy 24/7 — the system watches everything for you"

Pitfall 4: Broken Traceability

❌ Features without corresponding customer needs (self-indulgent features)
❌ Needs without corresponding features (broken promises)
✅ Every feature traces to a customer need; every need has feature support

Verification

Verify mastery of requirements mapping:

1. Methodology Understanding

   • Can explain each layer of the four-layer mapping model
   • Can classify features using the priority matrix

2. Practical Operation

   • Can extract 5+ Job Statements from a customer scenario
   • Can complete the full mapping from JTBD to technical solution
   • Can produce a structured requirements mapping document

3. Pre-Sales Application

   • Can guide customer needs using JTBD in pre-sales communication
   • Can build persuasive solution pricing using mapping results

Best Practices

• ✅ Recommended: Complete a requirements mapping workshop before each project kickoff
• ✅ Recommended: Use the RTM to ensure bidirectional coverage of needs and features
• ✅ Recommended: Explicitly include emotional and social jobs in proposal documents
• ✅ Recommended: Prioritize “Must-Have Zone” features for MVP, validate value quickly
• ❌ Avoid: Doing whatever the customer says (mine for deeper jobs)
• ❌ Avoid: More features is better (focus on features that complete the job)
• ❌ Avoid: Having the technical team face raw customer needs directly (PM must translate)

Summary

Key takeaways from this section:

1. The requirements gap is a core risk in IoT projects

   • A systematic translation mechanism is needed between customer demands and technical delivery

2. The four-layer mapping model connects business and technology

   • JTBD → Business Requirements → Functional Requirements → Technical Solution
   • Each layer answers a different question (Why → What → How)

3. The priority matrix guides MVP scope

   • Importance × Satisfaction matrix filters core features
   • Must-Have zone first, Opportunity zone for differentiation

4. The Requirements Traceability Matrix ensures completeness

   • Every feature traces back to a customer need
   • Every requirement has corresponding feature support and verification

5. The mapping workshop is the core collaboration format

   • Customer side + Service side participate together
   • Structured process ensures efficient output

References

• Ulwick, A. W. (2016). Jobs to Be Done: Theory to Practice — Chapter 5: “The Job Map”
• Switch Interview Technique - Christensen Institute
• Requirements Traceability Matrix Best Practices
• Kano Model and JTBD Integration

Building a commercial IoT product?

We provide ESP32 ODM design-to-manufacturing services. From prototype to production — the team behind this tutorial can build it with you.

Talk to us →