Note: parts 1 & 2 cover MVP development and are most useful for early stage start-ups, parts 3 & 4 are still being written and not yet available

If you haven’t read Part 1, you can do so right here: How to Develop Consumer Hardware (Part 1 of 4)

For this part of the series, I’ll be using the case of the Mealhero Smart Steamer to explain some core concepts.

Mealhero Smart Steamer IoT Device — *The Mealhero Smart Steamer*

For context: Mealhero allowed you to order frozen ingredients of their website and the app would know — based on your orders — what you'd have in your freezer. Based on this, it suggested multiple dishes you could make with your set of ingredients. So twenty ingredients might spawn you hundreds of different recipes to choose from. You'd pick a recipe, it'd tell which ingredients to get, you'd scan the labels and place them in the compartment of the steamer that lighted up. This way the steamer knew what went where and how long each ingredient needed to cook, plus your digital inventory was updated. It'd auto-prepare your meals and give a signal when done, you could scoop it out, wash the containers and rinse and repeat.

MVP Track — Stage 2: MVP Development

As you can see in the visual, this is a constant back-and forth between problem and solution as it's extremely difficult to divorce one from the other. I've tried methodologies in the past where you do split them up and a lot of it makes sense, but it's nigh impossible to completely ignore one or the other, so I've included some tips on how to deal with that throughout the article.

Problem Analysis

Here's the time to fall in love with the problem. This stage often requires some deeper tactics such as observations, roleplaying and truly immersing yourself in the world of your customers yourself. Now, for B2B it's often quite obvious how to do that: developing an IoT device for elderly care centers? Go work there for a few weeks while your co-founder checks himself in as a patient. Or work as a consultant/service technician to solve their current problem manually (and thus already proving willingness-to-pay quite soon).

But for consumer hardware it’s often a bit more vague or harder to do. It's really hard to emulate the life of a single mom with three kids for instance or to run a marathon when the last time you hit the gym was never. There are definitely workarounds, but there's a reason why already having good founder-market fit is so important for consumer hardware to succeed. And even if that fit is strong, you really need to get out there and explore the lives of others in a similar position.

Since this is much more time consuming, it really pays to have locked in a good customer segment first, you need your Smallest Viable Audience (SVA) on lockdown, otherwise you'll be doing this multiple times over and over, wasting a lot of time.

At this point you probably already are starting to have an idea about the product you need to build and you're already starting to think towards different solutions. And while that's great, I suggest you get that out of your system by making sketches and taking notes on how it might work and save it for the next step. Instead, I urge you to focus on "what" the system should do, rather than "how" it does it and start making a list of those things.

For instance: if you think of "it would be cool to have an RFID scanner read a label on the frozen ingredients for our smart steamer", think about what the essential function is, it could be something like: "the system is able to recognize different ingredients". This excludes the solution and keeps the door open for many different solutions. It could be done with a camera and vision technology, a barcode scanner, a spectrometer, the user inputting it manually with a code, …

Congrats, you're now taking your first steps towards writing "functional requirements"!

Do and don't of writing functional requirements — *Writing functional requirements*

Also, having a list handy makes it really easy to just dump those things in there and forget about them since they can come up at any time. I've included a further down in the article that you can use for this that we'll be working on in the next steps as well.

Once you're happy with your understanding of the problem and are experiencing diminishing returns on your research, it's time to take a look at your solutions. Up we go!

Solution Definition

There are a couple of steps to this process, it might seem a lot but in truth most of it can be banged out in a one-day workshop. Some steps do require you to move back to your users and re-evaluate, but generally speaking you can get this done in a week or two, tops. It looks something like this:

Product Vision & User Flow

Before we dive in head first, let's start with what you've got. As I said, it was important to not get carried away in the previous step, but we all know how that goes right? So I'm fairly confident that at this point you could draw a sketch or schematic of your perfect "product vision". This should be the one you want to scale.

Believe it or not, this vision will most likely still not be visionary enough, a fun exercise is to jot down the customer's experience when using this product (this can be a simple flowchart), look at all the steps and think about how you could "delight" your customers even more, how might you take away user friction?

Mealhero vision industrial design sketch and user flow customer experience — *Mealhero product vision (credit: Made) & user flow*

At this point, everything's fair game, cost is not an issue, it's about creating the best possible user experience. Update your sketches and diagrams accordingly. Done? Great. Now we can chop it to bits.

Core User Loop

Based on your user flow, you should be able to distil the "core loop" of what it is your product does. It typically consists of 3-5 blocks, each consisting of a single verb and a single noun. Try to focus on the value and benefits generated for the user rather than the strict functionalities. I've made an example using the smart steamer case.

Core loop user flow customer journey value product vision app and smart steamer — *Mealhero Core Loop & Vision*

First thing I typically see happening is founders listing too much steps. As you can see I've avoided including all the steps about scanning, emptying containers, using the app, … because they are all just a means to an end, solutions to perform a function. In a later step you will add levels to this and break it down further, but then were going too deep into the requirements management topic, so I'll leave it at that for now.

Once you do this in the context of a solutions brainstorm, you'll start to see that the core loop typically can be reduced even further once you start thinking more in terms of the value and benefits this is creating for the customer

It can sometimes happen at this stage that you might realize that you don't need a hardware product at all! It might be that a service business might be better suited. In the case of Mealhero, people didn't really care about having a smart steamer in their house: it took up space, had to be cleaned, etc… But it did allow them to get freshly made, healthy food in half an hour tops.

Real core loop user flow customer journey value product vision app and smart steamer — *Real Core Loop and emerging competitors*

But you could see how a business selling pre-packaged and complete frozen dishes that you fry up in a pan in 10 minutes might achieve the same thing with some added benefits (and granted, new downsides as well). In fact that is exactly what happened during the pandemic when Mealhero started to get outcompeted by these types of services springing up all over, in the end they tried to go the same route with pre-made casseroles, but unfortunately it was too late by then. This (and a bunch of other things) led to their untimely end.

If you encounter this, you can do three things:

Take a step back, revisit your CPS and either validate this new (non-hardware) idea by going back to Customer Discovery, or skip back to updating your product vision & user flow (at your own risk, since you didn’t validate your customers).
Decide your MVP should be a service (that excludes custom hardware components) you provide, allowing you to already sell in the space and get to know your customers. This will also strengthen founder-market fit over time and can be considered an extended "deep dive" into your customer space.
Double down on your hardware idea

Doubling down? Then let's get to work to to strip down your vision towards your MVP.

Core System Loop

Now that you know your core user loop, try and translate it into a core system loop. This means that you re-write them as system-level requirements. As discussed earlier, they can't include a solution and instead describe "what" the system does. Couple notes on writing them:

Write it from the Point-of-View (PoV) of the system and not the user.
Be concise: one function, one verb, no "and", …
Be precise: no ambiguity
Describe "what" it does, not "how": no solutions!
They refer to what the "complete" system does, so no describing of subsystems or functional groups

Note: I'm using the term system a lot, this can include multiple devices, services, humans and pieces of software. So what I mean by the last bullet, is that we will not specify which part of the system (certain device, an app, a person, …) performs the function. This forces you to remain at the highest system level and forces out any reference to a solution..

You'll notice that it will be very hard to do for some of the items on your list, this might mean they are in fact referring to subsystem and they are, in fact, not part of your system's core loop.

For the smart steamer example, they are:

The system provides the ability to order different frozen ingredients
The system knows which ingredients were ordered
The system can provide a list of recipes the user can choose from, based on delivered ingredients
Once a recipe is chosen to prepare, the system can identify which ingredients have been given to the system to prepare.
The system can prepare each individual ingredient according to the recipe instructions.
The system will notify the user once the dish is prepared
The system allows a removal of the dish from the system by the user
The system can be cleaned to receive new ingredients safely

Important to note is that at this point we're still excluding alternate user scenario's such as a first use setup, a yearly maintenance or a decommissioning. For small-scale MVP's you'll be providing a lot of hands-on support, so it matters less to have a dummy-proof product that users can setup all by themselves.

To manage this, it's helpful to use the Feature List, it's the list I mentioned earlier in the article to use as "dumping ground" and is a lean precursor to an actual Requirements & Test Plan and is a growing and evolving document (until it isn't). So it might be you've already populated it to a degree.

Download the Feature List

It looks like this:

For now we will mainly focus on populating the columns and sticking to the core loop, we won't do any heavy ranking with the values just yet.

Write down your core loop items in the "Functions" column and assign them "Level 1" in the first column. Group them at the top.

Now there are gonna be a bunch of other functionalities most likely, either from using it earlier during interviews or from ideas that came up during working out the loops. Some of these will be sub-requirements of the core loop (like a "visual countdown element" or "machine washable components"). Most of these will be secondary or tertiary functionalities, springing forth from the core loop, and yes, you could nest these and whatnot. But for now ignore that, you want to identify those high level functions and focus on them. So move all other items down and assign them a "level 2" for now.

In the “Customer Value” column we try to assign a score from 1-5 based on the level of value it creates for your customers. The scoring you give should be clear from the interviews you've had earlier. If not, go back to your customers and find out. There are several ways to approach this (card ranking, MaxDiff,…), but we won't discuss that here and now.

To start off, assign the highest values to the requirements that are a key part of the core loop. Ask yourself this: "if our system is incapable of this function, does our system become unusable? If it's missing, is there no longer a point in launching the product?". You'll find that most of the core loop (if you made it right) will receive the highest score, but really try to be honest with yourself here and weed out the "nice to haves". As you can see in the example, the notification for instance is up for debate, but made the cut.

Solutions

Now we turn our focus to the ”Solutions” column, start filling in the field on how you're planning on providing the solution that enables that function ("how" does the system do this). For now, start with your ideal vision of the product from the first step, you can be descriptive, formatting doesn't really matter right now.

While doing this I would always recommend to start visualizing it in a "solution diagram". A simple visual representation of the main building blocks of your system and how they function, describing the chosen solutions.

Solution Diagram of Mealhero Product Vision

The visuals typically lay bare interfaces which will spawn new functional requirements around things like connectivity, interfacing methods, etc… Again, these are secondary, you can add them to the list for future reference, but at this point they'll most likely be lumped in in with the description of your solution.

Next you're going to identify the investment this is going to take. Focus only on the highest value requirements. Now "investment" is a broad concept, at this point we're specifically looking at both CAPEX and development effort (Non-Recurring Engineering or NRE) required. You can talk to your technical team, freelancers and manufacturers to get an idea about this. First let them identify the absolute largest one on the list and next the absolute lowest one in the list, everything else is in reference to those two outliers. Most likely these guys will already start making suggestions on how to improve that rating, but we're not done yet.

Until now we've looked at your vision of the product, with all the bells and whistles, but for your MVP, all core requirements must be brought down to the absolute minimum in terms of "investment".

There are two things you can start looking at: OTS & Concierge.

First: what are off-the-shelf (OTS) solutions you can use that satisfy the functionality? To quote from my article on “8 Rules for Building Consumer Hardware MVPs”.

We want to do things that don't scale, this means:

You don't want to have invested heavily in CAPEX to create parts that do scale (think injection molding, PCBa's, but also custom firmware, …)
You want to be able to adapt your MVP quickly to react to customer feedback

As such, it should exist almost entirely of off-the-shelf (OTS) components. Meaning Raspberry Pi's over PCBa's, 3D-prints over injection molding, … you get the idea. Sometimes you even see that competitive or similar existing products are used to hack them into an MVP, which might feel weird at first, but you're simple capitalizing on all the work the competition has already done for you! You can even sometimes white-label existing technology with a few add-ons of your own

Second is using a concierge approach, I'm quoting the same article:

In almost all cases, you can replace the hard parts with a human. There are countless examples of this, what is known as a "concierge MVP" and it's one of my favorites. Here's a notable example:

Nest Thermostat

Early prototypes had remote operators monitoring and adjusting temperatures
Helped develop the learning algorithms by understanding human decision patterns
Manual intervention validated the concept before full automation

Because while OTS components are nice, they do come at a higher unit cost, not unimportant as we plan on selling these things later down the line. Although you should mostly ignore unit cost at this point, you're currently in a position where you have more time than money and a concierge approach allows you to leverage that for your first few customers to replace hard and/or expensive parts with a (behind-the-scenes) service.

Now using these two tools, try to get the "Investment" scores of your highest rated requirements as low as possible, you'll most likely think of several options for each of the functions. Now you can create (several) new solution diagrams and start comparing them based on pro's and cons, the most typical trade-offs will be in the unit cost department.

Some examples for the steamer below going from full custom with injection molded parts and custom electronics to a bare-bones frozen meal delivery service.

Before moving forward, you will have to decide on one of the several solution diagrams you've made. This can be based on user feedback, the pro-con list or just common sense. Whatever the case, lock it down before moving further.

MVP Definition

In this stage you will further define and flesh out your MVP and end up with a more complete Feature List, different levels and all. During this time, you will most likely be reusing several of the tactics from the previous steps when adding more detail and describing more features. Rinse and repeat wherever necessary, moving back and forth between problem (by getting customer feedback) and solution.

The goal here is to get to a point your team has a shared understanding of what the MVP should do. We are NOT building an actual Requirements List & Test Plan yet, we want to keep it lean and just need to know what a functioning system looks like.

The first step is to simply look at your solution diagram and start naming subsystems and functional groups. Be sure to use these names consistently across your document in your “how” column.

Second, create a functional diagram as well next to your solution diagram to help keep you grounded on the “what” side of things and ensure there remains enough flexibility to change solutions along the way. Same thing here, try to use names consistently across the document in your “what” column.

You can create as many levels and nesting in your Feature List as you like, but try to keep it simple for now. To avoid diving head first in the rabbit hole of requirement management, I'll just leave it at a few simple guidelines for your levels:

Keep it simple, the goal is to get a shared understanding of a functioning system. We are not creating a full-fledged Requirements & Test Plan.
A lower level (child) is always linked to a higher one (parent) and is a further detailing of the functional process.
A child requirement can never have a higher customer value or investment score than its parent.
I would advise not to go beyond two levels at this point

The point is of course to focus only on high-value functions of which we can get the investment as low as possible, so regularly rank for these two parameters and adjust your focus accordingly.

It will happen that you will get in an argument over whether or not a certain solution should be favored, even if it requires extra investment. At this point, it becomes useful to start thinking about the "why" of the requirement, which in turn might change your “what” and “how”.

A typical example is when it relates to connectivity. For the Mealhero MVP you could consider how to solve the connectivity function.

Why are solving it like this? Why are we using Wi-Fi for the connection? Plugging in a network cable is technically less complex and we wouldn't have to worry about EMC certification?

Well, because most kitchens don't have a UTP port available. However, you need to know this! By which I mean it needs to be proven as fact. Let's say the selected audience is families living in rural areas: they have little time and typically own a large, dedicated freezer that they have in the pantry. It just might be that most of them would prefer using the steamer there, near to the freezer and it just might be that they typically have their router in the same area. Now it becomes a completely different story. But it needs to be scrutinized and checked with potential customers, it needs to match the use case.

Simple rule of thumb for your MVP? If it adds cost and complexity, it needs a damn good reason to exist.

The Polish Pitfall

There's a pitfall when it comes to "polish" or rather how finished your product looks and feels in terms of UX/UI and industrial design. A lot of founders tend to overemphasize this in the MVP stage.

If you’re succumbing to the urge, it might be informative to take a look at the Windermere Hierarchy of needs (aka the Buying Hierarchy or Customer Value Chain). Think of it as Maslow, but for products. It describes that when deciding on which product to buy between several alternatives, customers will walk down the hierarchy. If all alternatives they’re considering score equally well in a category, they'll move on to the next one and so forth. Until they hit an instance where one of the alternatives is the clear winner, on which they'll then make their decision.

Windermere Hierarchy of Needs, Customer Value Chain, Buying Hierarchy — *Windermere Hierarchy of Needs*

So deciding how much polish you need will really depend on what the alternatives are for you customers. It'll also give you an idea of the maturity of the market you're in and how disruptive you're really being. The higher up you are, the better of a position you're in (and the jankier your MVP can be). If you find yourself competing on price, an MVP might simply not cut it, and to be honest: your solution might not be that great as you think it is.

As an example, the first generation of Roomba's were notorious for breaking down a lot, there were reports of customers who had to return it up to 6 times in the span of a couple of months, and they were still extremely happy and excited about the product! Because at the time, no-one else was offering this functionality and they had amazing product-market fit. So the reliability wasn't there (yet), but it didn't matter!

So ideally you're squarely in that first level, if you're in the second you definitely need to avoid custom development as much as possible and bank on OTS components and systems as much as possible.

If you're in the third, it really starts to make sense to have a polished UX/UI and industrial design, and that can still be a valid play! As discussed in Peter Thiel’s “Zero to One”, Apple consistently uses this tactic. If you're betting your 10x play on integration and usability, it definitely makes sense to spend some time on this and even involve a (freelance) designer to tackle this for you.

If you're in the last level you need to be very sure if you can in fact make a really big dent in cost as compared to others (again, 10x or bust). If not, you'll be outcompeted in no time given the maturity of your market and all your margins will melt away. And with consumer hardware, the only way to make that dent is go for scale, so again, an MVP is not really useful here and you're looking at the Scaled Track already.

The Mealhero MVP

In case you were curious about the Mealhero MVP, they took a middle ground (see the middle diagram from earlier as reference). For the compartments they used IKEA food containers with holes drilled in them. It used only a single heater, so all ingredients were chosen to have about the same cooking time, thus limiting recipes for the MVP. All electronics were OTS (Raspberry Pi, LED Ring, touch button, RFID scanner, …), connectivity happened with an Ethernet Cable and everything was literally taped together with standard plastic profiles and parts.

So while in my opinion they could have gone even leaner, this was the path they had chosen. But unfortunately, they didn’t use it to prove willingness-to-pay and create proof-of-business. Bringing me to my next point.

MVP Track — Stage 3: Customer Validation

Willingness-to-Pay

Now, before we go off and build the damn thing, it's a good time to check in on the willingness-to-pay of your customers. At this point you can start employing different tactics from my article on “How to Prove Willingness-to-Pay”, but keep them small-scale. You have your product vision handy on one end and your MVP design on the other when you're going to reach out again to the pool of people you've already spoken to — and see if they're willing to pull out their wallet!

In this stage I would always suggest making sales in person as much as possible, you don't need a landing page yet, but it definitely can help for late deciders. Ideally these are people on your e-mail list already — if not: have them join. If they refuse it might be an early warning sign.

Then create scarcity and urgency: "Look, we're looking to launch a limited batch of 10 MVP's, sort of a "beta launch", If you're interested you can sign up for a small fee to reserve your spot?". Try and make an appealing offer since they will be trading in some level of comfort for a chance to be first to use your product. Things to think about are: offering them to be involved in development (always a win-win if you ask me), giving them a big discount, limited free trial, including 30-day money-back in your offer, allowing a subscription model vs. a complete purchase, cashback once they can switch to a scaled product, …

You can make this very attractive for you early customers, but be sure that they at the very least pay the small fee for the reservation and that they start paying within the first month of using your product. If you have a landing page, keep it handy to follow-up on those who didn't buy instantly or for sharing purposes.

First Build

Assuming you were able to get 10 customer to pay to get on the waiting list, start by building a first unit for yourself or members of your team. This is your classic iteration cycle of “design-build-test”. I'd advise you and your team to start using your own solution — eat your own dogfood so to speak — to make sure the main kinks are out by when you're shipping to customers.

In this period it's good to experiment with (pre-)paying customers coming in to provide feedback, have them test it out or even use for a couple of day in a row and journal about it. If you're doing it right, they will be hounding you the days after to ask when they can get it back.

Now to properly build and evaluate this thing, it’s crucial to have your team aligned on what a functioning product actually looks like. Since we’re still in MVP-mode we don’t want to go full-blown Requirements & Test Plan, but we’ll do need a little more than the Feature List of before.

Here’s where the Lean Product Requirements Document (LPRD) comes in. I lifted the basic structure from Ben Einstein over at Bolt VC and made some tweaks to it to better match my own workflow. It’s honestly one of the most easy to use and clean documents on this topic I’ve ever used (and I’ve designed and used quite a few of these type of documents, so props to Ben!).

It’s a great way to start on your requirements without being overwhelmed and is perfectly suited for the MVP Track. It’s only five pages and you’ve already done a ton of work that will make filling it out a breeze.

There will be things you don’t know yet, but that’s okay. For now just mark those with a “TBD” and figure them out along the way.

Download the Lean Product Requirements document.

First Batch

Okay, let's say you've worked out your first MVPs and they are humming along nicely for you and your team, meeting the requirements well enough. It's time to build your first set of 10 and ship them to your users — giddy!

One of the most important things to do here is be sure you can provide the best customer experience ever. That means being there for the first use and giving them a personalized experience, you and your team need to be on call 24/7 to fix any issues that your paying customers might have in the fastest way possible, go onsite as much as you can.

First you need to make sure you can be reached very quickly, so include a phone number on the product they can call, or a QR code to scan. If it's mainly touchscreen based you can even bake in a "help" button on every page that connects straight to you.

Second, when you're doing a field intervention, be sure to always pack a spare unit in case you can't fix it on the spot. Also, don't be stingy, recognize that it's been inconvenient and offer discounts, extra's, extend their free trial, … People need to love your company.

Also make sure you choose an appropriate strategy if it comes to certification and be transparent about it towards your customers, they have a right to know. Check out rule #8 in the article on MVPs to see what your options are.

Remember, this is the part where you'll learn the most. You'll face a lot of unexpected failures, but that's good. As long as they happen now and not when you have thousands of units in the field. Now you can start scaling up step-by-step in batches of 10 (or whatever works for your). For each new batch you can experiment with sales, marketing, prices, revenue models — in a controlled fashion — as well as optimizing your MVP's design along the way.

Of course there's still an elephant in the room. More likely than not, you're operating on negative unit economics. If you're working with subscription models, you can compensate by spacing your batches to optimize cash flow, but in each case, you'll be burning money in this period. This is why testing your pricing and revenue model is so crucial right now. You need to see how high you can price it until about one in three people don't take the offer only because of price. So plan your cash and batch sizes accordingly.

During this period, spend time on researching what the unit costs might be when you go for a custom development, talk to similar start-ups that already went through it, engineers, designers, manufacturers, … to get an idea on what's possible in terms of COGS. You'll still get it wrong by a big margin, but it'll be the best bet you'll have at this point in time.

Finishing Up

Remember, the goal right now is learning and proving WTP. Once you're getting diminishing returns on either, it's time to review and work out if you can build a scalable business out of this, then it's on to scaled development. Since you'll have paying customers and can prove you just need the money to scale that operation and bring your unit economics down (not use it to de-risk the market), you'll have much better chances at finding external funding for your operations.

If you achieve proof-of-business, now’s a good time to rewrite your LPRD for your scaled version (V2) of the product.

This will be a great starting point for when you're diving in to scaled development with a team. Look at it as a high-level summary of what your V2 should be able to do, you can get much more granular later in development, but this is the leanest way to talk about requirements with other people and ensure there is a shared understanding.

The next parts in the series will cover the Scaling Track, but as of now isn’t finished yet. Need more info on that topic anyway? Feel free to reach out.

How to Develop Consumer Hardware (Part 2 of 4)