Click for previous chapter: Introduction
“Wait—should we even build this thing?”**
Imagine you are standing at the mouth 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 there are mud pits and hungry bugs waiting to nibble away at your runway. Chapter 0 is where you decide whether the treasure hunt is worth hacking a path at all. Rookie product managers often skip this step (“Let’s just start sprinting!”). Don’t. A disciplined Concept & Feasibility sprint saves you months of rework, melts away the fog of wishful thinking, and gives your team a rallying‑cry they can carry through the inevitable 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 wire‑framing without a clear, evidence‑based “Why”, you are basically renting a bulldozer before you know whether you need a flower bed or a skyscraper. Worse, rookie PMs who skip feasibility will end up pitching hazy dreams to stakeholders: “It’s like a Fitbit, but for cats, and also it mines cryptocurrency!” Great, but try defending that budget request in front of Finance once they ask 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 starts drifting above –15 °C at 3 a.m.
2. Vision statement
Distill what you heard into one sentence that can fit on a coffee mug. “We give facilities managers Jedi‑like foresight into 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 munches a celebratory cinnamon bun because catastrophe was averted. No UI pixel‑pushing yet—think comic strip, not Marvel 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 search of how many “Facilities Manager” job titles exist 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 signal dies at two metres, you just dodged a connectivity bullet before ordering custom PCBs.
- Sensor truthiness 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 (ThinkSpeak, 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 magical 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 management‑crust for the sake of ceremony. They act like 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”? Here’s a back‑of‑envelope cautionary tale. A team I mentored spent €60 000 on PCB spins before realising 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 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 slaps a $12 I²C temperature sensor onto a Wio‑Link dev board, streams JSON to Adafruit IO.
Wednesday: Cloud intern builds a Grafana panel and SMS alert via Twilio.
Thursday: PMs push a demo video to stakeholders; 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, emoji 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 loudest in impact. Treat it like the prologue to your favourite fantasy 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 like LEGOs. Your engineers will thank you, your investors will nod approvingly at your crisp articulation of value, and most importantly, your users will eventually receive a product that genuinely saves their bacon (or ice‑cream).
Ready? Take a sip of coffee, close those YouTube teardown tabs, and march boldly into Chapter 1, where we turn fuzzy aspirations into rock‑solid System Requirements—so clear even your future compliance auditor will crack a smile.