Skip to main content

Church of the Customer: creating emotional connections

Jackie and Ben have a great blog with Church of the Customer but their PODCAST is even better.

In this podcast, they were talking about how to create emotional connections with your customers/products - something that most FoxPro developers get. And in it, they spoke about a scale that was used by Gallup that was broken into four areas: rational , emotional, pride and passion.

It's an interesting exercise, especially considering the last MS FoxPro survey.

Rational
1. Rate your satisfaction with Visual FoxPro on a scale of 1 to 10.

2. How likely are you to buy/use Visual FoxPro again?
A: Depends on what the need is.

3. How much would you recommend Visual FoxPro to a colleague?
A: Depends on what the need is.

Emotional
Confidence
1. Is FoxPro something you can always trust - Yes or No?

2. Does FoxPro always delivers on what it promises - Yes or No?

Integrity

1. Microsoft/FoxPro always treats me fairly -

2. If a problem arises, will my problem be resolved ? - Yes/No

Pride

1. Are you proud to be a FoxPro developer?

2. MS/FoxPro always treats me with respect

Passion

1. FoxPro is the perfect product for people like me. - Y/N

2. I can't imagine a world without FoxPro . - Y/N

Is this survey flawed?
Jackie and Ben do a great job of tearing apart the concept of a satisfaction survey by asking:

How do respondents define "respect", "fairly", "pride" or 'satisfaction'?

From their point, the only questions that really mean something as far as creating that emotional intent is the one that refers to recommendability.

When I tried the above survey with FoxPro as my product, the only areas where I could even come up with a complete answer (one without it depends or N/A) were the last two on the topic of passion.

Compare this with the recent Microsoft survey. After going through all of the questions in that survey , the one that still stands out in my mind was:

a) what features make you want to buy/upgrade FoxPro?

This is where Microsoft sees the product revenue. VFP 9 is chock-full of developer goodies that require the developer to grow them into a meaningful application. That's great to satisfy the developer - but eventually, the developer has to answer to the customer and the customer , unfortunately, needs the eye-candy. (see my post on Office style tools)

Sure, there were lots of other questions but that one is the key point because one needs to have some reason to recommend upgrading and recommendability is likely the biggest area where Visual FoxPro suffers, overall as a developer tool.

At this stage, readers may be going "I always recommend FoxPro" but the answer for a recommendation in development tools should almost always be "it depends on the need".

Every solution is not in need of a hammer and when someone asks for a database, the first word on everyone's lips is NOT FoxPro, it's likely MySQL or SQL Server or _____. (and if you've ever heard Jim Duffy speak, FoxPro and database simply aren't two words that should ever be used together).

And if you ask about programming languages, you'll likely get a wide variety of responses as well. You want OOP - Why not use C++ or C#?

The recommended tool should always depend on the need.

And often, I find, the FoxPro developer, although loud in the community, doesn't beat the drum loud enough in their own organization to get it recommended. Maybe it's because they're tired of always having to defend the product. It was different in the early 90s because everything was about speed, an area where FoxPro wins hands-down. Now, it's also about security, maintainability, user interface, access and design.

So then the person asking the question "what tool should I use?" asks the next best person, who would be _________.

So who is that person?

Is it an IT person? IT won't likely recommend a FoxPro solution because they can't control it.

Is it Sales? Microsoft Sales won't recommend VFP because they make more $$ from other tools but there's an implied disingenuous feel here because their job is to make money. Likewise, a retail sales person won't recommend it because, well, when was the last time you saw FoxPro in a retail store?

Is it Marketing? (see Sales)

Who do YOU think that person is?

The podcast is only 30 minutes but the section on creating the emotiional connection is in the first 15 minutes and well worth the listen.

Church of the Customer: Podcast: Can't get no satisfaction; creating emotional connections

Comments

Popular posts from this blog

Blogs and RSS come to Microsoft.com

MS has just introduced their portal and it's pretty comprehensive. Nothing quite like learning that some people use AIM instead of MSN messenger, or that there really may be a need for supporting 4 monitors ( Cyrus Complains ) However, it's really a great sign that MS is serious about supporting the blogging community which seems to have um, exploded in size in the past year. Blogs and RSS come to Microsoft.com

Elevating Project Specifications with Three Insightful ChatGPT Prompts

For developers and testers, ChatGPT, the freely accessible tool from OpenAI, is game-changing. If you want to learn a new programming language, ask for samples or have it convert your existing code. This can be done in Visual Studio Code (using GitHub CoPilot) or directly in the ChatGPT app or web site.  If you’re a tester, ChatGPT can write a test spec or actual test code (if you use Jest or Cypress) based on existing code, copied and pasted into the input area. But ChatGPT can be of huge value for analysts (whether system or business) who need to validate their needs. There’s often a disconnect between developers and analysts. Analysts complain that developers don’t build what they asked for or ask too many questions. Developers complain that analysts haven’t thought of obvious things. In these situations, ChatGPT can be a great intermediary. At its worst, it forces you to think about and then discount obvious issues. At best, it clarifies the needs into documented requirements. ...

Programmers vs. Developers vs. Architects

I received an email this morning from Brandon Savage 's newsletter. Brandon's a PHP guru (works at Mozilla) but his newsletter and books have some great overall perspectives for developers of all languages. However, this last one (What's the difference between developers and architects?) kind of rubs me the wrong way. Either that, or I've just missed the natural inflation of job descriptions. (maybe, it's like the change in terminology between Garbage man and Waste Engineer or Secretary and Office Administrator) So maybe it's just me - but I think there's still a big difference between Programmer, Developer and then of course, architect. The key thing here is that every role has a different perspective and every one of those perspectives has value. The original MSF create roles like Product Manager, Program Manager, Developer, Tester, etc - so every concept may pigeon hole people into different roles. But the statements Brandon makes are often distinction...