Just finished listening to it. Highly recommended, very informative and
quite hilarious at times...:-)))

Thanks,
--Gabriel
----------------------------------------------------------------------------



From: "rickchapman53" <mchapman29@...>
Reply-To: PSPM@yahoogroups.com
Date: Fri, 21 Nov 2003 15:36:15 -0000
To: PSPM@yahoogroups.com
Subject: [PSPM] Online interview with author of In Search of Stupidity: Over
20 Years of High-Tech Marketing Disasters

Early in November Merrill R. (Rick) Chapman appeared on a local New England
business show to discuss his new book "In Search of Stupidity: Over 20 Years
of High-Tech Marketing Disasters" and other developments in software and
high-tech marketing.

The interview is now available in its entirety (sans the commercials) on
http://www.insearchofstupidity.com
The interview features samples of classic and current software and high-tech
marketing disasters and discusses the reasons why companies keep repeating
the same mistakes again and again.  The entire show is currently digitized
in Windows Movie Format (a Real version will be available shortly) and the
file size is 51MB if you wish to download and distribute.  Viewing time is
approximately 47 minutes.  Please note this link is optimized for
high-bandwidth connections.

Reply-To: ILPM@yahoogroups.com
Date: Fri, 21 Nov 2003 07:01:14 -0800 (PST)
To: ILPM@yahoogroups.com
Subject: Re: [ILPM] Re: [Toronto PMA] Software Architecture's Business Value -- if any

Hello all,

See my feedback below following Gabriel's questions. Good discussion on an important topic, often overlooked by many (not just the product manager)

Ran
Gabriel Steinhardt <gs241@...> wrote:

Hi Shimon,
I have some questions...
You wrote "Software architecture is vital to business value!".  To whom is it vital? to the software vendor or the customer?  why would it be valuable?

Ran: It is vital to everyone but the end-user. From the vendor, through the customer, to business and technology partners, and to investors. Why? Because architecture has a direct impact on the product's TCO and the size of the addressable market to mention just a few.

CTOs typically refrain from touching products built on proprietary architecture if they have an alternative. It locks them into the specific vendor/technology for life. It increases their TCO for the product (can't get anyone to write upgrades, change functionality, etc.). Scalability was another issue mentioned. Finally, architecture has to be flexible and adaptable to accommodate the ever-changing business world. Products built on inherently incompatible technologies (i.e., meshing .NET and Java together) are often viewed by investors as having limited market potential (many customers stick to one camp, and don't mix technologies) and significant cost of ownership.

You wrote "A product manager's view of software as black box is dangerous."   Why?  Product managers should be concerned with functionality that solves the target market's business/consumer problem.   Who cares if a product is written in C++ or ANSI C?

Ran: What language you write your code in can determine who you will be able to sell your product to, at what price, and how much capital, if at all, you will be able to attract to your business. This is at a strategic level. On a more tactical level, a product manager should care very much about the architecture selected since it directly impacts the cost of development (i.e., P&L) and time to market for the product. See also my answer above.


The issues of "scalability, time to market, modularity, leveraging on platforms" are all product requirements.  Not a specification dictating a certain software architecture.   Do you agree?

Ran: Disagree. Proprietary architectures (especially in the db and app server components) are inherently less scalable, and modular than open architectures (i.e., J2EE).

The case you gave about the bad code is a fine example of properly scrutinizing a potential partnership opportunity.  However, I apologize as I did not understand what  product management decision was made. ("With input from our software architect we made a very important product management decision.")

From: "Shimon Shmueli" <shimons@...>

Reply-To: ILPM@yahoogroups.com
Date: Thu, 20 Nov 2003 23:17:05 -0500
To: <ILPM@yahoogroups.com>
Subject: RE: [ILPM] Re: [Toronto PMA] Software Architecture's Business Value -- if any

Software architecture is vital to business value!

A product manager's view of software as black box is dangerous. A discussion about that is too broad and involved, but you should not forget issues of scalability, time to market, modularity, leveraging on platforms, just to name a few very important issues.

While working as product line manager for a large company, we selected a core piece of software from a major supplier (although a much smaller company) for a new family of products. One of our conditions was to review the architecture and even some source code. What we discovered was very poor architecture, patchy piece of software, loosely defined interfaces, lack of scalability, etc. Needless to say we did not strike a partnership, even though the software worked very well. Independently, that vendor later needed to completely rewrite the system and consequently lost market leadership and is currently struggling. With input from our software architect we made a very important product management decision.

Shimon

-----Original Message-----
From: Spinacia [mailto:sp853@...]
Sent: Thursday, November 20, 2003 10:19 PM
To: tpma@yahoogroups.com
Subject: [ILPM] Re: [Toronto PMA] Software Architecture's Business Value -- if any

Does software architecture's have a business value?
To the vendor producing the software there is minimal business value in publicizing the use of a particular software architecture and producing software products that conform to it.  In some markets, the existence of a certain software architecture may imply forethought, credibility and perhaps scalability.   I view software architecture mostly as a competitive differentiator and an element that satisfies RFP specifications.
To the customer, the thing that really matters is functionality and compatibility with business needs.  A software application that optimally implements a certain architecture will have very minimal value if it does not provide functionality that addresses the customer's business needs.


What is a good software architecture?
In accordance with the above comments, I believe that a good software architecture is a technical matter addressed by Development.  From the customer's and product management's perspective it does not make a difference if versions of the software product are based on different programming languages or architectures.

Thanks,
--Gabriel

---

From: "Dennis Layton" <d-layton-is@...>
Reply-To: tpma@yahoogroups.com
Date: Fri, 21 Nov 2003 00:30:59 -0000
To: tpma@yahoogroups.com
Subject: [Toronto PMA] Software Architecture's Business Value -- if any

I was intrigued by Luke Hohmann's post about the business value of
software architecture.

It would be interesting to find out what product managers perceive as
the business value of a good software architecture for a product or
product line. Is there a business value ?  

What is a good software architecture? I know what a good software
architecture is from the perspective of a technical architect, but
what do product managers expect from a software architecture ? Or is
it just something that development team should be concerned about ?


Dennis Layton

Reply-To: ILPM@yahoogroups.com
Date: Thu, 20 Nov 2003 23:17:05 -0500
To: <ILPM@yahoogroups.com>
Subject: RE: [ILPM] Re: [Toronto PMA] Software Architecture's Business Value -- if any

Software architecture is vital to business value!

A product manager's view of software as black box is dangerous. A discussion about that is too broad and involved, but you should not forget issues of scalability, time to market, modularity, leveraging on platforms, just to name a few very important issues.

While working as product line manager for a large company, we selected a core piece of software from a major supplier (although a much smaller company) for a new family of products. One of our conditions was to review the architecture and even some source code. What we discovered was very poor architecture, patchy piece of software, loosely defined interfaces, lack of scalability, etc. Needless to say we did not strike a partnership, even though the software worked very well. Independently, that vendor later needed to completely rewrite the system and consequently lost market leadership and is currently struggling. With input from our software architect we made a very important product management decision.

Shimon

-----Original Message-----
From: Spinacia [mailto:sp853@...]
Sent: Thursday, November 20, 2003 10:19 PM
To: tpma@yahoogroups.com
Subject: [ILPM] Re: [Toronto PMA] Software Architecture's Business Value -- if any

Does software architecture's have a business value?
To the vendor producing the software there is minimal business value in publicizing the use of a particular software architecture and producing software products that conform to it.  In some markets, the existence of a certain software architecture may imply forethought, credibility and perhaps scalability.   I view software architecture mostly as a competitive differentiator and an element that satisfies RFP specifications.
To the customer, the thing that really matters is functionality and compatibility with business needs.  A software application that optimally implements a certain architecture will have very minimal value if it does not provide functionality that addresses the customer's business needs.


What is a good software architecture?
In accordance with the above comments, I believe that a good software architecture is a technical matter addressed by Development.  From the customer's and product management's perspective it does not make a difference if versions of the software product are based on different programming languages or architectures.

Thanks,
--Gabriel

---

From: "Dennis Layton" <d-layton-is@...>
Reply-To: tpma@yahoogroups.com
Date: Fri, 21 Nov 2003 00:30:59 -0000
To: tpma@yahoogroups.com
Subject: [Toronto PMA] Software Architecture's Business Value -- if any

I was intrigued by Luke Hohmann's post about the business value of
software architecture.

It would be interesting to find out what product managers perceive as
the business value of a good software architecture for a product or
product line. Is there a business value ?  

What is a good software architecture? I know what a good software
architecture is from the perspective of a technical architect, but
what do product managers expect from a software architecture ? Or is
it just something that development team should be concerned about ?


Dennis Layton

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service <http://docs.yahoo.com/info/terms/> .

Yahoo! Groups Sponsor   ADVERTISEMENT

 

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service <http://docs.yahoo.com/info/terms/> .

I think many will find Jacques' newsletter insightful and useful.

Shimon



====================================
PRODUCT MANAGEMENT CHALLENGES
A Weekly Newsletter of Tips
For Companies that Develop Software
-- by Jacques Murphy
====================================
Today's Topic: ACHIEVING OBJECTIVES: GO FOR THE GOAL
Product Manager. It's the job where you get
involved with everything, managing by influence
across departments rather than direct authority
via direct reports.
This is a job where you really, really need to
figure out how to achieve goals. There are too
many tasks coming at you from too many directions
and priorities pulling you every which way.
My friend Mike Wass, a management consultant,
has a method he has practiced for years to make
sure that he reaches his goals. He gradually
realized that his approach to making something
happen was markedly different from the approach
most people seem to use. It's almost the
reverse of what the majority of people use, a
majority that struggles mightily to reach their
goals, and misses the target as often as not.
Mike learned to appreciate the uniqueness of his
perspective and taught his approach to others.
It's called Working From the Goal.
Read on for an explanation of how to use a
Working From the Goal approach to attain a whole
lot more of your goals than you otherwise would.
(This week's topic applies to far more than just
Product Managers. Everyone has goals they want
to achieve. Pass it on to someone who might be
interested.)
TAKING A PAGE FROM UNDERSTANDING BY DESIGN
Mike discovered only recently that this same
philosophy is embodied in the work of two
individuals who apply it to the educational
field. It's something that people in the
business world aren't likely to be familiar with,
because this approach is studied by people who
are learning to be educators.
In the book "Understanding by Design"
(Association for Supervision & Curriculum
Development, 1999) authors Grant Wiggins and
Jay McTighe describe a way to teach students
that is just like the idea of Working From
the Goal.
Applied to learning, this is called Backward
Design. Backward Design suggests that instead
of starting by putting together lessons and
activities, you must first and foremost figure
out what you want to do, specifically the BIG
IDEA that really crystallizes what you want to
impart. Once you have the big idea, you can
figure out how to assess whether a student has
understood it, then build the necessary lesson
plan, activities and other details to get where
you want to go.
This is very much the inverse of the approach
that most teachers take, where they look at the
reading materials and then build activities and
learning goals from them.
WHAT IT IS IN A NUTSHELL
Okay, let me warn you this may be hard to get at
first. The idea is that you need to work FROM
the goal, versus working TOWARD the goal. Most
people work TOWARD the goal, and in so doing
run the risk of never getting there.
Always work back from the goal to figure out what
you must do. To translate the Backward Design
concept into business language, first identify
the desired results (your goal), then determine
the acceptable deliverables for it, and only
then plan the tasks to get there.
HOW TO DO IT THE WRONG WAY
Maybe I'm just dense this way, but it took a lot
more than the above explanation for me to grasp
this. Everything about the above explanation
makes sense, and probably sounds like what you
do today. It helps to look at how it's done the
wrong way, working TOWARD the goal.
Everyone talks about what their goals are, but
most people focus on the things that are in the
pipeline to get to the goal, starting activities
with little real reflection on and clarification
of the goal. They decide to do x, y, and z, but
they never reach the goal they want. They wind
up wasting time, energy, and money.
Very often people start by putting activities in
place that move them in the direction of their
goal, because they want to get moving right away.
Moving is good. Just go for it! We've gotta get
going!
The problem with that is you're moving, but you
may or may not know what your goal is, because
you don't firm it up. These activities, while
taking up lots of time, don't get you there,
because you're not focused.
SO HOW DOES "FROM" GET YOU THERE?
If you work FROM the goal, you put the goal in
place from the start. You can work toward it.
The difficulty you face is like not being able
to see the forest for the trees. With all the
details and distractions of daily activity, you
need a clear goal.
When you work FROM the goal, you will constantly
be putting things in place that support where
you want to go. You are much more able to see
when activities don't contribute to the goal,
and cut them out of your schedule.
AN EXAMPLE: WINNING A GOLD MEDAL
Perhaps an example will be helpful. If you want
to win the 500 meter dash at the Olympics, you
can't start by saying "I'm going to work hard,
improve my times, get a good coach, and then I
should be able to win."
Instead, you start with "I'm going to win the
500 Meter. Now, what do I need to do to make it
happen?" If you use this approach, you'll
probably plan many more specific activities,
cutting out things that don't fit with your goal.
WELL DEFINED GOALS: VISION POWER
This touches upon other advice for achieving
goals, which is that the only reachable goal is
one that is realistic, and sufficiently detailed
and clear.
Often, when you challenge people (the many
people who are coming to you to set "your" goals),
they say that they can't be more specific about
the goal, they just don't know. In such a case
you're better off not doing anything. (Try
telling that to your boss!)
People have a difficult time working toward the
unknown. If you establish a goal, it becomes the
known, it becomes reality. Very much like the
concept of vision that is so talked about in
business these days. Paint a picture, create a
vision, and let it guide you and your teammates
all in the same direction, consistently.
WANDERING AROUND
By contrast, when you work TOWARD the goal, you
get bogged down in the process. As one educator
described it on a message board, it's like you
are "privileging the activities themselves over
the results they should yield." Because your
thinking is too short term, you don't keep the
goal in mind.
ANOTHER EXAMPLE: DEFINING A PROCESS
A good business example to contrast the two
approaches is to apply them to defining a
process using a flow chart. If you start at the
goal and work backward, the steps will all fall
into place. This is working FROM the goal.
But if you start at beginning, at the first
step, you may not make the right decisions as
you work your way forward TOWARD the goal.
(I have to guiltily admit that I've always done
flow charts starting from the first step. I must
say it has led to many revisions of the chart as
I progress. I guess I had better try it the
other way next time.)
STEPS
Here' a quick list of steps to summarize Working
From the Goal:
1. Set a goal. Make it clear, specific, and
realistic.
2. Create an assessment to determine if the goal
has been met. In a business setting, this would
be deliverables with specific content that will
tell you whether you're there.
3. Plan the activities you need to complete,
working backwards from the goal.
QUESTIONS?
I had a lot of trouble getting this one. I asked
Mike a lot of questions. So please don't
hesitate to ask your own questions. Send me an
email and I'll forward it on to Mike Wass.
The easiest way to send the email is to click
the link below.
<mailto:jacquesm@...?subject=Goals>
Since I have a day job, I'm on my personal email
only at night and on weekends, so it may take a
day or two before I forward it. I write this
newsletter in the evenings. If you've read this
far, congratulations, you're the loyal reader of
a cult newsletter on software product management!
(I have gotten a very enthusiastic response to
Product Management Challenges, there's obviously
a real hunger out there among Product Managers.
You're not alone, which also means I encourage
you to contribute material, since chances are
you've got a great idea that someone else could
use today.)

-- Jacques Murphy,
Editor, Product Management Challenges
jacquesm@...

====================================

PREVIOUS TOPICS
To receive copies of topics and tips from over
forty past issues of Product Management
Challenges, send an email to jacquesm@...
requesting the issue number(s) noted in the
list below.
Topics:
02001 - The Two Types of Product Managers
02002 - Requirements: From Hype-ful to Helpful
02003 - Product Research in Today's Tough Times
03001 - Why is the Soft Stuff So Darn Hard?
03002 - Requirements: How Much Is Enough?
03003 - The Development Plan: A Dose of Reality
03004 - Beta Software: Setting Expectations
03005 - Tips for Delivering Consistent Services
03006 - Who Should Do QA Testing?
03007 - In the Spotlight: Demos that Sell
03008 - How Can Product Managers Help Marketing?
03009 - Cutting the Cost of Services and Support
03010 - Pitfalls of the Paper Document Culture
03011 - Requirements 101: The Requirements Document
03012 - Requirements 201: The Requirements Process
03013 - Become an Industry Subject Matter Expert
03014 - Committing to Fixed Release Dates
03015 - An Interview with Alyssa Dver
03016 - Soft Skills: Practice Factuality
03017 - Product Pricing and the Socratic Method
03018 - Product Positioning: Where Do You Stand?
03019 - The Product: Not Just Software Anymore
03020 - Positioning: Making a Statement
03021 - Product Champion: What Does That Mean?
03022 - Straining the Trainer: Training the Sales Force
03023 - Virtual Product Manager: When No Body Will Do
03024 - For Sales: Dispatch to the Front Lines
03025 - Breaking Through to New Technology
03026 - Losing the Battle to Win the War
03027 - Requirements: Envisioning the Product
03028 - Clarifying the Why of Requirements
03029 - That Sisyphean Task of Change
03030 - Effective and Practical UI Design
03031 - The Interrupted Life: Time Management Tips
03032 - A Sales-Driven Product: Perversion and Conversion
03033 - Setting Prices: Dark Art or Evil Science?
03034 - TLC for the RFP
03035 - Contracts: the Letter of the Law
03036 - Two Good Product Management Websites
03037 - Requirements: Like Lambs to the Slaughter
03038 - Product Roadmap to the Promised Land
03039 - ROI and ROR: Return on Requirements
03040 - More TLC for the RFP

====================================

Copyright © 2002, 2003 Jacques Murphy.
All rights reserved.
This insight comes to you from Jacques Murphy.
Contact him at jacquesm@....
Jacques Murphy welcomes requests to make use of
this material in other publications at
jacquesm@....
ABOUT JACQUES MURPHY
Jacques Murphy has over 14 years of experience
in the software industry. He improves the
competitive position of a product through a
comprehensive approach to software product
management that aligns sales, marketing, and
services around efficient, predictable development.
Mr. Murphy is currently editor of a free opt-in
weekly email newsletter called Product Management
Challenges that provides tips on software product
management.
Jacques is Senior Product Manager at Entigo
Corporation, championing a Web-based warranty
chain management solution. More info is available
at www.entigo.com.
Mr. Murphy served as Product Manager for three
years at SEDONA Corporation, where he oversaw 13
successful releases of a Web-based CRM
application for financial services institutions.
Prior to that, he worked for two years as an
independent consultant for software companies
to improve their implementation, documentation,
QA testing, and training efforts.
Jacques spent over five years at Astea
International Inc. providing implementation
consulting, documentation and QA testing for
their call center, field service, and ERP product.
Mr. Murphy holds a B.A. from Oberlin College in
Ohio. He holds an Advanced Diploma in French
Business Studies from La Sorbonne in Paris,
France, and has completed coursework at the
Mandarin Training Center of National Taiwan
Normal University. He has studied and worked in
the United States, France, Taiwan R.O.C., and China.

====================================

SUBSCRIBE
Sign Up for Product Management Tips You Can
Really Use!
To regularly receive helpful tips for software
product management, send an email to
jacquesm@... with "subscribe" in the subject
line or click the link below.
<mailto:jacquesm@...?subject=Subscribe>
TO UNSUBSCRIBE
You don't want to receive insight that improves
the product management of your company's software?
Okay, but I'll miss you! Send an email to
jacquesm@... with "unsubscribe" in the
subject line, or click the link below.
<mailto:jacquesm@...?subject=Unsubscribe>

(Is there a colleague, friend, or boss who might
want to benefit from these tips? Real-world
advice for successful product management is rare,
so pass it on!)

Reply-To: ILPM@yahoogroups.com
Date: Thu, 20 Nov 2003 23:17:05 -0500
To: <ILPM@yahoogroups.com>
Subject: RE: [ILPM] Re: [Toronto PMA] Software Architecture's Business Value -- if any

Software architecture is vital to business value!

A product manager's view of software as black box is dangerous. A discussion about that is too broad and involved, but you should not forget issues of scalability, time to market, modularity, leveraging on platforms, just to name a few very important issues.

While working as product line manager for a large company, we selected a core piece of software from a major supplier (although a much smaller company) for a new family of products. One of our conditions was to review the architecture and even some source code. What we discovered was very poor architecture, patchy piece of software, loosely defined interfaces, lack of scalability, etc. Needless to say we did not strike a partnership, even though the software worked very well. Independently, that vendor later needed to completely rewrite the system and consequently lost market leadership and is currently struggling. With input from our software architect we made a very important product management decision.

Shimon

-----Original Message-----
From: Spinacia [mailto:sp853@...]
Sent: Thursday, November 20, 2003 10:19 PM
To: tpma@yahoogroups.com
Subject: [ILPM] Re: [Toronto PMA] Software Architecture's Business Value -- if any

Does software architecture's have a business value?
To the vendor producing the software there is minimal business value in publicizing the use of a particular software architecture and producing software products that conform to it.  In some markets, the existence of a certain software architecture may imply forethought, credibility and perhaps scalability.   I view software architecture mostly as a competitive differentiator and an element that satisfies RFP specifications.
To the customer, the thing that really matters is functionality and compatibility with business needs.  A software application that optimally implements a certain architecture will have very minimal value if it does not provide functionality that addresses the customer's business needs.


What is a good software architecture?
In accordance with the above comments, I believe that a good software architecture is a technical matter addressed by Development.  From the customer's and product management's perspective it does not make a difference if versions of the software product are based on different programming languages or architectures.

Thanks,
--Gabriel

---

From: "Dennis Layton" <d-layton-is@...>
Reply-To: tpma@yahoogroups.com
Date: Fri, 21 Nov 2003 00:30:59 -0000
To: tpma@yahoogroups.com
Subject: [Toronto PMA] Software Architecture's Business Value -- if any

I was intrigued by Luke Hohmann's post about the business value of
software architecture.

It would be interesting to find out what product managers perceive as
the business value of a good software architecture for a product or
product line. Is there a business value ?  

What is a good software architecture? I know what a good software
architecture is from the perspective of a technical architect, but
what do product managers expect from a software architecture ? Or is
it just something that development team should be concerned about ?


Dennis Layton

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service <http://docs.yahoo.com/info/terms/> .

Yahoo! Groups Sponsor   ADVERTISEMENT

 

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service <http://docs.yahoo.com/info/terms/> .

From: "Dennis Layton" <d-layton-is@...>
Reply-To: tpma@yahoogroups.com
Date: Fri, 21 Nov 2003 00:30:59 -0000
To: tpma@yahoogroups.com
Subject: [Toronto PMA] Software Architecture's Business Value -- if any

I was intrigued by Luke Hohmann's post about the business value of
software architecture.

It would be interesting to find out what product managers perceive as
the business value of a good software architecture for a product or
product line. Is there a business value ?  

What is a good software architecture? I know what a good software
architecture is from the perspective of a technical architect, but
what do product managers expect from a software architecture ? Or is
it just something that development team should be concerned about ?


Dennis Layton

From: "Dennis Layton" <d-layton-is@...>
Reply-To: tpma@yahoogroups.com
Date: Fri, 21 Nov 2003 00:30:59 -0000
To: tpma@yahoogroups.com
Subject: [Toronto PMA] Software Architecture's Business Value -- if any

I was intrigued by Luke Hohmann's post about the business value of
software architecture.

It would be interesting to find out what product managers perceive as
the business value of a good software architecture for a product or
product line. Is there a business value ?  

What is a good software architecture? I know what a good software
architecture is from the perspective of a technical architect, but
what do product managers expect from a software architecture ? Or is
it just something that development team should be concerned about ?


Dennis Layton

I was looking for an example of skewed processes...

Attached is a funny and somewhat realistic cartoon depicting internal
dynamics and views of corporate functions regarding a product.

I downloaded it a while back from Steve Johnson's blog on the
productmarketing.com website.


Please share similar ones if you have any.

Thanks,
--Gabriel
----------------------------------------------------------------------------

Quality management is always the key to success, not cost-cutting...

-----Original Message-----
From: Shimon Shmueli [mailto:shimons@...]
Sent: Tuesday, November 04, 2003 6:03 AM
To: ILPM@yahoogroups.com
Subject: RE: [ILPM] Very interesting article

I agree with most of what you are saying.

 

During my career so far, I have seen many styles of decision making, but my best experience has been in a world-class organization, the IBM ThinkPad development and marketing organization. There decisions were rarely made by an executive, but an the executive charted and facilitated the decision making process and decisions were made by an integrated management team. For most of the major decisions, it was up to the product manager to make a successful case to the integrated management team. 

 

Shimon

 

-----Original Message-----
From: Gabriel Steinhardt [mailto:gs241@...]
Sent: Tuesday, November 04, 2003 12:49 AM
To: ILPM@yahoogroups.com
Subject: RE: [ILPM] Very interesting article

Indeed a very interesting article depicting the amorphous outlook many companies have on Product Managers, the lack of clear and definitive job descriptions in the industry, and the traditional bundling of roles unaccounted for onto a Product Manager.  Mironov is accurately descriptive, but what is the solution to this problem?

 

In my opinion, the premise of "Product Management owns the product feature set, and Engineering owns the product development timeline" should help eliminate many conflicts as it's easy to derive the scope of responsibilities associated with such ownership.  By owning I mean making decisions.

 

Mironov also made a statement that I need to disagree with.  He says: "David Thompson, formerly of iPass and now at Good Technology, taught me that executives are paid to make decisions: a productive day must include least one decision.  Meetings, emails, discussions, forecast reviews and brainstorming are secondary to making decisions that drive action."

 

Executive Management's prime responsibility is formulating business policy and strategy, followed by providing resources to employees so they can do their job.  Once there is a clear and firm policy/strategy that is well propagated internally, decisions become obvious and just tools in driveing a business.

 

Whenever I hear that executives are making a business decision a day, I fear there is loose or no policy/strategy and that the executives are probably overly engaged in running daily business operations (aka micro-management).

 

Thanks,
Gabriel

---

 

----Original Message-----
From: Noa Adamsky [mailto:noa_lif@...]
Sent: Sunday, October 26, 2003 1:44 AM
To: ILPM@yahoogroups.com
Subject: [ILPM] Very interesting article

About the place of the Product Manager inside the organization.
http://www.mironov.com/pb/oct03.html

 

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.


 

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

• Customer Response Times.  There is a company where still today every employee decides for himself in which timeframe he will respond to customers.  Some employees respond immediately, some within the same business day, some within 24 hours, some after a week.  The lack of consistent policy in this matter has created an absolute mess of customer relations.
• Documentation. I saw a company where each department used different document templates for work.  Again, a simple matter that hindered internal collaboration to the point of utter frustration.  The company was bogged down by major inefficiency which caused product development to be delayed by over 12 months.

-----Original Message-----
From: Anat Mondshine [mailto:anatm@...]
Sent: Monday, November 03, 2003 10:52 PM
To: ILPM@yahoogroups.com
Subject: RE: [ILPM] Very interesting article

Hi Gabriel,

 

I understand strategy by I am not sure about policy. That word policy is a bit vague to me especially on the executive level.

 

I have seen a company totally fall apart because the executive or top management just did not know how to go about managing a large corporation that grew very quickly by acquisition.

 

Just to share a real-life story, in this company the little guy with lots of money, little people and little experience was totally overpowered by the big guy with no money but lots people and experience. Of course, as a result no one came out winning. The company filed for bankrupcy and is no longer in business.

 

I find that companies and top management are constantly trying to reinvent themselves going from one management principle to another.

 

Policy?

 

Thanks,

Anat

Gabriel Steinhardt <gs241@...> wrote:

Indeed a very interesting article depicting the amorphous outlook many companies have on Product Managers, the lack of clear and definitive job descriptions in the industry, and the traditional bundling of roles unaccounted for onto a Product Manager.  Mironov is accurately descriptive, but what is the solution to this problem?

 

In my opinion, the premise of "Product Management owns the product feature set, and Engineering owns the product development timeline" should help eliminate many conflicts as it's easy to derive the scope of responsibilities associated with such ownership.  By owning I mean making decisions.

 

Mironov also made a statement that I need to disagree with.  He says: "David Thompson, formerly of iPass and now at Good Technology, taught me that executives are paid to make decisions: a productive day must include least one decision.  Meetings, emails, discussions, forecast reviews and brainstorming are secondary to making decisions that drive action."

 

Executive Management's prime responsibility is formulating business policy and strategy, followed by providing resources to employees so they can do their job.  Once there is a clear and firm policy/strategy that is well propagated internally, decisions become obvious and just tools in driveing a business.

 

Whenever I hear that executives are making a business decision a day, I fear there is loose or no policy/strategy and that the executives are probably overly engaged in running daily business operations (aka micro-management).

 

Thanks,
Gabriel

---

 

----Original Message-----
From: Noa Adamsky [mailto:noa_lif@...]
Sent: Sunday, October 26, 2003 1:44 AM
To: ILPM@yahoogroups.com
Subject: [ILPM] Very interesting article

About the place of the Product Manager inside the organization.
http://www.mironov.com/pb/oct03.html

 

Indeed a very interesting article depicting the amorphous outlook many companies have on Product Managers, the lack of clear and definitive job descriptions in the industry, and the traditional bundling of roles unaccounted for onto a Product Manager.  Mironov is accurately descriptive, but what is the solution to this problem?

 

In my opinion, the premise of "Product Management owns the product feature set, and Engineering owns the product development timeline" should help eliminate many conflicts as it's easy to derive the scope of responsibilities associated with such ownership.  By owning I mean making decisions.

 

Mironov also made a statement that I need to disagree with.  He says: "David Thompson, formerly of iPass and now at Good Technology, taught me that executives are paid to make decisions: a productive day must include least one decision.  Meetings, emails, discussions, forecast reviews and brainstorming are secondary to making decisions that drive action."

 

Executive Management's prime responsibility is formulating business policy and strategy, followed by providing resources to employees so they can do their job.  Once there is a clear and firm policy/strategy that is well propagated internally, decisions become obvious and just tools in driveing a business.

 

Whenever I hear that executives are making a business decision a day, I fear there is loose or no policy/strategy and that the executives are probably overly engaged in running daily business operations (aka micro-management).

 

Thanks,
Gabriel

---

 

----Original Message-----
From: Noa Adamsky [mailto:noa_lif@...]
Sent: Sunday, October 26, 2003 1:44 AM
To: ILPM@yahoogroups.com
Subject: [ILPM] Very interesting article

About the place of the Product Manager inside the organization.
http://www.mironov.com/pb/oct03.html

 

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

About the place of the Product Manager inside the organization.
http://www.mironov.com/pb/oct03.html

-----Original Message-----
From: Gabriel Steinhardt [mailto:gs241@...]
Sent: Monday, November 03, 2003 9:49 PM
To: ILPM@yahoogroups.com
Subject: RE: [ILPM] Very interesting article

Indeed a very interesting article depicting the amorphous outlook many companies have on Product Managers, the lack of clear and definitive job descriptions in the industry, and the traditional bundling of roles unaccounted for onto a Product Manager.  Mironov is accurately descriptive, but what is the solution to this problem?

 

In my opinion, the premise of "Product Management owns the product feature set, and Engineering owns the product development timeline" should help eliminate many conflicts as it's easy to derive the scope of responsibilities associated with such ownership.  By owning I mean making decisions.

 

Mironov also made a statement that I need to disagree with.  He says: "David Thompson, formerly of iPass and now at Good Technology, taught me that executives are paid to make decisions: a productive day must include least one decision.  Meetings, emails, discussions, forecast reviews and brainstorming are secondary to making decisions that drive action."

 

Executive Management's prime responsibility is formulating business policy and strategy, followed by providing resources to employees so they can do their job.  Once there is a clear and firm policy/strategy that is well propagated internally, decisions become obvious and just tools in driveing a business.

 

Whenever I hear that executives are making a business decision a day, I fear there is loose or no policy/strategy and that the executives are probably overly engaged in running daily business operations (aka micro-management).

 

Thanks,
Gabriel

---

 

----Original Message-----
From: Noa Adamsky [mailto:noa_lif@...]
Sent: Sunday, October 26, 2003 1:44 AM
To: ILPM@yahoogroups.com
Subject: [ILPM] Very interesting article

About the place of the Product Manager inside the organization.
http://www.mironov.com/pb/oct03.html

About the place of the Product Manager inside the organization.
http://www.mironov.com/pb/oct03.html

About the place of the Product Manager inside the organization.
http://www.mironov.com/pb/oct03.html

-----Original Message-----
From: anatM [mailto:anatm@...]
Sent: Thursday, October 09, 2003 12:27 AM
To: ILPM@yahoogroups.com
Subject: [ILPM] Company Profile

Hello,

I am new to this forum and I am looking for a definition of Company
Profile. I have been asked to write such a Marketing Document for a
company that deals in health services and I was wondering where I can
find information on the main bullets to include and the best style
for such a document.

Having worked in Product Marketing I do have experience in this but I
am not sure if the way it was done in my previous company is the
correct way of doing it.

Is it a document that should include the following:
* about the company (some background and milestones)
* the mission
* the products
* the people

I think that it should be no longer than 2 pages with graphics and a
background as the eye catchers.

Any feedback would be appreciated...

Thanks,
Anat

Hello,

I am new to this forum and I am looking for a definition of Company
Profile. I have been asked to write such a Marketing Document for a
company that deals in health services and I was wondering where I can
find information on the main bullets to include and the best style
for such a document.

Having worked in Product Marketing I do have experience in this but I
am not sure if the way it was done in my previous company is the
correct way of doing it.

Is it a document that should include the following:
* about the company (some background and milestones)
* the mission
* the products
* the people

I think that it should be no longer than 2 pages with graphics and a
background as the eye catchers.

Any feedback would be appreciated...

Thanks,
Anat

• Sales - The act of interacting with and persuading potential customers to buy the product.

-----Original Message-----
From: Spinacia [mailto:list@...]
Sent: Tuesday, September 30, 2003 3:28 PM
To: ILPM@yahoogroups.com
Subject: [ILPM] Definitions and Terminology - Recap

Thanks for all the feedback. Here is a recap of the definitions that were established today.

• Product Management - The process of defining and maintaining a product through ongoing control of its features.
• Product Marketing - Outbound activities aimed at generating product awareness, differentiation and demand.
• Marketing Communications - A mix of media vehicles that support marketing objectives.

Thanks,

Gabriel

---

Thanks for the through response.  I agree with you on many things.  I would buy the Yellow Sports Hairdryer...

• Marketing Communications - A mix of media vehicles that support marketing objectives.

-----Original Message-----
From: Shimon Shmueli [mailto:shimons@...]
Sent: Tuesday, September 30, 2003 1:50 PM
To: ILPM@yahoogroups.com
Subject: RE: [ILPM] Re: Definitions and Terminology

Interesting....

 

I can live with various definitions of Product Management because they vary from one organization to another and most importantly they need to fit an organization structure, culture, channels, etc. I object to forcing an organization to adopt one definition or another without regards to these factors, however well a certain job definition works for other companies. That does not mean that an organization does not need to challenge itself to industry best practices, and indeed the trend that is emerging, and a correct one in my opinion, is that PM belongs in marketing, and is more inbound in nature. When you define a product, you define it with all the 4P's in mind, with all the 5C's, 7S', and whatever other acronyms exist out there. A product needs to accommodate the requirements of the channel, so if it is a consumer printer for example, and the channel needs to display it at the store and allow people to test it, you design into a product a button that allows testing, or whatever other mechanism. In the same manner you define a product to meet certain cost/pricing, business model, channels, etc. One way to distinguish between PM and PM is to say that Prod Mgt is inbound executing while Prod mktg is outbound executing. I say executing because both need to be observing all of the marketing aspects of the product. 

 

With respect to differentiation, yes, you can try to differentiate a commodity, and product marketing is a way to do it, but in today's market it is increasingly more difficult. Customers are smart, educated, saturated, etc. If you position and differentiate your products when it is ready for launch, you are doing it too late. You need to craft the positioning and differentiations before you start developing it and build them into the product. That is the product manager domain, not the product marketing manager. You can take a box of sugar and put the biggest splash on it and tell people that it is made only from politically correct labor, etc. but at the end of the day they buy it off the shelf, and that means that someone (product manager) needed to price, package, place, etc. the product in a way that matches the splash; otherwise it is back to square one -- it is one of a few commodities on the shelf. 

 

I do believe in the intangible branding aspects, emotional attributes, etc. But they are over-rated, and increasingly so. We, marketers, tend to get arrogant and under appreciate the customers. We believe that we can make a huge difference by coloring an hair drier in yellow and say it is a sports model, expecting to leverage on sport image, but the customers can see right through it. We overestimate our abilities to manipulate customers by words, colors, fonts, sounds, etc. that are not essential part of the product. Yes, branding is very important, but mostly as a promise of value and consistency. Sooner or later you need to show that value in a very tangible way, otherwise your brand will go down vet fast. Witness the fast rise and fall of various brands.

 

Shimon

 

 

-----Original Message-----
From: Spinacia [mailto:list@...]
Sent: Tuesday, September 30, 2003 3:45 PM
To: ILPM@yahoogroups.com
Subject: RE: [ILPM] Re: Definitions and Terminology

Hi Shimon,

I am trying to formulate a clear definition so those who don't fully understand the nature of profession, will be able to establish simplistic comprehension on what it's all about.

 

The PDMA definition is excessive and overly academic.  It will not suffice for my purpose and I believe it's flawed.

I disagree with the notion of mixing distinctly different business functions such product management, product marketing, communication (marcom?), distribution channels (sales?), in an attempt to define what true Product Management is; as the PDMA does.  Also, the PDMA does not have a glossary definition for Product Marketing, which is wrong.

 

As for product marketing.  Products maybe "different" by virtue of their features but "differentiation" is a term relating to the perception customers have of the product. At least that is how I view it...

 

I can add scores of new features to my product, but there will be no "differentiation" if it is not communicated properly.  Conversely, via product marketing I can create "differentiation" for my product although it will be similar (in features) to other products.  Elements of "differentiation" can be non related to physical features - for example: emotional value, status, prestige, reputation, credibility, service... etc'.

 

You said that "It is for product marketing to communicate that differentiation effectively." 

My opinion is that "It is for product marketing to create that differentiation effectively."  Product Management will create "different" products.

Thanks,
Gabriel Steinhardt

 

Moderator

The Israeli Product Marketing Forum
http://ILPM.take.to/

---

 

-----Original Message-----
From: Shimon Shmueli [mailto:shimons@...]
Sent: Tuesday, September 30, 2003 10:59 AM
To: ILPM@yahoogroups.com
Subject: [ILPM] Re: Definitions and Terminology

I believe that the definition on
http://pdma.org/library/glossary.html is quite a good one....
"Ensuring over time that a product or service profitably meets the
needs of customers by continually monitoring and modifying the
elements of the marketing mix, including: the product and its
features, the communications strategy, distribution channels and
price."

At IBM, where I used to practice PMgt, we used to refer to the
position as "product CEO" with all that is implied from that.

As for the product marketing definition, the "differentiation" is
not generated by product marketing, but rather by product management
and is reflected in the product itself and the accompying
positioning and messaging. It is for product marketing to
communicate that differentiation effectively.


--- In ILPM@yahoogroups.com, "Gabriel Steinhardt"
<gabriel_steinhardt@h...> wrote:
> Hi,
> Please comment on the following definitions.  Do you agree?
>
> *      Product Management - The process of defining and maintaining
a
> product through ongoing control of its features.
> *      Product Marketing - Outbound activities aimed at generating
product
> awareness, differentiation and demand.
>
> Thanks,
> Gabriel
>   _____

Thanks for the through response.  I agree with you on many things.  I would buy the Yellow Sports Hairdryer...

• Marketing Communications - A mix of media vehicles that support marketing objectives.

-----Original Message-----
From: Shimon Shmueli [mailto:shimons@...]
Sent: Tuesday, September 30, 2003 1:50 PM
To: ILPM@yahoogroups.com
Subject: RE: [ILPM] Re: Definitions and Terminology

Interesting....

 

I can live with various definitions of Product Management because they vary from one organization to another and most importantly they need to fit an organization structure, culture, channels, etc. I object to forcing an organization to adopt one definition or another without regards to these factors, however well a certain job definition works for other companies. That does not mean that an organization does not need to challenge itself to industry best practices, and indeed the trend that is emerging, and a correct one in my opinion, is that PM belongs in marketing, and is more inbound in nature. When you define a product, you define it with all the 4P's in mind, with all the 5C's, 7S', and whatever other acronyms exist out there. A product needs to accommodate the requirements of the channel, so if it is a consumer printer for example, and the channel needs to display it at the store and allow people to test it, you design into a product a button that allows testing, or whatever other mechanism. In the same manner you define a product to meet certain cost/pricing, business model, channels, etc. One way to distinguish between PM and PM is to say that Prod Mgt is inbound executing while Prod mktg is outbound executing. I say executing because both need to be observing all of the marketing aspects of the product. 

 

With respect to differentiation, yes, you can try to differentiate a commodity, and product marketing is a way to do it, but in today's market it is increasingly more difficult. Customers are smart, educated, saturated, etc. If you position and differentiate your products when it is ready for launch, you are doing it too late. You need to craft the positioning and differentiations before you start developing it and build them into the product. That is the product manager domain, not the product marketing manager. You can take a box of sugar and put the biggest splash on it and tell people that it is made only from politically correct labor, etc. but at the end of the day they buy it off the shelf, and that means that someone (product manager) needed to price, package, place, etc. the product in a way that matches the splash; otherwise it is back to square one -- it is one of a few commodities on the shelf. 

 

I do believe in the intangible branding aspects, emotional attributes, etc. But they are over-rated, and increasingly so. We, marketers, tend to get arrogant and under appreciate the customers. We believe that we can make a huge difference by coloring an hair drier in yellow and say it is a sports model, expecting to leverage on sport image, but the customers can see right through it. We overestimate our abilities to manipulate customers by words, colors, fonts, sounds, etc. that are not essential part of the product. Yes, branding is very important, but mostly as a promise of value and consistency. Sooner or later you need to show that value in a very tangible way, otherwise your brand will go down vet fast. Witness the fast rise and fall of various brands.

 

Shimon

 

 

-----Original Message-----
From: Spinacia [mailto:list@...]
Sent: Tuesday, September 30, 2003 3:45 PM
To: ILPM@yahoogroups.com
Subject: RE: [ILPM] Re: Definitions and Terminology

Hi Shimon,

I am trying to formulate a clear definition so those who don't fully understand the nature of profession, will be able to establish simplistic comprehension on what it's all about.

 

The PDMA definition is excessive and overly academic.  It will not suffice for my purpose and I believe it's flawed.

I disagree with the notion of mixing distinctly different business functions such product management, product marketing, communication (marcom?), distribution channels (sales?), in an attempt to define what true Product Management is; as the PDMA does.  Also, the PDMA does not have a glossary definition for Product Marketing, which is wrong.

 

As for product marketing.  Products maybe "different" by virtue of their features but "differentiation" is a term relating to the perception customers have of the product. At least that is how I view it...

 

I can add scores of new features to my product, but there will be no "differentiation" if it is not communicated properly.  Conversely, via product marketing I can create "differentiation" for my product although it will be similar (in features) to other products.  Elements of "differentiation" can be non related to physical features - for example: emotional value, status, prestige, reputation, credibility, service... etc'.

 

You said that "It is for product marketing to communicate that differentiation effectively." 

My opinion is that "It is for product marketing to create that differentiation effectively."  Product Management will create "different" products.

Thanks,
Gabriel Steinhardt

 

Moderator

The Israeli Product Marketing Forum
http://ILPM.take.to/

---

 

-----Original Message-----
From: Shimon Shmueli [mailto:shimons@...]
Sent: Tuesday, September 30, 2003 10:59 AM
To: ILPM@yahoogroups.com
Subject: [ILPM] Re: Definitions and Terminology

I believe that the definition on
http://pdma.org/library/glossary.html is quite a good one....
"Ensuring over time that a product or service profitably meets the
needs of customers by continually monitoring and modifying the
elements of the marketing mix, including: the product and its
features, the communications strategy, distribution channels and
price."

At IBM, where I used to practice PMgt, we used to refer to the
position as "product CEO" with all that is implied from that.

As for the product marketing definition, the "differentiation" is
not generated by product marketing, but rather by product management
and is reflected in the product itself and the accompying
positioning and messaging. It is for product marketing to
communicate that differentiation effectively.


--- In ILPM@yahoogroups.com, "Gabriel Steinhardt"
<gabriel_steinhardt@h...> wrote:
> Hi,
> Please comment on the following definitions.  Do you agree?
>
> *      Product Management - The process of defining and maintaining
a
> product through ongoing control of its features.
> *      Product Marketing - Outbound activities aimed at generating
product
> awareness, differentiation and demand.
>
> Thanks,
> Gabriel
>   _____

-----Original Message-----
From: Shimon Shmueli [mailto:shimons@...]
Sent: Tuesday, September 30, 2003 10:59 AM
To: ILPM@yahoogroups.com
Subject: [ILPM] Re: Definitions and Terminology

I believe that the definition on
http://pdma.org/library/glossary.html is quite a good one....
"Ensuring over time that a product or service profitably meets the
needs of customers by continually monitoring and modifying the
elements of the marketing mix, including: the product and its
features, the communications strategy, distribution channels and
price."

At IBM, where I used to practice PMgt, we used to refer to the
position as "product CEO" with all that is implied from that.

As for the product marketing definition, the "differentiation" is
not generated by product marketing, but rather by product management
and is reflected in the product itself and the accompying
positioning and messaging. It is for product marketing to
communicate that differentiation effectively.


--- In ILPM@yahoogroups.com, "Gabriel Steinhardt"
<gabriel_steinhardt@h...> wrote:
> Hi,
> Please comment on the following definitions.  Do you agree?
>
> *      Product Management - The process of defining and maintaining
a
> product through ongoing control of its features.
> *      Product Marketing - Outbound activities aimed at generating
product
> awareness, differentiation and demand.
>
> Thanks,
> Gabriel
>   _____




 

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

-----Original Message-----
From: Shimon Shmueli [mailto:shimons@...]
Sent: Tuesday, September 30, 2003 10:59 AM
To: ILPM@yahoogroups.com
Subject: [ILPM] Re: Definitions and Terminology

I believe that the definition on
http://pdma.org/library/glossary.html is quite a good one....
"Ensuring over time that a product or service profitably meets the
needs of customers by continually monitoring and modifying the
elements of the marketing mix, including: the product and its
features, the communications strategy, distribution channels and
price."

At IBM, where I used to practice PMgt, we used to refer to the
position as "product CEO" with all that is implied from that.

As for the product marketing definition, the "differentiation" is
not generated by product marketing, but rather by product management
and is reflected in the product itself and the accompying
positioning and messaging. It is for product marketing to
communicate that differentiation effectively.


--- In ILPM@yahoogroups.com, "Gabriel Steinhardt"
<gabriel_steinhardt@h...> wrote:
> Hi,
> Please comment on the following definitions.  Do you agree?
>
> *      Product Management - The process of defining and maintaining
a
> product through ongoing control of its features.
> *      Product Marketing - Outbound activities aimed at generating
product
> awareness, differentiation and demand.
>
> Thanks,
> Gabriel
>   _____




 

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

I believe that the definition on
http://pdma.org/library/glossary.html is quite a good one....
"Ensuring over time that a product or service profitably meets the
needs of customers by continually monitoring and modifying the
elements of the marketing mix, including: the product and its
features, the communications strategy, distribution channels and
price."

At IBM, where I used to practice PMgt, we used to refer to the
position as "product CEO" with all that is implied from that.

As for the product marketing definition, the "differentiation" is
not generated by product marketing, but rather by product management
and is reflected in the product itself and the accompying
positioning and messaging. It is for product marketing to
communicate that differentiation effectively.


--- In ILPM@yahoogroups.com, "Gabriel Steinhardt"
<gabriel_steinhardt@h...> wrote:
> Hi,
> Please comment on the following definitions.  Do you agree?
>
> * Product Management - The process of defining and maintaining
a
> product through ongoing control of its features.
> * Product Marketing - Outbound activities aimed at generating
product
> awareness, differentiation and demand.
>
> Thanks,
> Gabriel
>   _____

• Product Management - The process of defining and maintaining a product through ongoing control of its features.
• Product Marketing - Outbound activities aimed at generating product awareness, differentiation and demand.

• Pragmatic Marketing Certified Practitioner (PMCP) – A high-stakes, intermediate skill, professional product management certification program. Download from here (200k, PDF).
• The Product Manager’s Toolkit (PMTK) – A comprehensive and evolving set of product management and product marketing document templates.  Download from here (2mb, ZIP).