top of page
Blue Engine
TheRoad Logo


Product Management. Hands On Consulting.

  • Writer's pictureYoel Frischoff

Physical Products: Early Validation is Key

Updated: Apr 9


PM for the Physical World Series: Part V

The requirement pyramid. Ashby, M., & Johnson, K. (2003)
The requirement pyramid. Ashby, M., & Johnson, K. (2003)

Important disclaimer:

All charts shown are for illustration purposes only, and do not represent factual data or research. They were generate via prompting GPT4.0 with the open questions in the titles, and were then developed via dialog with the LLM.


Early Validation - Critical for physical products

Throughout this series, I hope I made clear of the "one-shot" nature of physical product launches. The resources required are high enough to sink most ships. An established company may take the blow, but for startups for which the launch is of their first and only product, any failure could be one too many.

This is different to pure software products, which are by nature much more agile, and could pivot at a tolerable cost and over a reasonable timeframe.

This is all to demonstrate why timely validation is so important for physical products, and by "timely" I mean: before unrecoverable resources and precious time are spent.

The questions for validation, though, remain the same:

  • Do users need your product?

    • Does your product fulfill its functional promise?

    • Is it safe?

    • Reliable?

  • Can users make use of your product?

    • In all of its usage scenarios

    • Does it require appropriate level of training (as in self explanatory for consumer goods)?

    • Do you offer adequate support?

  • Is your product perceived favorably by users?

    • Can your users experience your unique value proposition?

    • Is your USP in synch with your positioning?

The challenge with physical products is how to expose them so that validating signals are strong enough.


Cyclebe - A cautionary tale

The problem

This bicycle positioning beacon was born to answer a major safety need: Riders cycling along country roads risk being swept aside by car and truck drivers bypassing them. A potentially fatal hazard, tragically materializing more often and not.

The solution is a dual facing system, collecting positional data from a GPS enabled device, sending them to the cloud, where navigation software access these data so drivers are aware of pelotons and drivers ahead.

Great idea, which was initially materialized as a mobile app. This solution, though, encountered headwinds: Battery life turned to be too short, and other sports applications, namely Strava, started to provide a very similar functionality, eroding Cyclebe's competitive advantage.


The company decided to look for hardware as a differentiator - a physical device, that would pack the location and mobile communication (a GPS / M2M cellular module) with a strong taillight - all within an iconic packaging.

As we moved along, the industrial design of the unit was completed, engineering issues addressed:

  • Shock resistance

  • Water tightness

  • RF communications (m2m module)

  • Battery life cycle and charging

  • Taillight stroboscopic elements

  • Prismatic lense

Initial prototypes and mockups were built:

We also performed initial unit economics:

  • BOM (Bill Of Materials)

  • Labor costs

  • Packaging, shipping

  • NRE (Non Recurring Expenses)

    • Production tooling

    • Testing equipment

    • Minimal inventories

All these to establish unit costs (as a function of quantities produced), and to find BEQ (Break Even Quantities) that would be the lower limit to production, to serve in the go-no go decision.


What did we fail to take into account?...

  • Users willingness to pay: This device's BOM poses a hard lower limit on cost. Would users pay this non trivial amount?

  • What would be the cost of the alternatives / competing products? As it turned out, virtually $0...

  • What were the trends in this domains? Here too, mobile phone turned to be the Swiss army knife, that may not excel at anything, but can do most things satisfactorily.


Lessons Learned

Decision time has come for Cyclebe, and - attractive as it may look and feel - the company had to kill it off.

There was no way the additional cost would be justified by users, and the significant effort required to develop this multi disciplinary product turned to be redundant.

The lessons learned, though, is that sometimes one must explore ideas by developing them. This is how you unearth hidden costs, physical obstacles, engineering constraints.

This is how you can find out about your up front (NRE) and current expenses (unit economics), and how you learn about the problem you are solving, through early validation, and early go-no go decisions.

In established companies, this is part of the innovation effort, budgeted to run similar experiments, picking one of many to progress to manufacturing and launch.



85 views0 comments

Recent Posts

See All


bottom of page