Seems fairly straightforward. If you're a veteran and worked on anything even remotely like product-to-market (where coding and industry standards are required), are not lazy, and had decent references, I'd hire you to do the job.
You wouldn't be doing this in a vacuum. You'd gather use cases and explicit requirements which you could build to instead of having to asspull this. There may be ruggedness requirements which you could easily build to with pilot groups (AFTER accounting for stupid shit in lab tests...if this is a product that will be used by grunts, they will figure out ingenious ways to break shit).
It is stressful, though, to do this work. But some people enjoy it/love the challenge. That's how it was at the last place I worked before the current place I am at.
If you, in particular, do not feel comfortable doing this stuff, even if you have the capability, you should not be thrown into it and you're making the right call. You have to be hungry.
Have you heard of those "black box" teams? They are thrown a problem and they have to make a device that solves a problem or hits a specific set of requirements? That's what this feels like. These feels more like an area for an experienced coder/engineer than your every day normal coder. Very similar to the last job I had: we burned people out and the people who stuck around had a specific type of personality that loved that work.
"Black Box" team actually sounds about like what this is. I get the impression from talking to the recruiter that the company doesn't have a "product" so to speak, they're the skunk works, refiner, and manufacturer for "product," whatever that may be. The term bio-med was tossed around in the description as well, so take that for what it's worth.
I'd love to be part of a team like that, but I'm not the kind of person that can or wants to manage it. My current job has taken me a good two years to go from "I know what this device is" to being able to sit down with you, talk about the test plan that the original contractor developed, what they were trying to accomplish with it, and why that didn't work and exactly what makes it the stupidest thing I've ever read. I feel like I now know more than the OEM, which can't seem to make it work.
I got into a project to be the lead guy on an ERP module I had only read about and learned OJT cuz they couldn't find anybody who had even read up on it. By the end I was writing documentation other people were reading to learn the module. Did it take a lot of reading, yeah. But was it worth it, yes.
I wouldn't mind doing that, but I'm not moving to take a multi-discipline senior project lead, especially when there are market deliverables required.
(post is archived)