Eng-Tips is the largest engineering community on the Internet

Intelligent Work Forums for Engineering Professionals

  • Congratulations waross on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Design inputs from marketing - any existing strategies? 4

Status
Not open for further replies.

NateBME

Bioengineer
Apr 15, 2009
4
0
0
US
My company specializes in contract manufacturing of medical devices, but have done many development projects for our customers. We have a new drive to develop our own proprietary products based on inputs from our marketing/sales team. There has been a lot of turbulence in this because the expectations of marketing are not in sync with the engineering development steps (discovery, planning, testing, design iterations, etc).

Clearly some procedures need to be in place to get everyone on the same page. I was wondering if there are any industry standards out there that I could start with or read up on to help form our own program.
 
Replies continue below

Recommended for you

This bodes ill.

The medical marketing people with whom I tangled for several decades could all provide a good synopsis of what is being offered in the marketplace, right now. ... which is pretty much what they presented as market needs for the future.

That outfit's gestation time for a new product ranged from three to twelve years, with a median around five years.

I could never get <pejorative> Marketing </pejorative> types to understand that we needed a window into the market, five or more years into the future, in order to have a chance of meeting the market with a competitive product. All I got in response was blank stares, or worse.

Fortunately for that outfit, The Founder maintained such a personal window into the future, and also used a scattergun approach where he had maybe a hundred pirate projects going on, under everyone's radar, asking and answering forward looking questions like, "Could we build a machine to make a Magntic Resonance Image of a single cell?". I was privileged to be one of his pirates.

Unfortunately for that outfit, The Founder died. ... which is why I don't work there anymore.

Its remains were just sold, again.



Mike Halloran
Pembroke Pines, FL, USA
 
The only thing worse than marketing is when sales does the marketing. all sales really knows is why they lost their last sale, and that they want one like the competition's, but better, but not different.
 
I think there is a lot of documentation out there on NPI New Product Introduction methodologies that would help capture the needs. Like most of these things, they formalize & bureaucratize common sense. But then, when did those folks in Marketing or Sales ever apply common sense to engineering tasks? [wink]

But seriously, much of the Six Sigma & NPI stuff freely available on the web includes discussions & methods for capturing customer / marketing / sales input in a formal way. The challenge is that it is (in my experience) a grindingly slow, tedious, many-meetings-required, poorly-facilitated process and it usually gets ignored or under-resourced to its ultimate failure as a useful process. Nothing less than an Edict-From-On-High would force that group to undergo this process.

TygerDawg
Blue Technik LLC
Virtuoso Robotics Engineering
 
Most of our product ideas come from the field - builders, sales, etc.

Fortunately we are not tied to them and can proceed in our own way - WHICH works well.

My biggest bitch is that one we meet ALL their expectations - they DON'T use it!!
 
As tygerdawg says there are materials (including training programs) on "Product Lifecycle Process" & "Phase/Stage Gate Process" and various other ways for getting from 'someone has a bright idea/a possible market need is identified/we need a new product to make us money' through robustly defining the need, defining the requirements, proof of concepts, prototypes, testing, iteration, release to production...

I think some of our managers got training from Cadence Management Corporation - though I'm not saying that's an endorsement from me.

As the end of the day tygerdawgs second paragraph pretty much sums up my experience.

You may find some stuff in forum768 for instance thread768-272985.

Posting guidelines faq731-376 (probably not aimed specifically at you)
What is Engineering anyway: faq1088-1484
 
My outfit suffered an infestation of MBAs, who implemented a Stage/Gate NPI process. At about the same time, they got rid of all the people associated with the old process, the ones who understood the core technology, and basically sat around for ten years, waiting for outfits like the OP's to show up at the door with tooled, mature, developed products for them to badge-engineer and sell.



Mike Halloran
Pembroke Pines, FL, USA
 
You might contact or at least investigate the folks at the Product Development and Management Association.


They used to advocate the engineering and project management end of things, and had some program literature that helped get the non-technical development drivers (marketing, sales, finance, upper management) to understand the process.

I say "used to" because I haven't been in that game for quite a while.

Sometimes, the hardest part has been getting buy-in on the impossible-to-know parts of the Gantt chart. UL turnaround time? And oh my goodness, does your medical device have to go to FDA? What might be the lead time on the specialized processor that you haven't chosen yet? Those can be tough.

Best of luck and a barrel of serenity to you.

Good on ya,

Goober Dave

Haven't see the forum policies? Do so now: Forum Policies
 
A stage gate is where a time-to-market advantages goes to die. Of course, most places I've worked with that claim to use a Stage-Gate process don't use it as intended or don't really use it at all. Which begs the questions:

Why bother with the bureaucracy and cost?

Might there not be planning and execution techniques that could actually help?

Unfortunately, if everyone sits around, looks at themselves, and says, "We use stage-gate!" without questioning the value of it, they'll never get around to the second question.

Although a bit dated, one of my favorite books on the subject is Developing Products in Half the Time. It's available on Kindle.

Agile project management is a technique from software development that I've been experimenting with physical in product development.

Another software technique that I like to apply in product development - at least to establish a mindset and guide the continued development of a product or platform - is refactoring. In software, there is even less of an opportunity for clean sheet design than in physical goods (see Borland, Netscape). Refactoring is making improvements to parts of the code as you go, which is aided by well defined interfaces, knowing how you would do "it" (there are many "it"s) if you could start from scratch, and knowing where you eventually want to be. I apologize for the vagueness. It's a subject that deserves more attention than this.

That said, sometimes you just have to make a clean break from evolutionary design. Evolution can produce a cheetah, but sometimes you get a platypus (TM Rob Campbell :)

One more general product development insight, regarding adapting/copying one of your own products or a competitor's to enter a new market or market segment:

It is difficult to profitably scale a high-end product/technology down to capture a piece of the low end market. This can be scaling down in a literal or figurative sense (e.g., format size or accuracy). Simply "smallening" the parts doesn't reduce the cost enough to maintain margins. And some customers who would have bought the high-end version if it was the only option will buy the low end (cannibalization). Typically, a more significant design departure is required to make it work.

Conversely, modifying a low end product to move up market and increase profits is often quite easy.

Rob Campbell
Imagitec: Imagination - Expertise - Execution

 
While I'm not exactly marketing's greatest fan, I'll bite the bullet and assume that they have done a competent job in identifying some requirements for the product. As engineers our job is to translate those probably rather woolly requirements into numbers that we can evaluate, and offset against other attributes like variable cost and time to market.

Systems engineering is the general formal field that encapsulates this, and SS and the like have nicked some of the tools and repackaged them.

In the end there is no real objective way of doing this, it really comes down to vision and experience of the participants. But at least the objective framework provides one way of structuring the process.

Having said that the first thing you find out is that customers are liars. Therefore marketing's input is often less useful than you'd hope. eg, if you ask people whether they'll pay extra for reduced fuel consumption, and how much, you can build a nice little model showing what you need to give in mpg per dollar. If you base your product plans on that you will be very sad.



Cheers

Greg Locock


New here? Try reading these, they might help FAQ731-376
 
When I worked for a panelized homebuilder, marketing got to pick colors and the pretty names, and that was pretty much it. It worked.
 
If I ran the zoo, there's one thing I would definitely include in the marketing input algorith: cost of changes. No change will be considered unless marketing understands that there are time and cost impacts with every change, and these impacts rise exponentially as the project progresses.
 
Their inputs are erratic and ambiguous from questionable sources and logic. But, they are the ones in the field having conversations and getting feedback. They are my eyes and ears. They can be useful, but I need them to sound and appear like presenters at a symposium. Right now they are more like children at daycare.

Also, thanks to everyone providing useful input on this post. I have looked into your suggestions and have begun developing with my team a process to improve our internal communication and ultimately product development outcomes.
 
Nate,

I big part of it is defining the requirements. We do it in a 2 stage process.

1. Marketing do their thing and come up with a Marketing Requirements Document. Here they summarize what they believe the market needs based on there analysis. We work with them to try and put in hard requirements or clarify points etc. but at the end of the day it's Marketing's wish list.

2. Once they're done we then take their input and turn it into the Product Requirement Document. In an ideal world there's not much change - except for adding a formal approval block! In practice we normally need to flush out hard requirements and pass fail criteria etc. working with Marketing. Often we'll have to try and summarize a great long PowerPoint into a simple table form or similar with specific requirements. We also take manufacturing & services initial input at this stage.

Once this PRD is done it gets presented at one of the stage gate meetings and then goes through formal approval loop from the great & the good.

Once approved, then the requirements are more or less frozen. We're not great at this, we often get a bit of scope creep without properly revisiting the PRD & associated approvals. Though in fairness this is sometimes because when we wrote the PRD we didn't know what we didn't know etc.

There has to be some ability to change the PRD based on significant new information but as Tick & dshandling say the cost and schedule impacts of changes need to be taken into account.

Posting guidelines faq731-376 (probably not aimed specifically at you)
What is Engineering anyway: faq1088-1484
 
That sounds similar to our process except we have far more stakeholders involved. In a five year program, defining the product specs occupies anything up to a year, although some of the studies that are generated in that time are useful down the track (hopefully the one I've put most effort into is the one chosen, leaving the conundrum that in this 5 year program the vast proportion of interesting work is done in the first year or so, the rest is just polishing the apple).

The idea is not that we have a perfect crystal ball, it just means there is some logic in the direction at any point in the program. So it may be necessary to make late changes to the spec, whether from legislation, or a competitor raises the stakes, or the environment changes.

Cheers

Greg Locock


New here? Try reading these, they might help FAQ731-376
 
Greg, we have more 'stake-holders' - or at least more approvals - too, I just summarized a bit for brevity. I think there's something like 10+ approvals needed for the PRD from a corresponding number of departments/sub-departments/management levels.

For instance, in the later stages when I say marketing it also includes sales and applications folks. Likewise manufacturing includes purchasing/supply chain management, manufacturing engineering & operations.

Posting guidelines faq731-376 (probably not aimed specifically at you)
What is Engineering anyway: faq1088-1484
 
Status
Not open for further replies.
Back
Top