2. Entrepreneurship
101
Product Development Basics
Steve Carkner
Nov 2011
2

3. 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

4. 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

5. 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

6. 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

7. 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

8. The “V” Model of Development
8

9. 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
9

10. Concept of Operations
Comprised 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

11. Concept of Operations
Comprised 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

12. Concept of Operations
Comprised 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

13. Concept of Operations
Comprised 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

14. Concept of Operations
Comprised 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

15. Concept of Operations
We 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

16. 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
16

17. 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
17

18. 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
18

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

20. Customer / Market Reqs. – non technical
Flashlight 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

21. Customer / Market Reqs. – non technical
Flashlight 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

22. Customer / Market Reqs. – non technical
Flashlight 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

23. Customer / Market Reqs. – non technical
These 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

24. Customer / Market Reqs. – non technical
A 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

25. Functional Requirements – more technical
Helps 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

26. Functional Requirements – more technical
Helps 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

27. Functional Requirements – more technical
Helps 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

28. Product / Engineering Specification – technical
Should 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

29. Product / Engineering Specification – technical
Should 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

30. Product / Engineering Specification – technical
Should 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

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

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

33. Test and Verification Specifications – technical
Should 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

34. Test and Verification Specifications – technical
Should include sensitivity analysis
• Variation
• Allowable limits
Tests 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

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

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

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

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

39. 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!
39

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

41. Suggested Tactic
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”
Schematic PCB Mech Open /
Date Who open Date Who
Item # 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 to
4 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 and
5 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 looks
6 overhead view 0.0 0.0 0.0 Electrical great. closed 26-Nov-07Rene 11-Marsteve
41

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

43. 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”
43

44. 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
44

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

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
46

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
47

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
48

49. 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

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

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
51

52. 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

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)
53

54. 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

55. Real-World Flashlight Example
The 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

56. 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.

57. 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
57

58. Operations and Maintenance
Dealing 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

59. Operations and Maintenance
Dealing 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

60. 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
60

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

62. 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
62

63. 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
63

64. 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
64

65. 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

66. 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

67. 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

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

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