Product Development - Entrepreneurship 101

Entrepreneurship 101Product Development Basics Steve Carkner Nov 2011 2

Send Feedback•  My 4th year giving this presentation.•  Take notes on what you would like to see added, improved, etc.•  Send to scarkner@panacis.com•  Thanks! 3

Introduction to Steve Carkner•  25 Year product development experience•  Award winning designer, products featured in Popular Science, Smithsonian, Science & Tech Museum, and many more…•  Investor, advisor and board member in many startup companies•  Former Director of Product Development and Intellectual Property Research at RIM•  Dozens of patents world-wide 4

Introduction to Panacis•  Focus on energy storage systems (batteries).•  Roots in full product development from napkin sketch to production•  Many products launched internationally from tiny novelties sold at Walmart to power systems for fighter jets and artificial hearts•  Profitable, high growth (100% P.A.)•  Profit 100 Ranked – 3 Years in a row•  Deloitte Technology Green 15 Company 5

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 worst•  Following a plan will dramatically increase the chances of success defined as the launch of a profitable, high quality product or service 6

Lets look at a Flashlight!•  You might assume that a flashlight would be very easy to just “throw together” in a design•  We will chart the development path for a flashlight against the product development path that could be used for much larger programs•  It’s really just the number of zeroes in the budget that changes 7

The “V” Model of Development 8

Concept of OperationsComprised 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 9

Concept of OperationsComprised principally of the idea behind whatever you are trying to do.•  Who wants it –  Walmart, Road Warriors or Stocking Stuffers?•  What is it for•  Who pays•  What is YOUR capability in the area 10

Concept of OperationsComprised principally of the idea behind whatever you are trying to do.•  Who wants it –  Walmart, Road Warriors or Stocking Stuffers?•  What is it for –  Serious lighting or Fun?•  Who pays•  What is YOUR capability in the area 11

Concept of OperationsComprised principally of the idea behind whatever you are trying to do.•  Who wants it –  Walmart, Road Warriors or Stocking Stuffers?•  What is it for –  Serious lighting or Fun?•  Who pays –  Consumer, Industrial, Government?•  What is YOUR capability in the area 12

Concept of OperationsComprised principally of the idea behind whatever you are trying to do.•  Who wants it –  Walmart, Road Warriors or Stocking Stuffers?•  What is it for –  Serious lighting or Fun?•  Who pays –  Consumer, Industrial, Government?•  What is YOUR capability in the area –  Distributor, Designer, Manufacturer? 13

Concept of OperationsComprised principally of the idea behind whatever you are trying to do.•  Who wants it –  Walmart, Road Warriors or Stocking Stuffers?•  What is it for –  Serious lighting or Fun?•  Who pays –  Consumer, Industrial, Government?•  What is YOUR capability in the area –  Distributor, Designer, Manufacturer? 14

Concept of OperationsWe are going to build a Flashlight for Road Warriors to use in Serious Lighting situations. This will be bought by the Consumer. We will Design this product and outsource the Distribution and Manufacturing.I hope this matches your business plan!Entrepreneur’s Note: Cheaper is very rarely a viable business model 15

Requirements and ArchitectureBreak down into separate documents with the first TWO being the most important•  Customer / Market Reqs. – non technical•  Functional Requirements – more technical 16

Requirements and ArchitectureBreak 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 17

Requirements and ArchitectureBreak 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 18

Customer / Market Reqs. – non technicalFlashlight is:•  Durable and light weight for the Road Warrior 19

Customer / Market Reqs. – non technicalFlashlight is:•  Durable and light weight for the Road Warrior•  Bright, even light, with good battery life for Serious Situations•  Should never be left without light•  Price is only a moderate consideration 20

Customer / Market Reqs. – non technicalFlashlight is:•  Durable and light weight for the Road Warrior•  Bright, even light, with good battery life for Serious Situations•  Should never be left without light•  Price is only a moderate consideration•  Good place to add our special sauce such as a desire to be the smallest, or lightest, or brightest and explain how this helps to focus on the ultimate target market 21

Customer / Market Reqs. – non technicalFlashlight is:•  Durable and light weight for the Road Warrior•  Bright, even light, with good battery life for Serious Situations•  Should never be left without light•  Price is only a moderate consideration•  Good place to add our special sauce such as a desire to be the smallest, or lightest, or brightest and explain how this helps to focus on the ultimate target market•  Good place to add competitive comparisons which we can seek to meet or exceed 22

Customer / Market Reqs. – non technicalThese considerations may SEEM obvious to you, but they may not be obvious to the people helping you grow your business.You (should) know your market and target better than anyone else.Make sure everyone is going in the same direction. 23

Customer / Market Reqs. – non technicalA good plan inspires confidence inside your team.•  Everyone wants to do a good job•  Plan gives people a focus, something to be proud of, it is a great feeling when you overhear other team members quoting your market focus plans “we are going to be the lightest, brightest, best”•  Next up – How to measure when the job is complete 24

Functional Requirements – more technicalHelps to give both a fixed goal and a stretch goal•  How lightweight, example of less than 50 grams with a stretch goal of 40 grams (why?) 25

Functional Requirements – more technicalHelps to give both a fixed goal and a stretch goal•  How lightweight, example of less than 50 grams with a stretch goal of 40 grams (why?) 26

Functional Requirements – more technicalHelps to give both a fixed goal and a stretch goal•  How lightweight, example of less than 50 grams with a stretch goal of 40 grams (why?)•  How bright, even, adjustable, long life, etc.•  Drop, shock, water resistance, etc.•  This is the place to add any extra feature requirements such as onboard storage of an extra bulb (why?) 27

Product / Engineering Specification – technicalShould answer “how” for many of the previous functional requirements•  Achieve weight requirement by use of small AAA batteries AA AAA 23 Grams 12 Grams 28

Product / Engineering Specification – technicalShould answer “how” for many of the previous functional requirements•  Achieve weight requirement by use of small AAA batteries AA AAA 23 Grams 12 Grams•  Does this impact other customer or market requriements such as availability of batteries, operating costs, run-time. 29

Product / Engineering Specification – technicalShould answer “how” for many of the previous functional requirements•  Achieve weight requirement by use of small AAA batteries•  Material selection, Aluminum, Titanium?•  Achieve long run time by use of LED technologies•  Mechanical design to meet IPXX, plus 2 meter drops, etc. 30

Test and Verification Specifications – technicalShould answer “prove it” for the previous functional and engineering specification requirements 31

Test and Verification Specifications – technicalShould answer “prove it” for the previous functional and engineering specification requirements•  Test can be simple – Weigh it! 32

Test and Verification Specifications – technicalShould answer “prove it” for the previous functional and engineering specification requirements•  Test can be simple – Weigh it!•  Light output•  Battery life•  Durability•  Every item from specification to be checked! 33

Test and Verification Specifications – technicalShould include sensitivity analysis•  Variation•  Allowable limitsTests focus on proving the design does what we expected and therefore will also meet the customer specification.Tests are NOT done on every product 34

Test and Verification Specifications – technicalA good test plan will be used for years into the future, possibly after the original authors have departed from the company 35

Test and Verification Specifications – technicalA good test plan will be used for years into the future, possibly after the original authors have departed from the companyVerify that existing suppliers continue to meet the requirementsVerify new suppliers (lower cost, geographic changes, etc.)Deal with obsolete components and suppliers 36

Test and Verification Specifications – technicalA good test plan will be used for years into the future, possibly after the original authors have departed from the companyVerify that existing suppliers continue to meet the requirementsVerify new suppliers (lower cost, geographic changes, etc.)Deal with obsolete components and suppliersSoftware upgrades (a whole different presentation can be made on this) 37

Detailed Design Finally – it is time to actually start designing the product! 38

Detailed DesignThis 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! 39

ImplementationThis 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 40

Suggested TacticCreate a tracking system at this pointAny feedback can be reported, and tracked to closureReduces design spin due to items “falling through the cracks” Schematic PCB Mech Open / Date Who open Date WhoItem # Description 5part@n Revision Revision Revision Category How Fixed or Suggested Fix Verify / Opened it? Closed close it? Level Level Level Closed Customer spec does not explain what Charge Enable signal is used for or if it can be This has been clarified, signal is absolute ignored, we plan to requirement. Second procesor added to4 ignore it. 0.0 0.0 0.0 Electrical design to handle it. closed 26-Nov-07Steve Feb-08Rene Cells have too much free movement inside housing and will easily tear connectors or slam Manufacture carrier boards that are taped to into circuit board. New Mechanica the cells to restrict free movement and5 design required here. 0.0 0.0 1.0 l support tab structure. Pot batteries into case. CLOSED 26-Nov-07Eric May 23-08 Eric LCD Display angle is incorrect, designed for Increase drive level to LCD by clocking the 6-oclock view, should COM pin at 180 degrees to the segmet pin. be designed for This dramatically increases contrast and looks6 overhead view 0.0 0.0 0.0 Electrical great. closed 26-Nov-07Rene 11-Marsteve 41

Integration, Test and VerificationThis is the Collection phase•  This portion of the program is the MOST underestimated in terms of time and costs 42

Integration, Test and VerificationThis 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” 43

Integration, Test and VerificationThis 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 44

Integration, Test and Verification (cont)•  It will NOT work the first time 45

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 46

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 47

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 48

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 49

System Verification and ValidationThis 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 (not technical requirements)•  The most common complaint will be unexpected operation or interactions with other equipment 50

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 51

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 now can invalidate most of the work of your work (and money, and time) 52

Real-World Flashlight Example•  A large gun manufacturer was tasked with providing a portable target lighting system on their weapon. The object was to have a flashlight on the weapon so enforcement officers would not have both hands full (one with a flashlight and one with a gun) 53

Real-World Flashlight Example•  A large gun manufacturer was tasked with providing a portable target lighting system on their weapon. The object was to have a flashlight on the weapon so enforcement officers would not have both hands full (one with a flashlight and one with a gun)•  ALL requirements were met with respect to brightness, battery life (using LED’s), weight, etc. 54

Real-World Flashlight ExampleThe Problem (which still exists today)•  The white light from the LED’s is quite harsh and the human eye cannot perceive contrast and detail very well with it•  When they tried it in real life, they had a “criminal” hold either a gun, a stick, or a doll•  With conventional light bulb flashlight they could easily figure out what the criminal was holding•  With the LED light, they couldn’t tell•  Customer requirements did not envision this scenario, it is now part of their spec and validation plans 55

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.

Operations and MaintenanceDay-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 57

Operations and MaintenanceDealing with customer support, returns and field upgrade issues is rarely budgeted for•  If you are planning a very steep deployment ramp, there are a number of companies that you can outsource this to•  Planning a slower deployment ramp with a friendly customer will allow you to manage support in-house 58

Operations and MaintenanceDealing with customer support, returns and field upgrade issues is rarely budgeted for•  If you are planning a very steep deployment ramp, there are a number of companies that you can outsource this to•  Planning a slower deployment ramp with a friendly customer will allow you to manage support in-house Seek out your friendly customers! 59

The Next RevisionIt 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 60

ToolsA 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 61

Gantt ChartAllows all tasks to be managed on one sheetAssignment of resources and loadingEstimates of program costsQuickly helps locate critical pathsBut… easy to get too deep into micro-management 62

Gate ReviewAlso called a “Phase Gate Plan”Can be linear (as shown) or tieredProvides clear illustration of when the teams need to be brought together to approve moving to next phaseEach gate has documented set of deliverables and sign-offsVery 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 63

Budgeting for DevelopmentPrograms 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 64

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, do a search on past news releases and other information… dig•  Be open with the companies 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 65

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 practices, but should also include the statement of work to be performed and methods of dispute resolution – Get a lawyer•  Refer back to the contract DURING the project to ensure nothing new has been added or taken away by casual verbal agreement 66

One Last Look - Flashlight•  Don’t underestimate complexity, each part of this unit needed to be designed•  Effectively, each part is a mini-project itself 67

That’s It•  Wake Up…•  Any questions? 68

Please send any feedback you have to me, I would like to keep improving this presentation!Steve CarknerPresidentPanacis Inc.613-727-5775x727scarkner@panacis.com 69

Product Development - Entrepreneurship 101

by Cathy Bogaart on Nov 11, 2011

Accessibility

Categories

Upload Details

Usage Rights

Statistics

Product Development - Entrepreneurship 101 Presentation Transcript