From: Andrew M. DEARDEN\ (A.M.Dearden@shu.ac.uk)
Date: Sun Feb 13 2000 - 22:51:04 EST
bcapps@sharplabs.com writes:
>
>I suppose a bit more context is necessary.
>
>I'm a software process engineer working at an R&D lab for a multinational
>consumer products corporation. My group performs basic intellectual property
>research as well as product development. Until fairly recently, we've had a
>clear distinction between "technology" (i.e., source code that can
>demonstrate capability, but still needs considerable work before it will be
>ready to sell to end-users) and "products" (i.e., complete systems that are
>ready to sell). A quick informal internal poll reveals some of these
>differences and characteristics:
>
> Product Technology
> ======= ==========
> Delivered to end-users Delivered to internal groups
> Has identified customers May/may not have identified
>customers
> Provides utility Provides potential/partial
>capability
> An end unto itself A means to an end
> Fully supported Partial support or no support
> High level of expectations Reduced level of expectations
>
>I've searched the web and found many hits for the word "productization" (the
>process of "hardening" technology to turn it into a product), but most
>people tend to use these words without defining them.
>
>The problem for us arises because some of our domain engineering initiatives
>have begun to develop "technology products" for internal customers. These
>"technology products" fall somewhere between these two definitions; they
>have higher engineering standards and more support than "technologies" but
>they certainly aren't "products" since they are designed to be components
>*of* products. This ambiguity is causing confusion and project management
>problems. An "internal customer" is an alien concept to parts of the
>company.
Brent:
It seems to me your definitions need to cover 2 different dimensions that
distinguish
customer deliverable products
internally deliverable products
internally deliverable technologies
1) Does the thing delivered satisfy some immediate goal of the customer
(internal or external)
or does it only satisfy a goal when it is combined with various other things.
I.e. is it part of
some larger activity that teh customer is engaged in. A car satisfies a goal of
mine, to get from
A to B, but a spark plug doesn't - unless it fits my car (which assumes that I
don't have a diesel).
i.e. is it part of a product, or is it a whole 'value proposition'.
2) When I take delivery, to what extent is the functionality & performance
negotiable, i.e.
is this version of this thing going to be shipped to customers in it's current
state, or
if it needs improving can we chat to the supplier and sort something out - this
is your issue about the
appropriate engineering standards.
SO:
If you provide my department with a great tool to do my job, I might accept
that it's a bit
flaky, so long as you co-operate as we improve it.
If you provide my department with a part of something I'm going to ship,
...........
What this means for your definitions, I'm not sure, but how about:
>Product 2. A deliverable which is both necessary and sufficient to provide
>benefit to end-users.
Sounds fine
>
>Technology 2. A deliverable which is
A REQUIRED COMPONENT FOR A PRODUCT
> but not sufficient to
>provide
DIRECT
> benefit to end-users.
>
>Productization The process of integrating technology into a product.
This one is a bit dangerous - other people might say that productization was
the process of desiging
a product that exploits an idea - in which case the 'technology <-> part'
metaphor breaks down.
If I put my spark plug into my car am I productizing it ?
>
>
>Technology Product A technology which is both necessary and sufficient to
>provide benefit to internal customers.
I suspect that this one doesn't work. This is a product alright, but as I
suggested above, you
probably won't apply the same standards to it as products shipped to customers.
Does it need to be distinguished. Perhaps you need: Externally deliverable
product
&
Internally consumed product
Hope that helps rather than hinders the discussion
Andy
>
Andy Dearden
Senior Lecturer
Department of Computing and Management Sciences
Sheffield Hallam University
Sheffield
S1 1WB
UK
Tel: +44 (0)114 225 2916
This archive was generated by hypermail 2.1.6 : Fri Feb 21 2003 - 11:25:09 EST