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

1. Entrepreneurship
101
Product Development Basics
Steve Carkner
November 2008
1

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

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

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

5. The “V” Model of Development
5

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

25. Steve Carkner
President
Panacis Medical Inc.
613-727-5775x727
scarkner@panacis.com
25