Keys to Successful Product Development

You want to see your product succeed. You want to see your company succeed. In order for that to happen, you also have to succeed in product development.

The major hurdle most small companies and startups face when it comes to product development? Limited resources, both in funding and expertise.

Winning the Product Development Race

Seeing an idea, a twinkle in an entrepreneur’s eye become a successful product is a dream come true. From the moment of enlightenment or the aha moment when an idea is born, the natural urge to rush as quickly as possible from concept to finished product can put that great idea and potentially successful product at significant risk. Critically important steps are missed or ignored and shortcuts are taken, all with predictable results.

In the world of successful product development, a tested, well defined and faithfully executed process is the glue that holds it all together. It keeps everyone on the course and on schedule. It is the thing that enables a great idea to become a truly successful product.

The starting point for successful product development must be a foundation that carefully and clearly articulates agreed‐upon requirements. The requirements must then be followed by a logical and disciplined sequence of development phases; conceptual design, detailed design and documentation, design verification testing, pre‐production, and production.

In the following pages, we describe the Finish Line PDS product development process and share our insight into what we believe are the keys to success

Innovation

Innovation may be necessary, but it is never sufficient.

Innovation is great. It will make your product more competitive; however, it will not “make” your product. Customers only pay for change if it is nicely packaged into a product that gets to market on time and for a reasonable price. For every 100 innovative ideas, only one is successfully brought to market. The scarcity is not in innovation but execution.

According to Fiona Patterson in her paper Characteristics & Behaviors of Innovative People in Organizations, innovative people tend to have certain personality traits:

  1. Openness to Experience: Innovative people gravitate to the unknown. They like a novel and new things and are less likely to be “campers” who are content to stay in their comfort zone. Note: This is also likely the reason that some innovative people are controversial; “novel” and “new” is akin to risk. Risk means you are more likely to fail, which opens you up to criticism, especially by those whose personalities are risk-averse. Hiring only people who have perfect records or who have no detractors is likely to exclude the truly innovative. Steve Jobs was not “liked” by most and was famously fired by a risk-averse “professional manager.”
  2. Disagreeable: Several studies conclude that the more disagreeable a person is, the higher the innovation score they are likely to have. It is probable that their “disagreeableness” allows the person to avoid groupthink, which is known to stifle innovation. Herein lies the critical lesson, some people on the team need to be innovative and others not so much. Innovators will innovate but not execute. Non‐innovators will execute but not innovate. We know that successful product development requires both.
  3. Inattentive to detail: Several studies found a negative correlation between being conscientious and detail oriented and being innovative.

Conclusion: Innovative people are not likely to be key drivers to successful execution and closure. Execution and closure require high social skills, organization, methodology, and attention to detail. These are not the personality traits of an innovator.

In his famous book Good to Great, Jim Collins argues that the first order of business is getting the right people on the bus and in the right seats. For start‐ups, understanding the need for innovators and executors and the difference between them is the key to getting the right people onto the bus and into the correct seat.

The research is clear that some cultures foster innovation and others stifle it. These cultural characteristics have been found to promote innovation:

  1. Tolerance for Failure: If the culture does not support failure, innovation will suffer.
  2. Innovation is valued at the highest level in the organization. The leaders of the organization, especially those at the very top, must both communicate and demonstrate that innovation is valued and needed to establish and sustain the organization’s long-term success.
  3. Collaborative decision‐making: Command and control organizations are not going to be innovative.

Product Development Process – Don’t Just Do It.

Despite being a very successful marketing slogan, “Just Do It®” is not the way to approach product development. Successful product development requires discipline and a proven process. Without a process, you are going to get lost, waste time, money and possibly even your market opportunity. Without the discipline to follow the process, it is unlikely you will ever truly succeed. In some ways, the “Just Do It” approach is analogous to going from Boston to Los Angeles by simply saying, “I will just head west”. You might eventually get there, but it will take longer and cost a lot more than having a plan and using a map.

So then, what are the necessary tools of a successful Product Development Process?

  1. Requirement Document
    This is where you define your goal in specific, quantifiable units; we will develop a product with these functions and features, that will cost $X, be ready for market by Y and cost $Z to develop. You can request our requirement document template Here.
  2. Conceptual Design
    A good conceptual design consists of a documented, high-level, well-conceived technology plan for implementing the product that, when carefully compared against the requirements, defines the optimum approach to meeting those requirements.
  3. Detailed Design
    The detailed design translates the high‐level conceptual design into engineering documentation and, subsequently, working units defined by that documentation. This documentation includes schematics, source code, CAD files, assembly drawing, Bills of Material, etc. This phase is frequently the only one that many inexperienced engineers consider product development and is the point where they want to jump right in and “Just Do It”. Their rationale, that “we don’t have the time or money for Requirements or Conceptual Design”, is flawed and has no basis in either theory or practice. There are a time and place for everything. The time for detailed design is always after the requirements and conceptual design are completed and aligned with each other.
  4. Design Verification
    This is the stage at which the contents of the Master Book, the repository for the engineering documentation and end product of the Detailed Design stage, are used to build multiple units for comprehensive testing. These units are tested against all criteria specified in the Requirements Document to confirm that the design, as documented, meets all its objectives.
  5. Pilot Production
    This is where you make a small production run and give/sell to a select customer base.
  6. Production
    This is where your hard work pays off and you start to make money IF you did all the previous steps correctly. If you skipped steps or cut corners, then this is the place where you recognize the loss of time and money spent on development conducted without a proven process.

Requirements Document – If You Don’t Know Where You’re Going, Any Direction Will Do

Someone once said, “humor is funny because it is true”. If you have been involved with product development very long, you can probably relate to the cartoon to the right. Lack of a clearly articulated and communicated vision of the product is one of the most common reasons for the failure of the project to obtain a Return on Investment (ROI).

The first step in the development of any new product is defining it. The initial definition typically comes from product management, marketing or the company’s designated visionary. Initial requirements often consist of a list of specific new features, functions, performance, and cost. The list may include new and revolutionary ideas but, more often than not, simply consists of comparative references, e.g. faster than X, better than Y, less expensive than Z, etc. Also common are ‘inverse’ requirements, “none of the problems or issues of product X, Y or Z”. Naturally, everyone ‘knows’ that the list is not comprehensive and does not include ‘all’ of the requirements. The tacit assumption is that the new product will automatically inherit all of the ‘good’ characteristics of its predecessor/competitor and none of the ‘bad’ ones.

While the list is not a bad place to start, it is all too common for this list to be the ending place as well. The requirements exercise often concludes following a few markups of the list with relatively little discussion or incremental substance or clarity. When described in this manner, it is obvious that the subsequent product development effort is destined to fail, or at best, produce another small evolutionary step after experiencing numerous changes, delays, and budget overruns. Despite the knowledge and experience of the development team, new product success is based on a common, shared product vision and the only way to establish and share that vision is to clearly articulate and document the new product before actual design begins. This is the primary reason for generating and maintaining a comprehensive Requirements Document.

What belongs in a Requirements Document?
Well, that depends on the product and the organization but, in general, the Requirements Document should identify and include descriptions of all of the features, functions, performance, and criteria that must be provided or satisfied for the product to succeed in its target market. This spans the gamut from the innovative highlights that will distinguish the new product from and vault it above the competition to the mundane nuts and bolts criteria without which the market will reject the product before the marquis features ever come to light. Consequently, the Requirements Document must go beyond Data Sheet highlights and clearly identify and articulate everything about the product that the market will ultimately demand. It is also important that the requirements are sufficiently well defined that they can unambiguously be interpreted by the development team at subsequent stages of product development and can serve as a checklist during final verification testing.

What does not belong in a Requirements Document?
That also is dependent on the organization. However, it must always be kept in the mind that the Requirements Document is simply a means to an end that clearly defines the common development goal. Consequently, it should concentrate exclusively on defining ‘what’ the requisite criteria are, not ‘how’ those criteria should be achieved. As soon as the Requirements Document team enters into discussions regarding the ‘best’ way to implement a feature or function, they have progressed beyond requirements and should move on to discussing ‘what’ else the product must include. Emphasis on ‘how’, as opposed to ‘what’, is one of the biggest impediments to the timely completion of a viable Requirements Document and often results in an inferior new product.

Who should generate the Requirements Document?
The best Requirements Documents come from cross‐functional teams that include representatives from sales, marketing, service, manufacturing, quality, and engineering. In addition, all requirements need to be objective, not subjective. They are measurable features, parameters, and outcomes that will be tested and confirmed during Design Verification Testing. Each member of the team represents a different constituency and conflict is inevitable. However, teams that can overcome their differences with creative and constructive compromise produce Requirements Documents and products that reflect the values of all these constituencies who, after all, are simply different faces of the same customer.

Why all this fuss over requirements?
The Requirements Document clearly articulates and documents the product and consequently forms the basis of the common, shared vision of the product. While that alone justifies the time and resources necessary to generate and maintain a Requirements Document, there is a more compelling reason for developing one. Generating a good set of requirements saves time and money and, typically, substantial quantities of both. The process of developing a Requirements Document introduces more in‐depth thought and consideration of the product that would otherwise occur at the front end of the development cycle. Team members stimulate and challenge each other and produce superior results over those of individual contributions. The requirements team can also identify risks, opportunities and alternatives early in the product development process long before the development team ramps up and extensive resources are applied. Consequently, product changes and improvements introduced during the Requirements phase frequently have relatively little impact on project cost or schedules.

Conceptual Design – How not to be Rube Goldberg

Have you ever been in the detailed design or test stage of a development project only to find that it is not being done the right way? It is not uncommon. If you are lucky, you may accommodate some minor corrections with a modicum of incremental time and cost. More likely, you face the dichotomy of making the design ‘right’ versus delivering something not-quite-right but closer to the original schedules and budgets. Sometimes, changes can’t be avoided. Often they can. At Finish Line, we have learned that many late‐stage revelations can be anticipated and the associated problems avoided if the development team is afforded time at the front‐end to explore beyond the traditional boundaries and consider the unanticipated. These are some of the benefits accrued from including a Conceptual Design phase in your product development process.

Conceptual Design: Why bother?
Many product development projects start out “behind schedule”. Whether it is competitive pressure, an upcoming trade show or an emerging, alternative new technology, virtually every development project has inordinate time constraints. Therefore, it is only natural to want to jump in and start the ‘design’ right away. For many, this Ready – Fire – Aim approach is the way to demonstrate a bias toward action and a commitment to timely completion. However, it can, and usually does, have consequences. Often these consequences do not become apparent until much later in the project when momentum is at or near its peak and course corrections are difficult, time-consuming and expensive. Consequently, what starts out as a focused sprint to deliver a great product can be reduced to a muddled meander to mediocrity. Our experience here at Finish Line PDS, spanning numerous new product development projects, is that a well-managed Conceptual Design phase is an essential step in all successful and timely new product development efforts.

What is Conceptual Design?
There is no universally accepted definition of Conceptual Design and it is, by its nature, contextual. However, there is some consensus that Conceptual Design is the stage at which the ideas that underlie the root solution are created and matured in a manner that is consistent with the requirements.

The Conceptual Design process typically consists of several steps:

  • Understanding the root problem addressed by the requirements
  • Understanding the requirements and why they qualify as requirements
  • Identifying and exploring a broad range of alternative solutions that address the root problem and requirements
  • Evaluating alternative solutions and combining the best aspects of each
  • Determining which solutions require invention versus engineering
  • Selecting a combination of alternatives that best solve the root problem and satisfy the requirements as well as the business objectives and limitations

It is essential to understand that the goal of the Conceptual Design phase is to identify and select the general type of the solution required and not fixate on design and implementation details. The result is a documented design approach to successfully solving the root problem in a manner consistent with the requirements. The final Conceptual Design must address all cross-functional disciplines that are essential aspects of the solution be they ergonomic, algorithmic, electronic, mechanical, chemical, software, human interface, etc. As such, the Conceptual Design serves as a common road map for each of the technical disciplines as they embark on the subsequent detailed design.

What are the benefits?
Conducting a Conceptual Design goes a long way toward ensuring that you are solving the right root problem. It is not uncommon for engineers and designers to jump right into a detailed design mindset immediately after glancing at the requirements and without examining the requirements relative to the root problem to be solved. This Ready – Fire – Aim mentality tends to be inversely proportional to the time available and is responsible for the delivery of designs that fail to solve the root problem.

The inquiry conducted as part of the Conceptual Design also serves to vet the requirements. The exercise of examining the root problem and the new product requirements with an eye toward its implementation tends to be a revealing one. Features, functions, and characteristics initially thought to be essential to the product’s success may be determined irrelevant under further scrutiny and investigation. Other crucial factors that may not be included in the requirements may be discovered. Consequently, a frequent byproduct of the Conceptual Design phase is one or more revisions to the requirements.

The creative and investigative aspect of the Conceptual Design process is the single most significant opportunity for real innovation during the entire product development cycle. Understanding the root problem independent of any specific technology and then applying creative thinking to alternative solutions facilitates innovative designs. Narrowly focused development teams who are not given an opportunity to think outside of their traditional technologies tend to generate the same kinds of solutions regardless of the problem or the requirements. As the old saying goes, “to a hammer, everything looks like a nail”. To a traditional design team with a Ready – Fire – Aim mentality, the solution to every new product can look a lot like the last one.

As anyone involved with the creative process knows, the first idea or solution is rarely the best. Brainstorming, iterating and building upon different ideas is an effective way of getting past the time-driven tendency of settling on the first idea that springs to mind. Even small amounts of time applied to this process can yield substantial returns in the number and quality of alternative solutions identified.

Finally, one of the biggest benefits of the Conceptual Design is objectively differentiating invention from engineering and removing invention from the product development critical path. Nothing undermines a new product development project more than expecting a critical invention to be made on schedule. It just doesn’t work that way! Conceptual Design can identify areas where an invention is required and at least provide contingencies for requisite inventions that are not ready on time.

What are the liabilities?
The liabilities of conducting a Conceptual Design are virtually nonexistent. The time spent on this phase is typically quite short and can range from a few days to a few weeks. It can often be performed concurrently with requirements generation. The portion of this time that is applied to gaining an understanding of the root problem and the requirements is necessary regardless of the inclusion of a Conceptual Design phase. What’s more, the time and resources invested in the Conceptual Design are typically more than offset by the reduction of subsequent revelations, changes, and invention-related delays.

Design Verification Test – Does it “Work”?

Does it work? I am sure you have heard this question asked many times. I am also sure you have heard many different answers depending on who is asked the question; the design engineer, the salesperson, the customer, etc. If you are like most people, you are left wondering who is right? Herein lies one of the benefits of following a comprehensive product development process. When a Design Verification Test (DVT) is conducted and verifies that each of the requirements in the Requirements Document has been satisfied, the product “works” and you have a clear definition of what “working” means.

Conducting a good Design Verification Test is essential. Consequently, a comprehensive DVT must be included in every product development plan. The general rule of thumb is to schedule an equal time and money for DVT that was spent in Detailed Design. These costs are typically subordinate to the cost of allowing a design defect to reach your customers. The cost of a design error that goes undetected prior to production or product shipment can rapidly escalate and ultimately take the form of manufacturing shutdowns, rework and/or scrap costs, product recalls, inventory markdowns, carrying the cost, brand erosion and more.

What is DVT?
Design Verification Test (DVT) is a comprehensive test program that objectively confirms that all of the Requirements have been satisfied. It differs from the Engineering Validation Test (EVT) performed during the Detailed Design phase on the engineering prototypes in both breadth and depth. The design team typically conducts EVT as a preliminary confirmation of design functionality and conformance to a select number of critical requirements. An independent team conducts DVT to confirm that all requirements are satisfied under worst-case conditions.

Design Verification Testing can include:

  • Functional Testing
  • Fitness for Use Testing
  • Performance Testing
  • Climatic Testing
  • Reliability Testing
  • Environmental Testing
  • Life Testing
  • MTBF prediction
  • Compliance and Regulatory Testing
  • EMC Testing and Certification
  • Safety Certification

Why Conduct DVT?

There are two primary reasons to conduct a thorough Design Verification Test on every new design. The first is a commitment to your customers and the second is your bottom line. You are promoting and selling a product based on capabilities and performance criteria that are reflected in its requirements. Your customers have a right to expect that your product meets or exceeds those criteria. Consequently, you must ensure that it does so before it reaches them. Regardless of the nature of your product, from the simplest to the most complex, your customers will use [abuse] it to its intended limits and beyond and in ways you never imagined or intended.

The second reason to conduct a thorough Design Verification Test program is economic. The ROI of a DVT program is the highest in the entire product development cycle. There is an adage gauging the cost of correcting problems in new products that states: It costs 1X to correct a problem during development; 10X to correct that problem in production and 100X to correct that problem after it is in the field. This adage does not even address the cost to your reputation when problems reach the field. One way or another, your product is going to experience rigorous testing. Can you afford to let your customers conduct DVT for you?

Who Should Conduct DVT?
As stated above, Design Verification Test (DVT) is a comprehensive test program that objectively confirms all of the Requirements are satisfied. The objectivity required to design and conduct a thorough DVT generally disqualifies the design team from participating. The team that designed the product cannot objectively test their own creation. For numerous reasons, the design team’s personal and professional biases could infiltrate the DVT process and potentially compromise their objectivity and undermine the test and its results.

It is also common for the design team to be actively engaged in the generation of corrective actions during DVT. Problems encountered during DVT typically require immediate attention and resolution by the design team. Consequently, having the design team concurrently engaged in both testing and corrective action is a scheduling conflict at best and a conflict of interest at worst.

Applying an independent test team to review the requirements, design and conduct a comprehensive test program, interpret and document the results and then repeat the cycle for the subsequent corrective actions is the most efficient and effective way to staff and conduct a DVT.

Keys to Conducting a Successful DVT

1. DVT Test Plan
A comprehensive, written test plan is essential to a successful DVT. The plan should specifically address every physical and functional requirement. It should include an unambiguous and objective means of testing each requirement, a quantitative measure of performance and an associated acceptance range or limits. The development team should review and approve the Test Plan prior to initiating DVT testing. The development team should also review and approve all subsequent changes to the plan.

2. Data Collection & Logging
A Data Collection Log that complements and accompanies the Test Plan is also an essential component of a successful DVT. The log should include entries for every test, the associated test data to be collected and all unique operating conditions under which the data is collected. In addition to being sound lab practice, the log provides a written record of the tests and the associated test results. Since the log is comprehensive, it also provides a means of determining what was not tested. Having the test and data as well as knowing what was not tested can be critically important in cases where subsequent manufacturing or field issues emerge. The comprehensive and well-documented log frequently provides a means to differentiate design from materials or workmanship issues and determine the root cause.

3. Review & Disposition
An objective review of all test results is essential. This is particularly important for those results that fail to satisfy the requirements. In general, corrective actions are required for all failures. After completion of a design change to eliminate the failure, all previously completed tests whose results may be affected by the change must also be repeated in addition to simply repeating the test[s] that identified the failure. In rare instances, the test design may be faulty or the requirement itself may be inappropriate or poorly defined. In these cases, it is essential that the team remain objective prior to changing a test procedure or waiving a requirement to accommodate a test failure.

4. DVT Closure & Design Approval
It is common for some DVT Tests to fail and some Requirements to remain elusive. This is particularly true when dealing with radically new or different products and technologies that have no precedents on which to base the expectations and requirements. However, it is essential to bring closure to the DVT and make conscious decisions regarding the project’s fate. Whether a small number of criteria absolutely must be satisfied before a qualified approval can be granted or the product design is deemed ‘OK as is’ regardless of the shortcomings, it is important to document the final state of DVT, the test results and the disposition. Corporate memory is short. Previous decisions to waive a test or requirement are often forgotten in weeks or months. Consequently, future decisions and even future projects and products based on imperfect memory can be compromised from the onset. Documenting all decisions, compromises, waivers, etc. serves as an antidote to imperfect memory.

Pre-Production Planning – Don’t just throw it over the wall

Even the best design effort is all for naught if the product cannot be manufactured correctly. Many projects have been ‘thrown over the wall’ between engineering and manufacturing, typically because the pressure to get the product into production exceeded the need for prudence. This is usually a failure of management, not engineering or manufacturing, and must be avoided. Planning for pre‐production that consists of an orderly transfer of information from engineering to manufacturing as a necessary and normal part of the development processes helps to guard against this failure of leadership. By insisting on a methodical, systematic transition plan and resisting the temptation to skip steps, you can ensure that you will “serve no wine before its time”.

Pre-production is the first phase of new product manufacturing and the final phase of the product development process. It is the first time that all of the final documentation is used to source, fabricate, assemble, test and qualify a new product in a production environment. Consequently, it is the ideal time for the development and manufacturing teams to work in concert to conduct a final vetting of every aspect of the documentation package. The net result is confirmation that the documentation completely and accurately describes all the materials and processes required to manufacture the new product in a manner that ensures compliance with its requirements.

What is Pre-Production?
Pre-production is typically the first time in the new product development process that a meaningful number of the new products are produced in a manufacturing environment under manufacturing control. It is also the first time that production personnel use the final production materials, assemblies, jigs, tests and accompanying work instructions and test limits. Prior to this stage, prototypes are typically built by a combination of engineering and manufacturing resources in small quantities, using prototyped piece parts and with limited assembly, process and test documentation. While pre-production quantities vary along with the nature of the product, pre-production often consists of 10 to 20 times the number of prototypes that have preceded it.

Why is Pre-Production Part of the Product Development Process?
Many consider pre-production the first phase of manufacturing a new product. At Finish Line PDS, we also view pre-production as the final phase of the product development cycle. The reason is simple. The primary deliverable of the new product development process is not the unveiling of the very first copy of the fabulous, whiz-bang, high margin product that will vault your company from the depths of obscurity to its rightful place atop its target market segment. The output of the new product development process is a comprehensive, accurate documentation package.

That documentation package must include all of the information required by a manufacturing organization to ensure the consistent production and reliable performance of each one of those wonderful products that are produced. Consequently, pre-production is the final opportunity to review and vet all aspects of a new product documentation package before production ramps up and the products start shipping to customers.

Are all the parts and the correct quantities included in the Bill of Materials? Is the latest software revision available for device programming? Do the labels reflect that revision? Is the PCBA package complete? Do all the components have the correct tolerance and form factor? Are all of the subassemblies included and properly identified? Are the assembly and work instructions complete and unambiguous? Are the test fixtures fully documented? Do the final test procedures identify non‐compliant product? Without an affirmative answer to all of these questions, it is unlikely that the new products will meet all of the requirements all the time! Without actually ordering the materials, using the intended manufacturing equipment, and following the assembly and test instructions, it is impossible to be confident of their accuracy and their viability as a roadmap to manufacturing and product success.

What is the Development Team’s Role in Pre-Production?
The development team plays a supporting role in pre-production. By definition, pre-production is a manufacturing activity. Manufacturing plays the lead role in all aspects of pre-production including materials procurement and sourcing, staging and staffing the production line, and performing the actual assembly and test processes required to produce the new product. The development team works closely with the manufacturing team in all of these activities. It stands at-the-ready to answer questions from the production team and its suppliers, address any issues and correct the challenges that arise. It works closely with the manufacturing team to be certain that all of the production criteria are clearly conveyed and understood. Consequently, this is also the point at which the development team provides additional clarification, information, and documentation that may be required.

What is the Value of Including the Development Team in Pre-Production?
Organizational theory has clearly established the importance of orderly transitions from one phase and/or team to the next. Finish Line PDS prides itself on the innovation of our product designs, the quality of our deliverables and successful transitions from our development to your manufacturing organization or partner. Despite our best efforts to the contrary, the complexity of today’s projects and the time constraints under which they are conducted means that mistakes can and will happen. Vetting the documentation package during pre-production is the earliest and most cost-effective means of identifying and correcting errors and omissions prior to production ramp-up. Catching issues at this early stage of manufacturing also keeps them in-house, preserving your reputation as a quality supplier and eliminating costly field failures or returns.

Product Success – It’s all about ROI

Let’s face it; most product development fails to live up to business or market expectations. Some estimates indicate that only one product development effort of every ten has a positive return on investment and that only one in a hundred meets the expected ROI.

Why?
Most product ideas start with someone with an entrepreneurial personality. They may be an actual entrepreneur starting a new company or they may simply be someone within an existing organization who champions a product idea. Nonetheless, they all tend to have certain strengths and weaknesses. Most successful product development teams also tend to have certain strengths and weaknesses. These tend to be quite different than those of the entrepreneur. Successful product development, defined as one having a positive ROI, is enhanced when those with an entrepreneurial personality are matched with those with product development personalities. Think Steve Jobs and Steve Wozniak. Although most of the fame related to the success of Apple is directed towards the extroverted and eccentric Jobs, without the methodical and OCD Wozniak, Apple would not have been successful.

Leaders who wish to improve the success rate of product development are well served by ensuring that first, they have the right combination of entrepreneur and product development personalities on the team, and second, they manage the inevitable tension that results when two such different personality types work in a highly stressful and close environment. Insisting that the team follow a well-defined product development process is the best method for managing this dichotomy. This is especially true for start‐up organization where everything else is new and unproven.

Winning the Product Development Race

At Finish Line PDS, we take the time to understand your specific product requirements, your customers’ needs, your challenges, and your goals. We create an environment of tight collaboration and teamwork to ensure we’re together every step of the way. By understanding your specific requirements, we create designs that meet your needs, starting with a requirements document that thoroughly captures and details your specific product. Guided by clearly defined requirements, our design team then creates solutions that are innovative, elegant and pragmatic.

Finish Line PDS services range from design through manufacturing with engineering and documentation processes that take you seamlessly from the concepting and prototyping through the production phases of your project. Our proven methodologies are customized to meet each individual client’s needs. Our clients know they’re getting expertise and experience, proven processes and detailed documentation to enable full‐scale and cost‐effective manufacturing on any scale. That’s why more and more companies are relying on Finish Line as their trusted product development advisors.

Our clients’ success is our only goal! So, contact the Finish Line team to learn how we can help you develop your product, and get it to market quickly and profitably.

About the author: Steve Owens, Founder, and CTO of Finish Line Product Development Services has over 30 years of successful product development experience in many different industries and is a sought-after adviser and speaker on the subject. Steve has founded four successful start-ups and holds over twenty-five patents. Steve has worked for companies such as Halliburton and Baker Hughes. He has experience in the Internet of Things, M2M, Oil and Gas, and Industrial Controls. Steve’s insight into the product development process has generated millions of dollars in revenue for start-ups and small businesses.

DOWNLOAD THE WHITEPAPER

  • This field is for validation purposes and should be left unchanged.