How to Test Market Fit in One Week with the IoT Discovery Sprint Methodology

Building an IoT product is an expensive commitment. 

Before a single line of production code is written, you’re already making decisions about hardware, connectivity, cloud architecture and firmware, all decisions that are difficult, sometimes impossible, to unwind later. 

Get those decisions right, and you have a foundation worth building on. Get them wrong, and you’re carrying unnecessary technical debt from day one.

The traditional response to this problem is a full discovery phase: weeks of workshops, research and planning designed to de-risk the build before it starts. That’s the right instinct, but for many teams it’s also impractical. 

Discovery phases stretch. Scope creeps. Stakeholders lose patience. And by the time you’ve finished planning, the market has moved.

There’s a better way to approach early-stage IoT validation. One that’s structured, time-boxed and built around a single decisive output. 

The IoT Discovery Sprint is a framework that’s emerged across product and engineering teams as a way to answer the most important question in product development as fast as possible: is this worth building?

Most product validation frameworks were designed with software in mind. Run a few user interviews, build a clickable prototype, test it with your target audience. If it works, ship it. If it doesn’t, pivot. The feedback loop is tight and the cost of being wrong is relatively low.

IoT doesn’t work like that.

In a connected hardware product, software, firmware, cloud infrastructure and physical device design are coupled from the start: 

• An assumption you make about connectivity at the concept stage will shape your cloud architecture 
• Your cloud architecture will constrain your data model 
• Your data model will affect what your firmware needs to do 
• And your firmware choices will influence what hardware you can realistically use

This coupling means that a wrong assumption made early (about how the device will communicate, what data it needs to capture, or how users will interact with it in the real world) doesn’t affect just one layer of the product. It propagates through all of them.

As covered in our guide to IoT MVP best practices, shortcuts taken during early product development have a way of becoming expensive structural problems later.

The implication is this: IoT teams need a way to validate their core assumptions before those assumptions get baked into architecture. That’s exactly what the Discovery Sprint is designed to do.

The IoT Discovery Sprint is a structured, five-day process for validating the core assumptions underpinning a product concept. It’s collaborative by design, meaning your stakeholders are active participants throughout, not passive observers waiting for a report. Think of it as a Stage Zero exercise, a purely theoretical process that operates entirely at the assumption, architecture and framework level. No hardware is involved.

Now let’s be clear about what the sprint is not.

It’s not a hackathon. There’s no pressure to produce working software by Friday.

It’s not a sales exercise. The output isn’t a proposal for a build engagement, it’s an honest assessment of whether and how to proceed.

It’s not a hardware validation exercise. Physical constraints (parts availability, size, real-world power consumption, RF behaviour in the field) are outside the sprint’s scope. If those are your primary unknowns, you’re looking at a PoC build, not a sprint.

And it’s not a substitute for a full product discovery process. For complex products with multiple user groups, extensive regulatory requirements or significant technical unknowns, a longer discovery phase may still be warranted.

What the sprint does is get you to a decision point quickly, rigorously and with enough evidence to act on in a way that a longer, more open-ended process regularly fails to deliver.

Day 1: Map Your Assumptions

The sprint begins with a facilitated assumption-mapping session. Your key stakeholders, typically your product lead, a technical decision-maker and any relevant domain experts, work together to surface and prioritise the assumptions your product concept is built on.

These might be assumptions about:

• User behaviour (“people will check the dashboard at least once a day”) 
• Technical feasibility (“we can achieve the required battery life with this sensor configuration”)
• Market demand (“facilities managers will pay for this capability”)

Most product concepts have more assumptions embedded in them than their teams realise.

By the end of Day 1, you have a ranked list of assumptions, ordered by two criteria: how critical each one is to the product’s success, and how uncertain you currently are about whether it holds. These become the rest of the sprint’s focus.

Day 2: Test Technical Feasibility

With the critical assumptions identified, the engineering leads take over on Day 2. This is where the IoT-specific complexity gets worked through:

• Connectivity requirements
• Edge vs. cloud processing trade-offs
• Data volumes and latency needs
• Firmware constraints and regulatory compliance requirements

Day 2 is an architectural and theoretical exercise. The goal is to identify constraints and blockers on paper, not to validate them against physical components. That level of validation comes later, during PoC and prototyping.

On the last point about regulatory requirements: IoT products placed on the EU market are now subject to mandatory cybersecurity requirements under the Radio Equipment Directive (RED), which came into force in August 2025, ahead of the broader Cyber Resilience Act obligations rolling in from 2026 onwards. These aren’t considerations to revisit at launch, and architecture decisions made on Day 2 of the sprint should reflect them.

The output of Day 2 is a clear picture of (1) which assumptions are technically sound, (2) which are achievable with caveats, and (3) which represent genuine blockers that need resolving before a build can proceed. This is also the stage where security-first design principles are introduced as a structural input to the product’s architecture.

Day 3: Scope the Minimum Testable Thing

Day 3 is about translation. Given everything surfaced in the first two days, what is the smallest, most focused thing you could build or simulate to test your highest-priority assumptions?

This is a different question to “what’s the MVP?” An MVP is a product you’re willing to put in front of users. The Minimum Testable Thing is whatever gives you the most useful signal about your core assumptions, which might be considerably simpler than a full product prototype.

The Minimum Testable Thing could be:

• A hardware simulation 
• A software mock-up of the key user interaction 
• A data model exercise 
• A structured customer conversation with a concept in hand (in some cases)

The team agrees on what to test and how to test it, with clear criteria for what a positive or negative result looks like. That definition of success is documented before testing begins, not decided retrospectively.

Day 4: Gather Feedback

With the testable concept defined and prepared, Day 4 is dedicated to gathering input from the people whose response matters most, whether that’s prospective users, internal stakeholders, technical reviewers or potential buyers. The format depends on what you’re testing and who your audience is.

At this stage, you’re looking for signal, not certainty – that is, enough directional evidence to inform a confident decision on Day 5.

Day 5: Make the Call

The sprint closes with a structured decision session, with findings from all four preceding days reviewed together: the assumption map, the technical feasibility assessment, the Minimum Testable Thing and the feedback gathered. The team then works through what the evidence supports.

The output is one of three recommendations:

Go – the core assumptions hold, the technical path is clear, and there’s sufficient evidence of market demand to justify moving ahead with further development.

Pivot – one or more assumptions need revising, but the underlying opportunity is real. The sprint output defines what needs to change before build can begin.

Stop – the evidence doesn’t support the product concept as defined. This is the most valuable outcome the sprint can produce, because it saves the cost of building something the market doesn’t want, a lesson that’s played out across the IoT industry.  We’ve seen it firsthand with DO OK’s long-term partner Versa, who pivoted from luggage tracking to asset and cargo tracking in response to changed market conditions.

Regardless of which recommendation the sprint produces, you leave with a set of concrete, usable outputs:

• A documented assumption map, ranked by criticality and uncertainty
• A technical feasibility assessment covering connectivity, architecture, compliance and security considerations
• A defined Minimum Testable Thing with agreed success criteria
• A summary of feedback gathered and what it indicates
• A clear go/pivot/stop recommendation with the reasoning behind it

These outputs feed directly into whatever comes next, which could be a refined product brief, a build engagement or just a decision to redirect resources elsewhere.

The Discovery Sprint works best in a specific set of circumstances. It’s the right move when you’re validating a new IoT product concept when:

• The core assumptions haven’t been tested
• An existing product is being adapted for a new vertical or market and you’re uncertain whether the use case transfers
• You have a technically complex product idea and need to understand feasibility before committing to a build

It’s less suited to products with a well-established market fit and a clear technical path, or where a longer, more intensive discovery phase is already planned and resourced. If you’re not sure which category you’re in, that uncertainty is itself a signal that a sprint might be worth the week.

Remember, the Discovery Sprint is a theoretical exercise. The moment real hardware enters the picture, with physical prototypes, component sourcing, real-world power and connectivity testing, you’ve departed from sprint territory. At that point you’re running a PoC, which is a different engagement entirely and one that typically takes weeks to months rather than days. 

The sprint is designed to get you to the point where a PoC is worth running, not to replace it.

The Discovery Sprint is a framework any capable IoT team can run, but the quality of the technical feasibility work on Day 2 depends heavily on the depth of experience in the room. 

IoT-specific constraints around connectivity, firmware, edge computing and EU regulatory compliance aren’t always well-represented in generalist product teams. That’s where a specialist partner adds the most value.

DO OK’s IoT and cloud engineering team has hands-on experience across connected hardware and cloud platforms with a variety of real-world deployment challenges. We most commonly support teams with structured facilitation of the sprint itself, particularly the technical feasibility and assumption-mapping stages, and in translating sprint outputs into a product discovery process that carries the validated concept through to build. 

If you’re sitting on an IoT product concept and wondering whether to move forward, get in touch and we can talk through the right starting point for your team.