Revolutionize Remote Sensor Design: The Jobs-to-be-Done Approach

Focus on User Outcomes to Create Truly Innovative IoT, Drones & Industrial Controls

𝗪𝗵𝘆 𝗮𝗺 𝗜 𝘄𝗿𝗶𝘁𝗶𝗻𝗴 𝘀𝗼 𝗺𝘂𝗰𝗵?

I want you to see that while JTBD is a method, 𝘵𝘩𝘦 𝘮𝘰𝘳𝘦 𝘪𝘮𝘱𝘰𝘳𝘵𝘢𝘯𝘵 𝘵𝘩𝘪𝘯𝘨 is that it can be applied to almost 𝙚𝙫𝙚𝙧𝙮 𝙩𝙮𝙥𝙚 𝙤𝙛 𝙥𝙧𝙤𝙗𝙡𝙚𝙢. You have a choice; you can spend years listening to someone preach about how to do a small part of it, or you can inspire yourself to dive in and solve problems that are never talked about in this small community. 𝗟𝗲𝘁'𝘀 𝗺𝗮𝗸𝗲 𝘁𝗵𝗶𝘀 𝗰𝗼𝗺𝗺𝘂𝗻𝗶𝘁𝘆 𝗺𝘂𝗰𝗵 𝗹𝗮𝗿𝗴𝗲𝗿.

The Remote Control Conundrum

We live in an increasingly connected and remotely operated world. Drones patrol vast agricultural fields, IoT sensors monitor critical infrastructure in harsh environments, and complex industrial machinery is controlled from afar. The demand for sophisticated, reliable remote systems is exploding. Yet, despite packing more features, sensors, and connectivity options into these systems, are they really getting the job done for the users who rely on them?

Often, the answer is a frustrating "no." Traditional design approaches frequently focus on adding more – more buttons, more data streams, more configuration options. This feature-focused approach can lead to systems that are overly complex, difficult to learn, unreliable under pressure, or ultimately fail to solve the core problem the user is grappling with. We build better components, but not necessarily better solutions.

There's a better way. By shifting our perspective from features to the Jobs-to-be-Done (JTBD), we can uncover the real goals users are trying to achieve when they "hire" a remote system. This insight allows us to design solutions that deliver superior value, simplify complexity, and create truly innovative remote systems and sensors.

What Job Are Your Remote Systems Really Hired For?

When designing a remote system, it's tempting to define its purpose by its function: "monitor temperature," "control a valve," "fly a drone." JTBD pushes us to dig deeper. What fundamental progress is the user trying to make?

Defining the Core Functional Job:

Instead of focusing on the task, we need to identify the underlying objective. Consider these examples:

• Instead of "Monitor soil moisture," the job might be: Ensure optimal crop irrigation levels.

• Instead of "Control a remote robotic arm," the job might be: Manipulate materials in a hazardous environment safely.

• Instead of "Gather atmospheric data," the job might be: Predict localized weather patterns accurately.

• Instead of "Adjust flow rates remotely," the job might be: Maintain optimal fluid dynamics within a system.

Notice the shift? We move from what the system does to what the user achieves. These core jobs are stable over time, even as technology evolves.

The Importance of Context:

The "remote" aspect is crucial context. Why does the user need to perform this job remotely?

• Is it due to distance?

• Is it required because of a hazardous environment?

• Is it driven by the need for speed or efficiency?

• Is it because the user lacks local expertise?

Understanding the constraints and circumstances surrounding the job is vital for effective design.

Unpacking the Desired Outcomes:

Once we know the core job, we need to understand how the user measures success. These are the Desired Outcomes – the specific, measurable results the user wants to achieve when executing the job. They often relate to speed, predictability, efficiency, and output. Examples for the job "Achieve situational awareness in a hazardous environment" might include:

• Minimize the time to detect a critical event.

• Increase the accuracy of identifying the event type.

• Reduce the likelihood of false alarms.

• Maximize the area that can be monitored effectively.

• Minimize the need for personnel to enter the hazardous zone.

Using precise, outcome-focused verbs (like minimize, increase, reduce, maximize) is key to capturing these needs effectively.

Elevating the Abstraction: From Components to Core Goals

One of the biggest traps in designing complex systems, especially remote ones, is getting stuck at the component level. We optimize the sensor accuracy, refine the communication protocol, add features to the control interface – but we lose sight of the bigger picture, the overall job the user is trying to accomplish.

The Trap of Component-Level Thinking:

Focusing solely on improving individual parts often leads to solutions where the user has to manually integrate disparate functions, manage complex workflows, and possess significant expertise. They might have the best sensor and the best controller, but still struggle to efficiently achieve situational awareness or maintain optimal fluid dynamics.

JTBD Insight: Integrating for the Job:

Jobs-to-be-Done encourages us to ask: How can we enable the user to get the entire job done more simply, more effectively, and potentially automatically? This involves elevating the level of abstraction.

Instead of providing tools to monitor temperature, adjust flow rate, and detect leaks separately, could we design an integrated system focused on the higher-level job of "Maintain optimal system performance autonomously"? Such a system might actually have fewer user-facing controls and data points, but it would achieve the core goal more reliably and with less user effort. It abstracts away the complexity of managing individual components.

“But we make money selling individual components!” 🤡

Identifying Opportunities for Abstraction:

Where should you look for these opportunities?

• Where are users currently forced to use multiple tools or interfaces to complete one core job?

• What steps in the process require significant manual intervention, expertise, or interpretation?

• Where do errors, delays, or inefficiencies frequently occur due to the complexity of managing individual components?

These pain points often signal unmet needs and opportunities to innovate by designing a higher-level, more integrated solution. This abstraction might even change who can perform the job, potentially opening up your solution to less specialized users.

Applying JTBD to Remote System Design: A Practical Approach

Integrating JTBD into your design process doesn't require abandoning your existing methods entirely, but rather augmenting them with a focus on user goals and outcomes.

• Step 1: Define the "Job Performer": Who is ultimately responsible for getting the core job done using the remote system? (e.g., field technician, control room operator, farm manager, infrastructure inspector).

• Step 2: Uncover the Core Job(s): Conduct interviews and observations focused on their goals, struggles, and workarounds, not just how they use current tools. Ask "Why are you doing that?" repeatedly. Use outcome-focused verbs from the start.

• Step 3: Capture Desired Outcome Statements: Systematically document how the job performer measures success. Use the structure: Verb + Metric + Object of Control + Contextual Clarifier (e.g., Minimize the time to diagnose remote equipment failure when network connectivity is intermittent).

• Step 4: Quantify Opportunity: Survey job performers to rate the importance of each desired outcome and their current satisfaction level with existing solutions. Identify the outcomes with high importance and low satisfaction – these are your prime innovation targets.

• Step 5: Use Insights to Drive Strategy: Let the prioritized, unmet outcomes guide your development roadmap. Should you focus on improving reliability, reducing latency, simplifying diagnostics, automating analysis, or integrating disparate functions? JTBD provides the data to make these strategic choices.

Case Snippet (Hypothetical): Asset Monitoring Transformed

Imagine a company providing remote vibration sensors for industrial equipment. Initially, they focused on sensor accuracy and data transmission rates (component-level thinking). Customers (maintenance managers) received raw vibration data streams they had to interpret using separate analysis software, requiring specialized skills.

By applying JTBD, the company discovered the core job wasn't "Monitor vibration" but "Prevent unplanned equipment downtime." Key unmet outcomes included reducing the time to predict potential failures and minimizing the need for expert analysis.

They shifted their strategy. Instead of just sending raw data, they developed an integrated platform that analyzed the data, identified patterns indicative of future failure, and provided clear alerts ("Bearing A likely to fail within 7 days"). They elevated the abstraction from data provision to downtime prevention. This higher-value solution commanded a premium price and significantly reduced customer effort and required expertise.

Designing for Outcomes, Not Just Control

The future of remote systems and sensors lies not just in more sophisticated technology, but in a deeper understanding of the human goals these technologies serve. Jobs-to-be-Done provides a powerful strategic lens to shift our focus from building features to delivering successful outcomes.

By rigorously defining the core job, identifying unmet desired outcomes, and seeking opportunities to elevate the level of abstraction, we can move beyond incremental improvements. We can design remote systems that are not only powerful but also intuitive, reliable, and genuinely valuable, solving the real problems users face.

Time to rethink: What core job is your remote system truly being hired to do?

---

What's the biggest challenge you face in designing or using remote systems today? Is it complexity, reliability, data interpretation, or something else? Share your core 'job' and biggest hurdles in the comments below!

If you’d like to take action, I would love to help. Here’s are some steps you can take to make that a reality for us:

1. Join my community and get access to more content and tools

2. Apply for coaching so we can do projects together and build a new business-as-usual with someone who will share the knowledge, and hold you accountable. (I have limited seats so hurry!)

3. I do project work as well. Use the coaching link and we can discuss.

Why Me?

I’ve been trained by the best in Outcome-Driven Innovation. Part of that training involved how to understand what the future should look like. As a result, I’ve taken what I’ve learned and begun innovating so I can get you to the outcomes you’re seeking faster, better, and even more predictably. Anyone preaching innovation should be doing the same; regardless of how disruptive it’ll be.

How am I doing this?

• I’ve developed a complete toolset that accelerates qualitative research to mere hours instead of the weeks or months it used to take. It’s been fine-tuned over the past 2+ years and it’s second-to-none (including to humans). That means we can have far more certainty that we’ve properly framed your research before you invest in a basket of road apples. They don’t taste good, even with whipped cream on top.

• I’m also working on a completely new concept for prioritizing market dynamics that predict customer needs (and success) without requiring time-consuming and costly surveys with low quality participants. This is far more powerful and cost effective than the point-in-time surveys that I know you don’t want to do!

I believe that an innovation consultant should eat their own dog food. Therefore, we must always strive to:

• Get more of the job done for our clients

• Get the job done better for our clients

• Get the job done faster for our clients

• Get the job done with with fewer features for our clients

• Get the job done in a completely different and novel way for our clients

• Get the job done in a less costly manner for our clients

You could be an early tester of the latest developments, but at a minimum take advantage of an approach that is light years ahead of incumbent firms that are still pitching a 30 year old growth strategy process.

All the links you need are a few paragraphs up. Or set up some time to talk … that link is down below. 👇🏻

Mike Boysen - www.pjtbd.com
Why fail fast when you can succeed the first time?

📆 Book an appointment: https://pjtbd.com/book-mike