Building Requirements the Solution Can Stand On 

By Sam Day, VP of Engineering, JLD Technology Solutions

At JLDTS, many of the products we build start as an idea someone is excited about. Sometimes it arrives as a one-line pitch, sometimes as a stack of sketches with enthusiasm; regardless, the common instinct is to start building. Someone has already found a chip that looks perfect. Someone else has a dev kit in a drawer. Someone says, “Build fast. Fail fast. Iterate.” The whole room wants to move. 

We don’t move right away. Before we choose a single component, we sit down and pull the idea apart. Brainstorming sessions generate block diagrams with loose ends, which leads to a living list of notes and questions. We steadily organize this into something structured. That process turns the spark of an idea into a written foundation, which can mitigate the complexities of hardware and firmware development throughout the project. This can be the difference between embarking on a fun project and building a viable solution with market fit. It is also one of the first things a prospective client should understand about how we work.

This is risk retirement, not paperwork 

The work we do at this stage is not a formality. It’s risk retirement, completed with documents and diagrams instead of a soldering iron. Every serious problem a product can have, whether it costs too much, drains a battery in a day, can’t pass certification, or can’t be manufactured, is far cheaper to catch in the early stages than any later point in the project. A bad assumption caught at this stage costs an afternoon. That same assumption caught after boards have been ordered costs weeks and real money. 

So, when a development partner wants to start soldering on day one or demoing in a week, treat it as a warning sign. Enthusiasm to build is not the same thing as readiness to execute. The teams that move fastest over the life of a project are usually the ones willing to take time to lay a solid foundation at the start. 

Start with the problem, not the product 

The first questions we ask have nothing to do with parts. They’re about the problem, the person who has it, and what the solution accomplishes. What is this truly for? Who uses it, and in what conditions? What does success look like to the user? 

Those answers set the guardrails that quietly govern every technical decision that follows. Getting them wrong early can sink a project no matter how thorough the engineering is later. Questions like: 

• What is the power budget? For a battery-powered device, this shapes nearly every other choice on the board. 

• What is the operating environment? This will dictate form factor and what conditions a device must withstand. 

• Is there a target cost? Specifically consider the per-unit cost ceiling at the volume you plan to ship. 

• What are the regulatory and compliance standards? Wireless certifications like FCC and CE are cheap to plan for early and brutal to retrofit once hundreds or thousands of boards exist. 

For example, a microcontroller can be chosen early – sometimes before we are involved. When that happens, we want to know how it performs within the above requirements and limits. If it cannot, the cheapest solution is to identify that as early as possible.

The requirements nobody hands you 

Often, a client hands us is a feature list that works perfectly on paper in the happy-path scenario. Each capability makes sense on its own, and they do not conflict when used as intended. The whole thing reads like a finished product. Our job at this stage is to highlight which real-world limits will affect the solution, and how they will impact the product (power, cost, size, environment, users), and how they all impact each other. The requirements that sink projects are almost never on the original feature list, because they only surface at that collision. We would rather find them now, while they are still cheap to deal with. 

At JLDTS, we’re not afraid to ask the pointed, slightly annoying questions: 

• What is the real battery life expectation, not the aspirational one? “As long as possible” is not something we can design against. 

• Does it need an ingress protection (IP) rating? Is it going to get rained on, dropped in mud, or washed down? 

• What volume are we really talking about, and over what timeline? 

• What is the unit-cost ceiling nobody has said out loud, but everybody is quietly assuming? 

A requirement you can point to later is a decision. A requirement left vague is a discrepancy waiting to lead to an incorrect assumption or breaking limitation. We would rather have the tough conversation at the start, when it has the least impact on budget and timeline.

What we are building is a foundation, not a wish list 

All of that brainstorming and note-wrangling drives toward a single output: a structured document that captures far more than a list of features. We write down five things, and we keep them alive as the project moves: 

• Requirements. What the product must do, stated clearly enough to design and test against. 

• Features. The capabilities that deliver those requirements, and how they fit together. 

• Limitations. What the product intentionally does not do. Scope you draw a line around now is scope you do not argue about later. 

• Assumptions. Everything we are quietly betting on, written down so when one turns out to be wrong, we know exactly what shifts and why. 

• Uncertainties and risks. The things that could bite us, named early so we can design around them, test them first, or at least go in with our eyes open. 

The first two are easy. Anyone can write a feature list. It is the last three, stating what you will not do, what you are assuming, and what could go wrong. That separates a real plan from a wish. Those pages are usually the ones that save the project. 

Draw the boundaries, not the schematic 

With that foundation in place, we draw the system rather than the circuit. Block diagrams first: what lives on the device, in a mobile or web application, in the cloud, and where the lines between them fall. 

We draw the boundaries between subsystems deliberately and outline the protocol between them, so each block knows only what it needs about the next, without depending on how it works inside. Sensing, storage, connectivity, power: we treat each as its own concern with a clean interface to the rest. Early on it looks like a mess of boxes and arrows in disarray before it is refined into a tidy web of interconnected systems. It is not tidiness for its own sake, and it pays off in ways that are not yet obvious. 

What this actually buys you 

Requirements are the cheapest place to be right – and the most expensive place to cut corners. The structure we invest in here – meaning clear requirements, honest limitations, explicit assumptions, and named risks buys you/the client/the partner options that are impossible to see from the starting line. 

 So press pause on ordering the chip, breaking out the dev kit, or picking up the soldering iron. Find a partner who is willing to slow down in order to be thorough from the beginning. A partner who does this, like JLDTS, is buying you room to chase the opportunities you want, instead of chasing down problems you could have caught in this stage.