End‑to‑End IoT Product Development Playbook – Stage 0 – Concept & Feasibility
Click for previous chapter: Introduction
“Wait — should we even build this thing?”
Most failed IoT products were lost before the first schematic was drawn: nobody checked whether the idea was worth building. Stage 0 exists to answer that question with evidence rather than enthusiasm. Picture yourself at the edge of a dense jungle, machete in hand. You can hear there might be treasure beyond the vines — rumours of grateful customers, glowing investor slide decks, maybe even the mythical Series B. But you can also sense the mud pits and hungry bugs waiting to nibble away at your runway. A disciplined Concept & Feasibility sprint tells you whether the treasure hunt justifies hacking a path at all. Teams in a hurry often skip this step (“Let’s just start sprinting!”). Don’t. A few focused days here save months of rework, clear away the fog of wishful thinking, and give the team a rallying cry that survives the long nights of debugging firmware at 2 a.m.
0.1 Why does this chapter matter so much?
Because every downstream Gantt bar, Jira ticket, and purchase order inherits its reason for existing from the decision you make here. If you launch into schematic capture or mobile-app wireframing without a clear, evidence-based “Why”, you are renting a bulldozer before you know whether you need a flower bed or a skyscraper. Teams that skip feasibility also end up pitching hazy dreams to stakeholders: “It’s like a Fitbit, but for cats, and it also mines cryptocurrency!” Entertaining — until Finance asks about the cost of Bluetooth mesh on a collar that Fluffy loves to chew.
0.2 The four conversations you must have
1. Pain‑point interview
Find an actual human (or several) who experiences the problem daily. Listen more than you talk. If they don’t use salty language or sigh heavily when describing the pain, the problem probably isn’t acute enough to justify a hardware start-up’s burn rate.
Example: A facilities manager confesses they lose thousands of euros a month because nobody notices when the industrial freezer drifts above –15 °C at 3 a.m.
2. Vision statement
Distil what you heard into one sentence that fits on a coffee mug. “We give facilities managers early warning of equipment failures — before the ice cream melts.” If the sentence feels flabby or tries to please everyone, keep whittling.
3. High‑level user journey
Plot a simple storyboard: the manager receives a push notification, taps to open a trend graph, dispatches maintenance, and enjoys a quiet cinnamon bun because catastrophe was averted. No UI pixel-pushing yet — think comic strip, not high-fidelity mock-ups.
4. Market sanity check
Open a spreadsheet (yes, that dreaded blank grid) and answer: How often does this pain occur? How many people have it? What would each pay for relief? Industry reports, competitor SKU prices on Digi-Key, and a quick LinkedIn count of “Facilities Manager” job titles in your target region will get you within respectable accuracy. Rookie PMs worry about decimal places; veterans worry about orders of magnitude.
0.3 Rapid‑fire feasibility experiments
Hardware development can feel glacial, but you can still generate convincing evidence in days:
- Range smoke test – Grab an off-the-shelf BLE dev-kit, stick it inside a stainless-steel freezer, ping it from the corridor, measure RSSI. If the signal dies at two metres, you just avoided a connectivity mistake before ordering custom PCBs.
- Sensor truth check – Borrow a calibrated temperature probe, tape it beside your candidate digital sensor, and record 12 hours of data. Does the cheap sensor drift 3 °C every time the compressor kicks in? Scrap it early.
- Stakeholder demo – Pipe the dev-kit’s data into a free cloud dashboard (ThingSpeak, Adafruit IO) and show your facilities manager. If they ask, “Can I buy this tomorrow?” you’re onto something. If they shrug, refine or pivot.
0.4 Artefacts to take away (nothing fancy)
- Vision one-pager – Elevator pitch, target user, visceral pain, proposed outcome.
- Three-frame storyboard – Identify trigger, action, and outcome. Sketchy is fine; phone photos of sticky notes count.
- TAM/SAM/SOM table – Total, Serviceable, Obtainable market estimates. Ten rows is plenty. Include your confidence score and citation links.
- Feasibility sprint memo – One page: Hypothesis → Experiment → Data → Verdict → Next step. Readable in three minutes by your VP.
These artefacts are not ceremony for its own sake. They act as alignment beacons: when marketing wants to chase another persona, or engineering proposes an exotic mmWave radio, you can wave the one-pager and ask, “Does this serve our freezer-saving facilities manager story?”
0.5 Cost of skipping
Still tempted to declare “build it and they will come”? A back-of-envelope cautionary tale: a team I mentored spent €60 000 on PCB spins before realising that hospitals — their target market — don’t allow 2.4 GHz radios in MRI suites. A two-hour feasibility smoke test with a borrowed spectrum analyser would have saved eight months and an engineer’s resignation.
0.6 Building the Go/No‑Go ritual
Humans — especially engineers fuelled by the thrill of blinking LEDs — hate saying “No.” Institutionalise it. Put a calendar invite for a Feasibility Review exactly two weeks after project kickoff. Invite one person each from business, engineering, quality, and customer success. Present your four artefacts, demo any quick prototypes, and end the meeting with a forced vote: Go or No-Go (pivot counts as No-Go). Majority rules. Record the decision in your wiki with a timestamp and a list of attendees. Future-you will thank past-you when auditors or investors ask, “Why did you bet the farm on LoRa rather than NB-IoT?”
0.7 Common rookie pitfalls and how to dodge them
| Pitfall | Why it stings | Antidote |
|---|---|---|
| Solution first, problem later – Falling in love with cool tech | You end up hunting for a market | Write your pain statement before touching dev-kit firmware |
| Analysis paralysis – Weeks of spreadsheets | Momentum dies, morale dips | Time-box every research task to days; share imperfect numbers openly |
| Asking leading questions – “Wouldn’t you love a freezer cloud?” | Users say yes to be polite → False validation | Ask about today’s workaround cost; watch for real emotion |
| Ignoring hidden constraints – Regulatory bans, building codes | Surprise redesigns cost millions | Phone one industry veteran; ask “What blindsided you last time?” |
0.8 Mini case study: The One‑Week Smart‑Freezer Sprint
Monday: Two PMs interview three facility managers, confirm freezer spoilage costs €10 k per incident.
Tuesday: Hardware lead mounts a $12 I²C temperature sensor on a Wio-Link dev board, streams JSON to Adafruit IO.
Wednesday: Cloud intern builds a Grafana panel and an SMS alert via Twilio.
Thursday: PMs push a demo video to stakeholders; the CFO blurts, “If this works, we’ll save €1 m annually across all sites.”
Friday: Feasibility Review votes Go, but mandates verifying cellular back-haul where Wi-Fi is flaky.
Total spend: €300 on parts and pizza. Clarity gained: priceless.
0.9 The Chapter 0 Checklist (print, annotate, stick above your monitor)
- Problem statement captured in one brutally short sentence.
- At least one interview with a sufferer of the problem, quotes recorded verbatim.
- Vision statement shared on Slack, reactions collected (if nobody reacts, re-write).
- Two-to-three user-journey sketches photographed and uploaded.
- Initial market sanity numbers in a spreadsheet, tagged with source links.
- One feasibility experiment run, data charted.
- Calendar-blocking for the Go/No-Go review done; neutral referee invited.
- Decision recorded, link pasted into the root of your project repository.
- If Go → high-level risks & next chapter owner assigned.
- If No-Go → a thank-you note sent to the team; lessons learned documented.
Tape this checklist to your laptop lid. The next time you’re tempted to sprint ahead because “the PCB house has a sale that ends tonight,” glance at box #1. If you can’t recite the problem statement in five seconds, you’re not ready to order copper.
0.10 Wrapping up
Concept & Feasibility is the smallest chapter by calendar time — but the largest in impact. Treat it like the prologue to a good novel: skip it and the rest of the plot feels confusing and hollow. Invest a focused burst of energy here, and every subsequent chapter clicks into place. Your engineers will thank you, your investors will nod at a crisp articulation of value, and your users will eventually receive a product that genuinely saves their bacon (or ice cream).
Then move on to Chapter 1, where we turn fuzzy aspirations into well-defined System Requirements — so clear that even your future compliance auditor will crack a smile.