Blog Archives

The Entrepreneur And Product Development : Lessons Learned

Inventor, Product Development, Prototype, Lawn MowerYou might remember that we helped Entrepreneur Steve Hartman with the product development on his Cyclemower, a product that eventually ended up being featured in the Inventors Spotlight at the Las Vegas National Hardware Show. It’s time to check back in with the Entrepreneur Mr. Hartman and the Cyclemower to ask a few questions pertaining to product development and lessons learned along the way.

Q: Steve, what have you learned about product development?

A: The learning curve on prototype development is a long one, which I am still going through. At first, I had a design in mind, which I though I could just kick out and be done with it. I soon learned that there were a number of design details, at least with a relatively complex product like Cyclemower, that caused one problem to exacerbate another. With my first prototype, I was looking to prove that I could achieve my expected blade speed, which I succeeded in doing. I was unable to cut grass with it, and the design was really ugly. When we finally got to our current design, it was still not what I initially envisioned, but it had all the functional elements. It not only spun the blade at speed, but we eventually were able to cut grass. It has a cool look as well, but we also have found a number of weaknesses that makes it unsuitable for a final product. Notably, its too heavy, and the bottoms of the sideplates drag on uneven terrain. This causes the blade to stop spinning. We also can’t seem to get the back roller to function, so we can’t establish an even cutting height. For demonstration purposes, we are basically limited to perfectly flat and well tended lawns, which are hard to come by. To summarize, I think the biggest thing I learned is that the details never stop, and you can never assume that you have figured them all out.

Q: What did you learn from attending the Las Vegas Hardware show?

A: I learned from the hardware show that it is not necessarily a good place to find manufacturers who want to invest design and engineering resources into a new product. The hardware show is a good place for existing manufacturers to show their products to distributors and retailers.

Q: When building a product again, what will he do different next time?

A: If we need to develop another prototype, it will become all about the details. We will want to take all the shortcomings we have learned from our current design, and eliminate them, one by one. We will also want to directly compare ourselves to our competitors, in order to point out the superior aspects of our design. This is a long and tedious process, but one where nothing can go unaccounted for, no matter how seemingly insignificant. We will want our design to be perfect, from form and function all the way to packaging and shipping.

Q: Suggestions for others building hardware for the first time?

A: My suggestion for others would be to take a long, hard look at what you are trying to accomplish, and identify potential shortcomings in a brutally honest and thorough way. I can’t overstress the issue of details, as it only takes a small malfunction to make your whole design look bad. Have faith in your convictions, but take all the advice you can and apply good ideas that make sense to you. One thing I learned along the way is that there will always be people who will tell you how stupid your idea is. Most of the time, these people should be ignored. On occasion however, someone will come up with a legitimate criticism which should be considered and applied to improve your design. Inventing is hard work, and most people can’t do it. Quitting is easy, and most people do that all the time. There are so many obstacles to overcome in creating a new product, but you have to keep at it while maintaining faith in yourself. No one is going to succeed for you.

We would like to thank Steve for taking the time out for our Q&A. If you are an Entrepreneur entering the product development cycle, it’s great to hear from people that have been there and done that. They can help shed some light on the process of product development, prototyping and product marketing.

Need more information? Please contact us with any questions or contact me directly at joseph.donoghue ( at ) leardon.com

Tagged , , ,

Product Cost, Scope, Schedule: Prioritize or Fail

Joe Donoghue, San Diego Prototyping, Patents & Prototypes, Live Web Show, Product Development, Engineering Services, Manufacturing, Entrepreneurial Product DevelopmentProduct development and commercialization can be summarized as a balancing act between the competing constraints of product cost, scope, and schedule. Thousands of decisions are made while a product is under development and the end result is typically a sub-optimal result of these decisions. A consistent theme exists as a team moves through the process of bringing a product to the customer: it is virtually impossible to optimize all the requirements of the program/product.

Since optimization is impossible, it is necessary to prioritize the objectives of the project in order to ensure success. Without prioritization, the individuals working on programs will be pulled in opposing directions and will be continually redirected during the project, resulting in failure. Proper prioritization of product cost, scope, and schedule will result in success.

The three objectives of a program are product cost, product scope, and program schedule.

Product Cost refers to the many financial metrics, including total budget, cost of goods sold, gross margins, or any other financial metrics used on the project.

Product Scope refers to the product features that will be designed into in the final product.

Program Schedule refers to the amount of time available to complete the project.

Unfortunately, it is impossible to change one of these objectives without affecting the others. The cost, scope, and schedule each act as constraints and therefore movement of one affects the others. This is typically referred to as the project management triangle by program managers.

How do you manage a project knowing that everything cannot be optimized? The management team at Leardon Solutions has managed hundreds of programs using a simple method of prioritization which requires that the team takes away the constraints that will cause failure. This method requires thinking of the cost, scope, and schedule in terms of three levels of priority.

a) Determine which of the three program objectives is the most important. This chosen objective will be the first program priority that must be constrained and cannot change under any circumstance. For example, if the product being developed is for the snowboard market and must be available two months prior to the skiing season, the program schedule should be chosen as the highest priority. The team must make changes to the product scope or product cost in order to meet the program schedule.

b) Choose one of the two remaining program objectives that can change but must be held within a range. After the top program priority that cannot change under any circumstance is chosen, there are only two objectives left. The second priority should be thought of as an objective that can be modified but should always be kept as close to the goal as possible. In the snowboard example, program schedule is the top priority and everything else must adapt to meet the program schedule. If all similar products in this snowboard product category have a retail price around US$50, this product might also need to be close to this retail price. It might not be possible to hit this price exactly because of the rigid schedule constraint, but the product cost should be optimized by minimizing the product manufacturing cost or modifying the gross margins.

c) The outcome of the last program objectives will be accepted as is. Unfortunately, since the first program priority was constrained and the second program priority was optimized, there is no ability to control the third program priority. The program manager must accept whatever results from the actions of constraining and optimizing. For the snowboard product example, the product scope is considered the third program priority. The product designer might have wanted to include a small injection molded plastic toe bumper on the front of the product to improve the looks of the product and prevent wear of the toe. But due to the schedule constraint (injection molding tool has a six week lead time) and the product cost optimization (this additional part adds cost), the design engineer should not include the toe bumper in the design.

Some hard tradeoffs need to be made when prioritizing the program cost, scope, and schedule. By performing this exercise and communicating the priorities, the product development team will be given very clear objectives that allow the members to make their own tradeoffs knowing the overall program priorities. This will result in successful programs for both large and small projects at companies of all sizes.

Tagged , , , , , ,

How to Properly Define Your Product

Joe Donoghue, San Diego Prototyping, Patents & Prototypes, Live Web Show, Product Development, Engineering Services, Manufacturing, Entrepreneurial Product DevelopmentWhen an inventor, entrepreneur, or company has a great product idea, they typically start out by constructing a prototype to prove the idea is feasible.

While this might seem like the logical first step, it should actually be the second step taken. The first step should be to document the product features and functionality so that there are product goals for the team to pursue. Without first defining and communicating the product features, the product team will be moving forward blindly while wasting time and money.

Leardon Solutions follows a rigorous Product Development Lifecycle and commercialization process shown in the figure below to ensure all products achieve their product development goals and objectives. The first phase of this process, the Definition Phase, is sometimes thought to be the most important phase because it sets the stage for the success of the product. Without properly completing this phase, the team will be working without any objectives or goals for the product. A detailed list of the activities and deliverables that should be accomplished in the Definition Phase can be found in the Product Development Lifecycle presentation.

Leardon Solutions Product Development Lifecycle

Leardon Solutions Product Development Lifecycle. Copyright 2011 Leardon Solutions

To summarize, the goal in the Definition Phase is to do exactly what the title states: define the product thoroughly. An organization’s worst enemy in product development is vagueness and ambiguity. The engineers and designers need specifications and guidelines to properly complete their objectives and this phase provides the list of clear, concise, and measureable specifications. The two most important documents, the Product Requirements and Engineering Specifications, are described below.

Product Requirements: The Product Requirements, also known as Product Data Sheet or User Needs, is a list of performance, functional, and interface requirements that are focused on the customer’s point of view.  One way to compile a complete list of these requirements is to get the cross-functional product team together for a meeting and answer the following questions:

How will the product perform and what are the functional characteristics?

Will the product interface with other products outside of your control?

What are the industrial design requirements (the look of the product)?

What are the human factors requirements (the feel and human interaction of the product)?

Are there any installation, support, service, and maintenance requirements?

What type of qualification, regulatory, safety, and standards compliances are required?

Should the product be compatible with other products and if so what are these requirements?

What are the packaging, shipping, and labeling requirements?

This is just a short list of all the questions that will arise when compiling the Product Requirements document.  Of course, compilation of this document requires ample time and research but if it is done properly, it will be one of the most useful documents of the product development process.

Engineering Specifications: The Product Requirements document provided earlier is the first step in specifying the product with respect to the customer’s point of view. While this is very helpful for the product team, it does not typically provide an engineering team with enough detail to begin designing. Therefore, the engineering team needs to take these Product Requirements and translate them into Engineering Specifications. The engineers will use this document as they move through their design and development stages.

The simple example below demonstrates how to construct the Product Requirements and Engineering Specifications.

Leardon Solutions example product requirements

Leardon Solutions Product Requirements and Engineering Specifications Example

The effort required to generate the Product Requirements and Engineering Specifications might seem too detailed for such an early stage of product development. These documents are valuable resources that will be used throughout the product development lifecycle and will save the team valuable time and money by focusing the team on the proper goals and objectives. This is definitely a step that should not be skipped.

Tagged , , , , , ,