July 25, 2007

The Marketing Wedge  Comments 

Filed under: High Tech Marketing — admin @ 3:52 pm


In my experience I saw that it was much more important to get into the right markets, and learn from the customers, than to try to build the right product for the wrong market.  As I moved into management I found that I had to explain this theory more and more to management in a credible way.  This led me to develop this framework.


I have shared it with many colleagues that have found it useful.  It has been presented as part of a panel to the Portland chapter of the Product Development and Management Association, and to multiple Portland State University classes.


It is similar to some other frameworks for making sure that marketing is covering all the bases.  I find it useful, because it makes sure that marketing does not get lost in the details, and maintains its key role in the directionof the company.

Market, Customer, Product 

I classify marketing activities into three buckets: markets, customers, and products. 

The Market factors are:

            Market size

            Growth rate





            Adjacent markets

The Customer factors are:

            Problem to be solved

            Rank versus other customer problems


            Sales channel


The Product factors are:





            Fit with sales channel

Where to spend Marketing time 

On which set of factors do you spend your time?  The basic premise it that Market factors are much more important that Customer factors, and that Customer factors are much more important than Product factors. 




One way to think of it is the impact a change of one of the factors could have to a business.  A market change generally means a dramatic shift (a 360°change of course).  A customer change means a large shift (a 90°change of course).  Lastly, a product change means a slight shift (a 20° change of course). 


Another way to think about it is that if you get the market and customer factors right, then the customer will give you feedback to correct a product that isn’t quite right.  But if you get either the market or customer factors wrong, then the feedback will not necessarily get you to success.


It helps explain why often the better mousetrap does not lead to a great business.  Often the market and customer factors swamp what is clearly a better product. 


In my experience, it works well for technology markets and I assume that it would work well for many other fast changing industries. 


Rick Denker

Packet Plus™, Inc.


July 18, 2007

Development Tools Compared to QA Tools  Comments 

Filed under: Engineering Tools — admin @ 2:48 pm

In the networking industry most test tools have become focused on the QA engineer.  I believe this has developed because of two factors:  first, is the need for a complete network set-up running at full speed to uncover the majority of issues.  Test cases that are not full speed often do not uncover any interesting issues.  Second, the issues are not easily uncovered in simulation, either at the chip or network level.  Simulation is often too regular to represent the randomness of actual network traffic. Typically the development engineer is left with only a software protocol analyzer at the packet level, and tools that are focused on other abstraction levels.   

The development analysis tool 

A development tool must be available early in the design process when the development engineer is the most active in debugging a new design.  This means at or before first silicon/first prototype.  This drives a set of needs that are very different than QA.  The needs and the characteristics of development tools are summarized below. 


- work when unsure of many parts of design           

- support broad usage by the development team           

- allow extensive control           

- ability to explore new options           

- work in leading edge environment 


- complex interface that may require highly trained user           

- limited size, and easily portable           

- inexpensive so it is economical for the individual engineer 

Tools that have these characteristics may have application in customer support, manufacturing fault analysis, or offloading an expensive QA tool.

The quality assurance tool

The QA tool must provide complete coverage of all the features and combinations of features that make up the design.  This must be able to be run after each new release or update.  This tool does not need to be available as early, but must have more coverage.  This drives the set of needs and characteristics summarized below. 


- support repeatable regression testing           

- coverage of maximum configurations           

- provide an efficient interface 


- larger, and not easily portable           

- simple easy-to-use interface with pre-written tests and extensive reports           

- limited control            

- expensive, priced for a project or company use 

The development team often needs to use the QA tools when working on larger configuration testing. 

Comparison to other industries 

Interestingly the split between development and QA has evolved differently in other technical disciplines. 

For the software industry, development tools progressed much faster with QA tools being almost non-existent initially.  QA tools came later and still typically lag.  In specialized area such as multi-user loading for internet servers quite advanced QA tools have been developed. 

In the Electronic Design Automation industry was initially dominated by development tools, but shift toward verification now takes up more than half the effort of most chip designs. 

For the hardware industry there has been more of a balance with development have larger staffs and tools budgets, but with QA having the larger and more complex equipment. 

Rick Denker

Packet Plus™, Inc


July 10, 2007

New Approach Needed  Comments 

Filed under: Engineering Tools — admin @ 2:46 pm

(This is the sixth of six posts that is exploring the question – “Why have sophisticated commercial development tools seemingly passed over the networking equipment development engineer??) 

Currently the networking industry tolerates the method of custom tool development that has gotten the industry this far even though it is expensive.  However with the continued growth of complexity, the costs will continue to escalate both for the custom development and for the lack of productivity for the development engineers.   

A dramatically improved approach to the problem is required.  A ten percent better tool may only provide a few months in terms of keeping up with the coming issues.  It makes me think of the Einstein quote, “We can’t solve problems by using the same kind of thinking we used to create them?.  Several innovative solutions are being developed for QA testing such as those from VeriWave for wireless LAN products.  The same kind of innovation needs to be applied to the tools for the development engineer.    

The new solution should have substantially the following characteristics below.  Some of these characteristics have been made obvious from the discussion in this paper.  Other characteristics are implied because of the need to preserve the primary benefits of the tool.   

Characteristics for a development tool solution:

§          It should be available at first silicon, or first prototype. 

All of the dependencies that cause delay need to be eliminated.   

§          It should be flexible and configurable. 

This allows the exploration of new versions of protocols, or potential new changes to protocols without an entirely new development. 

§          It should integrate easily with other tools that are used. 

The gains that were made in timeliness should not be given back because of the need to spend additional time integrating the tool into the development environment. 

§          It should support the easy generation of test cases. 

If a tool requires significant effort and time to develop test cases, it can limit when it can start being used.  Cumbersome test case generation can be the equivalent to a product delay. 

§          It should allow the efforts between companies to be combined. 

A solution that works well for just one company will not be an industry solution.  The solution should be able to use the size of the networking industry to its advantage. 

This set of requirements may set the bar too high for some approaches.  However, it reinforces the need to come at the problem with a different approach to meet these requirements.  

Rick Denker

Packet Plus™, Inc. 

Root Causes of Issues  Comments 

Filed under: Engineering Tools — admin @ 2:29 pm

(This is the fifth of six posts that is exploring the question – “Why have sophisticated commercial development tools seemingly passed over the networking equipment development engineer??) 

The current state of tools for the networking development did not just appear over night.  There are several industry dynamics that have combined to create the current state of developer tools.   

The primary cause has been the speed of the technology evolution.  If the technology has been stagnant the investment would have been made to improve the breadth and quality of the tools.  However, it has been an ever changing target.   

Such a treadmill effect exists in several tool industries.  In the Electronic Design Automation industry the same set of tools need to be re-built for each new geometry of chip development technology.  The complexity of this challenge with ever smaller geometries often consumes the development teams.  Because of this treadmill, new features are rarely added, and sometimes they are even dropped in subsequent product generations.   Another factor is that test tools use the same basic architecture as the equipment that they are testing with some modifications.  (See Figure 1 – Networking Test Architectures) The modifications are made in software, hardware or the network physical layer (PHY).   For the software a more controlled version with a limited number of options is implemented.  For the hardware a higher performance or more programmable version is implemented.  For the PHY most commonly a standard interface chipset is used, but a custom interface solution may be used in some cases.  The more modifications the more the tool development will cost, so each modification is implemented, or not, based on a cost benefit analysis.  Also the more modifications that are made the earlier the development needs to start to meet the availability need.  


Using the same architecture can also make the test tools suffer from “chicken or the egg? dependencies.  For example, a tool that uses a commercial PHY chipset for the physical layer will be limited by the availability of the chipset.  Some of the disadvantage of this approach can be mitigated by an accelerated integration program once the chipset arrives.  Ideally a tool would be available before the equipment under test, so that the developer could become comfortable with how it will perform before the critical time when first silicon or first prototype is delivered.  Effectively the tool developers are on the same treadmill as their customers, except their market size is understandably significantly smaller.  This causes many tool companies to take a “wait and see? attitude to new standards.  Because of these effects companies often focus on the needs of Quality Assurance (QA) testing which is generally larger, but does not have the same critical need for early availability.   Another factor that has limited the advancement of sophisticated tools has been the lack of a way for the custom tool developers to share their efforts.  Each vendor develops their custom tools independently.  There have been a few cases in the past where a consortium has funded tool development, but it hasn’t been early enough to replace the internal custom tools. 

Rick Denker

Packet Plus™, Inc.