How quickly was the Proceq GP8800 developed?

How quickly was the Proceq GP8800 developed?

19 April, 2021 2 min read
product development, trade-offs, innovation, agility, Lean, engineering, teams, conflict

The Proceq GP8800 handheld SFCW wireless (to iPad) radar

A friend recently asked me how long it would take to develop a physical product. My answer: way less than you think; if you do the right things the right way with the right people.

Except of course if you do things the way you were taught in your studies or in a company with a phase-gate process, or by jumping from stand-up meeting to stand-up meeting in some misguided sense of “agility”.

I used to work for a fantastic company that, for all it’s fantastic qualities (seriously, best company I ever worked for—besides TECTRA Ltd, that is), prided itself immensely on its mega-checklist of a product development and launch process.

Imagine spending 3-5 years to develop an innovation like this one above. Nonsense.

So, how quickly did we develop Proceq GP8800 when I was working at Proceq (now Screening Eagle Technologies), including adapting the “Proceq GPR Live” app for iPad to the new product?

The precise answer would shock you, and due to my NDA I wouldn’t provide it anyway. So let’s just say that we are not counting in years, but in months.

We didn’t use old-school Requirements Engineering, stage-gate deliverables, gate meetings, or any of that stuff that you learn in an auditorium.

How was it possible to go that fast and still deliver an innovation that is both disruptive in terms of technology (far better than anything else out there) and business model (you buy the probe, the probe is yours, but you commit to 2 years of software subscription, and you can always access your data, even without an active subscription)?

Here’s the semi-answer: Lean Product Development. However: we never called what we do “Lean”, “Agile”, or by any such buzzword.

I prefer to focus on principles, instead of pontificating endlessly about Toyota This or Toyota That.

In particular: the principles inherent in set-based concurrent engineering, such as trade-off curves for the most important aspects; creating optionality through lots of conceptual prototyping; customer involvement from the earliest moments; fast iterations.

Most importantly: a project team with competent individuals with Mastery, Autonomy and Purpose, ready to lock horns and work things out in productive conflicts.