25
1 Entrepreneurship 101 Product Development Basics Steve Carkner November 2008

Product Development

Embed Size (px)

DESCRIPTION

Speaker: Steve Carkner, President, Panacis Medical Inc. Part of the MaRS Event Series, CIBC Presents Entrepreneurship 101. For more information and event video, visit: http://www.marsdd.com/Events/Event-Calendar/Ent101/2008/product-development-11262008.html

Citation preview

Page 1: Product Development

1

Entrepreneurship 101

Product Development Basics Steve Carkner

November 2008

Page 2: Product Development

Introduction to Steve Carkner

•  20+ Year product development experience •  Former Director of Product Development and

Intellectual Property Research at RIM •  Dozens of patents world-wide •  Principally an Electrical Engineer

2

Page 3: Product Development

Introduction to Panacis

•  Medical, Military and Consumer product developer

•  Full product development from napkin sketch to production

•  Many products launched from tiny “cooler light” sold at Walmart to a power system for a fighter jet, sales to U.S. Navy.

•  Profitable, high growth (100% P.A.)

3

Page 4: Product Development

Product Development Path

•  Does not matter how large or small – same basic path can be followed

•  Failure to have a plan WILL result in inefficiencies at best… complete failure at “almost the worst” case

•  Law suit is perhaps the worst case

•  Following a plan will dramatically increase the chances of success defined as the launch of a profitable, high quality product or service

4

Page 5: Product Development

The “V” Model of Development

5

Page 6: Product Development

Concept of Operations

Comprised principally of the idea behind whatever you are trying to do.

•  Who wants it •  What is it for •  Who pays •  What is YOUR capability in the area

6

Page 7: Product Development

Requirements and Architecture

Break down into separate documents with the first TWO being the most important

•  Customer / Market Reqs. – non technical •  Functional Requirements – more technical •  Product / Engineering Specification – technical •  Test and Verification Specifications – technical •  Issues found during the design phase may

change the technical specifications, but will rarely change the customer and functional requirements documents

7

Page 8: Product Development

Detailed Design

This is the most common product development activity to outsource

•  Well written, complete requirements and architecture documents will dramatically simplify this step

•  Larger programs are often broken up and assigned in a mix of in-house and outsourced models

•  Keep an eye on the Customer Requirements, ensure that design decisions do not impact these, it is the basis of your plan! 8

Page 9: Product Development

Implementation

This is the building phase •  Break into smaller, easier to test and validate

modules where possible •  Create a Statement of Work for any contractor,

clearly define tasks and reference back to the specifications

•  Any departure from the specifications, especially feature creep, should be documented and a revised SOW issued, otherwise unexpected invoices and departure from plan timelines will result 9

Page 10: Product Development

Suggested Tactic

Item # Description 5part@n Schematic Revision Level

PCB Revision Level

Mech Revision Level

Category How Fixed or Suggested Fix Open / Verify / Closed

Date Opened

Who open it?

Date Closed

Who close it?

4

Customer spec does not explain what Charge Enable signal is used for or if it can be ignored, we plan to ignore it. 0.0 0.0 0.0 Electrical

This has been clarified, signal is absolute requirement. Second procesor added to design to handle it. closed 26-Nov-07 Steve Feb-08 Rene

5

Cells have too much free movement inside housing and will easily tear connectors or slam into circuit board. New design required here. 0.0 0.0 1.0

Mechanical

Manufacture carrier boards that are taped to the cells to restrict free movement and support tab structure. Pot batteries into case. CLOSED 26-Nov-07 Eric May 23-08 Eric

6

LCD Display angle is incorrect, designed for 6-oclock view, should be designed for overhead view 0.0 0.0 0.0 Electrical

Increase drive level to LCD by clocking the COM pin at 180 degrees to the segmet pin. This dramatically increases contrast and looks great. closed 26-Nov-07 Rene 11-Mar steve

10

Create a tracking system at this point Any feedback can be reported, and tracked to closure Reduces design spin due to items “falling through the cracks”

Page 11: Product Development

Integration, Test and Verification

This is the Collection phase •  This portion of the program is the MOST

underestimated in terms of time and costs •  Budget should include the same amount of

time and cost for this stage as was allocated to the Design and Implementation phases together

•  Pull in the modules and work created by the team and start “plugging it together”

11

Page 12: Product Development

Integration, Test and Verification (cont)

•  It will NOT work the first time •  Most of the problems you encounter will tie

back directly to mistakes in the technical specifications, this is where a small mistake gets multiplied by orders of magnitude in terms of cost and timelines

•  Resist temptation to revise on-the-fly •  Fix the specification, revise the statement of

work, move forward again •  Only fix it once, don’t break something else in

the process 12

Page 13: Product Development

System Verification and Validation

This is where you take the fully assembled product and start testing it in real-world situations

•  Most of the problems you encounter will tie back directly to mistakes in the Customer Requirements

•  The most common complaint will be unexpected operation or interactions

13

Page 14: Product Development

System Verification and Validation (cont)

•  A detailed system verification plan (sometimes called a Design Validation plan) is key to ensuring every element of the customer and functional requirements document is satisfied

•  It is possible that a mistake at this point can invalidate most of the work done to this point

•  Example: A customer wanted a system to operate a 1000 watt rated pump, provided this as a maximum rating, but at this stage discovers the pump requires 3000 watts to start spinning

14

Page 15: Product Development

Treat Failures Like Gold!

You may be losing valuable information about product weaknesses

•  Products will fail in the field in ways that cannot be predicted, therefore any failure during small scale production testing have a very high probability of indicating a real problem, fix it now rather than recalling a product that goes to full production

•  Avoid the temptation to write off an early product failure as “because it’s a prototype”, follow the failure to a known root cause.

15

Page 16: Product Development

Operations and Maintenance

Day-to-day activities would normally include production and maintenance of the design, updates to the design and product in the field

•  The verification documents used in the previous step usually form the basis of a production test plan, a subset of tests that aims to prove the product is built correctly

•  The production test plan forms the basis of a product return validation method, anything returned by a customer would be validated using the same tests as production

16

Page 17: Product Development

The Next Revision

It is normal to go to Revision #2 Seeding the initial market target may give you

ideas on an even larger market that you can reach with minor product changes

You may realize how to get more money for the product with an additional feature

Revision may be necessary due to a misunderstanding of the market itself

This is the time to allow some feature creep, now that you have experience with Rev #1

17

Page 18: Product Development

Tools

A few project management tools will help to improve communication and reduce risk

•  Gantt Chart is the most common planning tool •  Gate Review Chart more common in Military

18

Page 19: Product Development

Gantt Chart

Allows all tasks to be managed on one sheet Assignment of resources and loading Estimates of program costs Quickly helps locate critical paths But… easy to get too deep into micro-management

19

Page 20: Product Development

Gate Review

Also called a “Phase Gate Plan” Can be linear (as shown) or tiered Provides clear illustration of when the teams need to be brought

together to approve moving to next phase Each gate has documented set of deliverables and sign-offs Very useful when managing external resources as progress can be

charted in terms of performance, timeline and cost to be sure you are on target at each gate

20

Page 21: Product Development

Budgeting for Development

Programs are generally over time and over budget •  It is NOT always a bad thing to be over-budget, quite often

the end product is better when an appropriate amount of “spin” is added

•  Budget can refer to dollars, to people or to time •  If you are solely responsible for the estimate, you may be an

order of magnitude too low, get a second opinion… and double it?

•  It is exceptionally rare to over-estimate a budget •  Find similar products and see if you can find out how much

it cost to develop from end to end •  Don’t expect to “beat” the predictions just because you are

a smaller team / company 21

Page 22: Product Development

Choosing a Partner

•  The people and companies you choose to work with will be directly responsible for the success of your idea, do you really want to go with the lowest bidder?

•  Investors are increasingly skeptical of heavily outsourced models because there is often a lack of buy-in by the outsourced company

•  Look for a partner that will ADD to your company’s reputation and will improve your chances of getting funded

•  Check references, not just the references the company gives you, but do a search on past news releases and other information… dig

•  Be open with the company’s you deal with, treat them with respect and they will be there to help you later if/when things don’t go exactly to plan 22

Page 23: Product Development

Contracts

•  Business should be done on a handshake, with a high level of trust •  The handshake must be backed up with a contract •  A good approach is to start with an MOU (Memorandum of

Understanding), it can be a 1 page bullet list which a lawyer can then easily turn into a full blown contract

•  Ultimately, if you don’t trust the person or are nervous about the business relationship then an MOU or contract will NOT help, sometimes you have to go with your gut impression

•  A well written contract will benefit both parties in conveying more than just rates and billing practises, but should also include the statement of work to be performed and methods of dispute resolution – Get a laywer

•  Refer back to the contract DURING the project to ensure nothing new has been added or taken away by casual verbal agreement

23

Page 24: Product Development

That’s It

•  Wake Up…

•  Any questions?

24

Page 25: Product Development

Steve Carkner President Panacis Medical Inc.

613-727-5775x727 [email protected]

25