I am absolutely fed up with talking to people at software companies who don’t have a clue about their customers. It’s a Software Worst Practice.
I’ve heard some of the most pathetic excuses lately, from all functional areas of software companies:
- “I’m in PR, someone else comes up with the content”.
- “I’m a developer, I write code”.
- “I’m a performance architect, my job is to remove bottlenecks and make things go fast”.
- “I sell, Sales is based on relationships and closing skills”.
- “I’m the CFO, other people do that”.
- “I have a team of product managers who are experts in that area”.
- “I’m the Sales VP, my job is to commit to a number, drive my Reps hard, and hit my target quarter after quarter”.
- “I get what I need from Gartner and Forrester”.
- “Our developers know the latest technology trends – we’re technology-driven”.
- “I’m a Marketing generalist”.
- “Our CTO is the visionary…we follow him/her”.
Those excuses are a big bag of
horseshit horse-puckey. Pathetic. All of them.
They demonstrate that people are shirking their responsibilities – often hiding behind “someone else does that” or “I don’t need to do that” or the worst: “I’m a visionary, I already know that”.
This disease riddles many software companies. It’s often accompanied by the drinking of astonishing quantities of Kool-Aid (the “denial” flavor is particularly popular).
All these people banded together, thinking they know where they’re going…when in fact it’s “over a cliff” – lemming style.
First Commandment of Software: Know thy Customer
Everyone in the company needs an appropriately deep understanding of the target customer – how the software is used, who uses it, what problems it solves, why that is important, what other alternatives the customer has.
In the context of a software vendor:
- A C-level executive that doesn’t know these things has no business leading a software firm.
- A Marketing or PR person who doesn’t know these things has no business marketing anything.
- A Sales person who doesn’t know these things ought not to be selling that software or probably anything else.
- A Sales Manager/Director/VP who is clueless in this area, can’t train new Sales Reps and is a sad example to follow.
- A Developer or Architect who doesn’t know these things is running blind.
- An Engineering manager who doesn’t know these things should find some other profession.
- A Product Manager or Product Marketing Manager who doesn’t know these things should be taken out and shot (figuratively, though I’d be tempted – I live in Texas, so it might be OK here).
I could go on, but I think I’ve made my point.
Are you a Visionary, or are you Smart and Deluded?
Knowing your customer (or “target customer”) is the MOST IMPORTANT thing you can do to create Great Software (and Great Software companies). I daresay any business, for that matter. It is the foundation upon which wildly successful companies are built. Companies like Apple, where knowing the customer has been taken to a new level.
Steve Jobs isn’t a visionary because he’s psychic or amazingly intelligent. A lot of CTO’s seem to believe that smart = visionary. Or worse yet, smart + some previous success = super visionary. Super-deluded is usually more like it.
Steve Jobs is a visionary because he (and his people) live and breathe customer needs, wants and priorities. And because he combines that with brilliant insight and a lack of tolerance for compromise on the 1st Commandment.
Avoiding the Cliff of Delusion and the Pit of Ignorance
One “best practice” tool for helping spread knowledge of the customer is the “use case”. I’ve written an article on SysCon Media/Ulitzer on the topic – “Software Best Practices: Use Cases are for Everyone“.
Learning More about Use Cases
One excellent resource is the “Building Better Software” blog. If for no other reason, you should visit their blog because of their tagline “…because people want their software to work”. That’s brilliant. A great starting point is “Requirements 101: User Stories vs. Use Cases“.
Another great resource: Joy Beatty is an expert in the area of use cases and software requirements – typically for commercial customers, rather than software vendors. She has produced a 2 minute video which gives an concise and understandable overview of what a formal use case looks like, as well as dozens of other business analyst-focused articles.