<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.3" -->
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	>
<channel>
	<title>Comments for Sales Process Engineering</title>
	<link>http://www.salesprocessengineering.net</link>
	<description>The application of process-engineering principles (particularly TOC) to the sales process</description>
	<pubDate>Wed, 10 Mar 2010 17:41:11 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.3</generator>
		<item>
		<title>Comment on Why the term &#8216;communication problem&#8217; insults your team members and retards the performance of your organization by Sales Process Engineering &#187; Blog Archive &#187; How to get the most out of Manufacturer&#8217;s Reps (and distributors)</title>
		<link>http://www.salesprocessengineering.net/2009/07/25/why-the-term-communication-problem-insults-your-team-members-and-retards-the-performance-of-your-organization/#comment-681</link>
		<dc:creator>Sales Process Engineering &#187; Blog Archive &#187; How to get the most out of Manufacturer&#8217;s Reps (and distributors)</dc:creator>
		<pubDate>Fri, 08 Jan 2010 20:40:57 +0000</pubDate>
		<guid>http://www.salesprocessengineering.net/2009/07/25/why-the-term-communication-problem-insults-your-team-members-and-retards-the-performance-of-your-organization/#comment-681</guid>
		<description>[...] of the fact that formal workflows are required and that these workflows must be designed to eliminate the requirement for the trasfer of anything other than simple information.&#160; The key to doing this effectively is to ensure that any complex workflows are managed by [...]</description>
		<content:encoded><![CDATA[<p>[&#8230;] of the fact that formal workflows are required and that these workflows must be designed to eliminate the requirement for the trasfer of anything other than simple information.&nbsp; The key to doing this effectively is to ensure that any complex workflows are managed by [&#8230;]</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on The myth of branding by David Sandusky</title>
		<link>http://www.salesprocessengineering.net/2008/07/07/the-myth-of-branding/#comment-632</link>
		<dc:creator>David Sandusky</dc:creator>
		<pubDate>Thu, 05 Nov 2009 04:13:52 +0000</pubDate>
		<guid>http://www.salesprocessengineering.net/2008/07/07/the-myth-of-branding/#comment-632</guid>
		<description>I enjoyed this well thought out post and mostly agree.  I do feel it is unfortunate that the big climax "So, is a brand actually worth anything?" is about commodities.  The discussion looses water on the sales person's side because selling a commodity is about and only about proximity to need.  Oil. Bananas. Cotton. No brand value and no reason to get all caught up in price and what we "stand for". 

The experience of actual brand loyalty (Coke v Pepsi) is proven when the brand champion will go out of her way to get a Coke over a Pepsi or choose nothing.  In my personal findings, more people will go out of way for Coke than for Pepsi (at least in my region).  There is your brand value. 

Well written...will follow your work.</description>
		<content:encoded><![CDATA[<p>I enjoyed this well thought out post and mostly agree.  I do feel it is unfortunate that the big climax &#8220;So, is a brand actually worth anything?&#8221; is about commodities.  The discussion looses water on the sales person&#8217;s side because selling a commodity is about and only about proximity to need.  Oil. Bananas. Cotton. No brand value and no reason to get all caught up in price and what we &#8220;stand for&#8221;. </p>
<p>The experience of actual brand loyalty (Coke v Pepsi) is proven when the brand champion will go out of her way to get a Coke over a Pepsi or choose nothing.  In my personal findings, more people will go out of way for Coke than for Pepsi (at least in my region).  There is your brand value. </p>
<p>Well written&#8230;will follow your work.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Video interiew with Fabiano Aguilar (Agentrics) by SKI</title>
		<link>http://www.salesprocessengineering.net/2009/11/05/video-interiew-with-fabiano-aguilar-agentrics/#comment-631</link>
		<dc:creator>SKI</dc:creator>
		<pubDate>Thu, 05 Nov 2009 02:28:38 +0000</pubDate>
		<guid>http://www.salesprocessengineering.net/2009/11/05/video-interiew-with-fabiano-aguilar-agentrics/#comment-631</guid>
		<description>Justin

Good stuff. Your breakthrough in Sales Process Engineering is as profound as any Constraints Management tool in use today. 

Thanks for sharing.

-ski</description>
		<content:encoded><![CDATA[<p>Justin</p>
<p>Good stuff. Your breakthrough in Sales Process Engineering is as profound as any Constraints Management tool in use today. </p>
<p>Thanks for sharing.</p>
<p>-ski</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on If you tell your team to ‘maximize sales’ that may be a tacit admission of a flaw in the design of your business! by SKI</title>
		<link>http://www.salesprocessengineering.net/2009/08/02/if-you-tell-your-team-to-%e2%80%98maximize-sales%e2%80%99-that-may-be-a-tacit-admission-of-a-flaw-in-the-design-of-your-business/#comment-609</link>
		<dc:creator>SKI</dc:creator>
		<pubDate>Sun, 02 Aug 2009 12:48:04 +0000</pubDate>
		<guid>http://www.salesprocessengineering.net/2009/08/02/if-you-tell-your-team-to-%e2%80%98maximize-sales%e2%80%99-that-may-be-a-tacit-admission-of-a-flaw-in-the-design-of-your-business/#comment-609</guid>
		<description>Great mental exercise for a Sunday morning. 

May I suggest that you forgot two other likely choices?

4. Status Quo

I always list it first. It provides an easy way to bail out of a project when you find out the leadership is paying lip service to change. Nothing will take years off one's life faster than dealing with bozos on a daily basis. Life is too short. Of course when you noticed the (perfectly healthy) CEO's Porsche consistently parked in the handicap spot in front of the building, you should have found a quicker way to bail... but I digress.

5. Biz Basics Boot Camp

People rarely know what they do not know. Justin's work on SPE is just so much common sense. So much so, that the first time I read one of his White Papers on it, I thought he was all wrong.

But over coffee one morning, just thinking about the ramifications of Ballistix SPE, I had to admit that he was absolutely 100% spot on. When you take the time to think it through (something most Americans just hate to do!), there is but one conclusion: SPE has to work.

But in my experience, just like fitting a rocket engine to your Piper Cub, bolting on SPE to most organizations is not going to work. At least not for long. Until the underlying assumptions are challenged (and exposed), any gains will be short lived. At best. Most often, they are simply rejected outright.

That "If there were a better way, we would have thought it" ego-speak of the doomed. Enter the requirement to 'school' leadership as well as the rank &#38; file on business basics. Think military: they train and train, then train some more. All just to be effective.

Ask yourself: when was the last time you attended any training?

Thanks again Justin for a great article on addressing the weakest link.

-ski</description>
		<content:encoded><![CDATA[<p>Great mental exercise for a Sunday morning. </p>
<p>May I suggest that you forgot two other likely choices?</p>
<p>4. Status Quo</p>
<p>I always list it first. It provides an easy way to bail out of a project when you find out the leadership is paying lip service to change. Nothing will take years off one&#8217;s life faster than dealing with bozos on a daily basis. Life is too short. Of course when you noticed the (perfectly healthy) CEO&#8217;s Porsche consistently parked in the handicap spot in front of the building, you should have found a quicker way to bail&#8230; but I digress.</p>
<p>5. Biz Basics Boot Camp</p>
<p>People rarely know what they do not know. Justin&#8217;s work on SPE is just so much common sense. So much so, that the first time I read one of his White Papers on it, I thought he was all wrong.</p>
<p>But over coffee one morning, just thinking about the ramifications of Ballistix SPE, I had to admit that he was absolutely 100% spot on. When you take the time to think it through (something most Americans just hate to do!), there is but one conclusion: SPE has to work.</p>
<p>But in my experience, just like fitting a rocket engine to your Piper Cub, bolting on SPE to most organizations is not going to work. At least not for long. Until the underlying assumptions are challenged (and exposed), any gains will be short lived. At best. Most often, they are simply rejected outright.</p>
<p>That &#8220;If there were a better way, we would have thought it&#8221; ego-speak of the doomed. Enter the requirement to &#8217;school&#8217; leadership as well as the rank &amp; file on business basics. Think military: they train and train, then train some more. All just to be effective.</p>
<p>Ask yourself: when was the last time you attended any training?</p>
<p>Thanks again Justin for a great article on addressing the weakest link.</p>
<p>-ski</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Why the term &#8216;communication problem&#8217; insults your team members and retards the performance of your organization by Communication Problems are actually Process Design Problems &#124; Reach1to1 Technologies</title>
		<link>http://www.salesprocessengineering.net/2009/07/25/why-the-term-communication-problem-insults-your-team-members-and-retards-the-performance-of-your-organization/#comment-606</link>
		<dc:creator>Communication Problems are actually Process Design Problems &#124; Reach1to1 Technologies</dc:creator>
		<pubDate>Wed, 29 Jul 2009 16:45:13 +0000</pubDate>
		<guid>http://www.salesprocessengineering.net/2009/07/25/why-the-term-communication-problem-insults-your-team-members-and-retards-the-performance-of-your-organization/#comment-606</guid>
		<description>[...] Justin Roff-Marsh, proponent of his highly effective Sales Process Engineering methodology that incorporates the techniques from Theory of Constraints into the sales process &#8211; has written an excellent article on his Sales Process Engineering blog, where he explains &#8220;Why the term ‘communication problem’ insults your team members and retards the performance of yo...&#8220;. [...]</description>
		<content:encoded><![CDATA[<p>[&#8230;] Justin Roff-Marsh, proponent of his highly effective Sales Process Engineering methodology that incorporates the techniques from Theory of Constraints into the sales process &#8211; has written an excellent article on his Sales Process Engineering blog, where he explains &#8220;Why the term ‘communication problem’ insults your team members and retards the performance of yo&#8230;&#8220;. [&#8230;]</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Why the term &#8216;communication problem&#8217; insults your team members and retards the performance of your organization by Malcolm Ryder</title>
		<link>http://www.salesprocessengineering.net/2009/07/25/why-the-term-communication-problem-insults-your-team-members-and-retards-the-performance-of-your-organization/#comment-604</link>
		<dc:creator>Malcolm Ryder</dc:creator>
		<pubDate>Sun, 26 Jul 2009 19:45:44 +0000</pubDate>
		<guid>http://www.salesprocessengineering.net/2009/07/25/why-the-term-communication-problem-insults-your-team-members-and-retards-the-performance-of-your-organization/#comment-604</guid>
		<description>Hi Justin. Nice bit.

Just for the sake of commentary: I think there are some fine points to your great observation.

1. Complex information can be handed off. Translation may be necessary. Information transformation is not the same thing as information loss. In fact, a key thing to understand is that users of Information Type X may add, modify and delete *data* in order to produce Information Type Y, with nothing "lost" that is important to a process.

2. In Example A, I think you're describing the need for an architect. This is not the same as a project leader. A project leader is a production manager. An architect is an analyst/designer. It's the architect that does the translation of Info Type X to Info Type Y.

3. In example B, your punchline is really great. You would want your consultants to acquire the skillsets for requirements analysis and use case definition. The developers understand that handoff, even if it is complex information.

My own punchline here is a personal favorite: complexity and complication are not the same thing. Complication you want to get rid of, in general; whereas, many extremely valuable things to have or do cannot exist without complexity. When something complex is valuable and needed, you don't want it to be replaced or obscured by something complicated...</description>
		<content:encoded><![CDATA[<p>Hi Justin. Nice bit.</p>
<p>Just for the sake of commentary: I think there are some fine points to your great observation.</p>
<p>1. Complex information can be handed off. Translation may be necessary. Information transformation is not the same thing as information loss. In fact, a key thing to understand is that users of Information Type X may add, modify and delete *data* in order to produce Information Type Y, with nothing &#8220;lost&#8221; that is important to a process.</p>
<p>2. In Example A, I think you&#8217;re describing the need for an architect. This is not the same as a project leader. A project leader is a production manager. An architect is an analyst/designer. It&#8217;s the architect that does the translation of Info Type X to Info Type Y.</p>
<p>3. In example B, your punchline is really great. You would want your consultants to acquire the skillsets for requirements analysis and use case definition. The developers understand that handoff, even if it is complex information.</p>
<p>My own punchline here is a personal favorite: complexity and complication are not the same thing. Complication you want to get rid of, in general; whereas, many extremely valuable things to have or do cannot exist without complexity. When something complex is valuable and needed, you don&#8217;t want it to be replaced or obscured by something complicated&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Why the term &#8216;communication problem&#8217; insults your team members and retards the performance of your organization by Jack Vinson</title>
		<link>http://www.salesprocessengineering.net/2009/07/25/why-the-term-communication-problem-insults-your-team-members-and-retards-the-performance-of-your-organization/#comment-602</link>
		<dc:creator>Jack Vinson</dc:creator>
		<pubDate>Sun, 26 Jul 2009 01:27:33 +0000</pubDate>
		<guid>http://www.salesprocessengineering.net/2009/07/25/why-the-term-communication-problem-insults-your-team-members-and-retards-the-performance-of-your-organization/#comment-602</guid>
		<description>Thanks, Justin.  I completely agree with the sentiment that if we leave the blame at something we think we can't control, then we leave ourselves open to that problem again and again.  

I had an entertaining comment from a client recently, where "communication" has been a question.  He "discovered" that the project wasn't much more than a means to improve communication in the organization.</description>
		<content:encoded><![CDATA[<p>Thanks, Justin.  I completely agree with the sentiment that if we leave the blame at something we think we can&#8217;t control, then we leave ourselves open to that problem again and again.  </p>
<p>I had an entertaining comment from a client recently, where &#8220;communication&#8221; has been a question.  He &#8220;discovered&#8221; that the project wasn&#8217;t much more than a means to improve communication in the organization.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Why the term &#8216;communication problem&#8217; insults your team members and retards the performance of your organization by clarke chign</title>
		<link>http://www.salesprocessengineering.net/2009/07/25/why-the-term-communication-problem-insults-your-team-members-and-retards-the-performance-of-your-organization/#comment-601</link>
		<dc:creator>clarke chign</dc:creator>
		<pubDate>Sat, 25 Jul 2009 08:57:05 +0000</pubDate>
		<guid>http://www.salesprocessengineering.net/2009/07/25/why-the-term-communication-problem-insults-your-team-members-and-retards-the-performance-of-your-organization/#comment-601</guid>
		<description>Nice work Justin.</description>
		<content:encoded><![CDATA[<p>Nice work Justin.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on A strategy for coping with tough economic times by Sales Process Engineering &#187; Blog Archive &#187; My Industry Week webinar online for you to view</title>
		<link>http://www.salesprocessengineering.net/2009/02/20/a-strategy-for-coping-with-tough-economic-times/#comment-588</link>
		<dc:creator>Sales Process Engineering &#187; Blog Archive &#187; My Industry Week webinar online for you to view</dc:creator>
		<pubDate>Fri, 22 May 2009 00:15:29 +0000</pubDate>
		<guid>http://www.salesprocessengineering.net/2009/02/20/a-strategy-for-coping-with-tough-economic-times/#comment-588</guid>
		<description>[...] The title is: How to grow sales in a shrinking economy.&#160; It&#8217;s an introduction to SPE, along the lines of my past post entitled A strategy for coping with tough economic times. [...]</description>
		<content:encoded><![CDATA[<p>[&#8230;] The title is: How to grow sales in a shrinking economy.&nbsp; It&#8217;s an introduction to SPE, along the lines of my past post entitled A strategy for coping with tough economic times. [&#8230;]</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on The business case for CRM by SKI</title>
		<link>http://www.salesprocessengineering.net/2009/05/14/the-business-case-for-crm/#comment-587</link>
		<dc:creator>SKI</dc:creator>
		<pubDate>Thu, 14 May 2009 11:22:16 +0000</pubDate>
		<guid>http://www.salesprocessengineering.net/2009/05/14/the-business-case-for-crm/#comment-587</guid>
		<description>Consider that for the small privately held firm, an Apple Mac and the iPhone (and/or iPod touch) are more effective than most any m$ft offering, IMNSHO.

For larger companies, it is the lack of planning that kills any CRM implementation. Lack of vision and the blind hope that a new tool is going to make it all better. If you are a bozo before CRM, you will still be a bozo after the CRM implementation.

FYI: If as you suggest, CRMs are bought to "automate" Sales, then the organization is beyond hope. But I digress.

-ski

P.S. As I share your SPE approach with entrepreneurs, many are simply amazed that you have discovered what they could not: the missing link with regard to the B2B Sales function. Keep up the good work.</description>
		<content:encoded><![CDATA[<p>Consider that for the small privately held firm, an Apple Mac and the iPhone (and/or iPod touch) are more effective than most any m$ft offering, IMNSHO.</p>
<p>For larger companies, it is the lack of planning that kills any CRM implementation. Lack of vision and the blind hope that a new tool is going to make it all better. If you are a bozo before CRM, you will still be a bozo after the CRM implementation.</p>
<p>FYI: If as you suggest, CRMs are bought to &#8220;automate&#8221; Sales, then the organization is beyond hope. But I digress.</p>
<p>-ski</p>
<p>P.S. As I share your SPE approach with entrepreneurs, many are simply amazed that you have discovered what they could not: the missing link with regard to the B2B Sales function. Keep up the good work.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
