The newbie and griefer: 2 customers that break your sales & how to deal with them

Howdy! 👋 This is the 1st in a series of posts about pricing software development services. We will try to give you market data, underline common industry problems, share some good practices and help you sell more. Today's issue is all about specific types of customers that sales teams and founders of many tech companies don't fully get. Let's see if we can change this situation together.

You might be thinking "wait, there's lots of types of customers" - and you are correct. Depending on the criteria you might differentiate your leads & clients by size, headcount, revenue, geographic region, target markets, and so on. We have all heard the truisms and stereotypes: the French don't like speaking English, telcos & banks are always behind the curve, startups require constant changes, and so on. Depending on your business model and experience any of these distinctions might work, but what we wish to focus on are the buyer personas. The real people you sell to, with their concerns and priorities.

In our eyes, you don't sell just to an organization: you sell to a human.

Persona 1: the newbie

People in general are often irritated by newcomers to a particular scene. Playing most popular multiplayer games for the 1st time can result in a pretty nasty chat messages log, interns are often badly treated in bigger companies and you certainly don't want to show up to a tournament for your first taste of a particular sport. What we often fail to grasp is that everyone has to start somewhere. Someone with no knowledge or background indeed has nothing to fall back on and can at times act, in our judgement, irrationally. In such cases, our role is to be their mentor and show them all the quirks of an industry.

Software development is an extremely complex industry, with a wide variety of challenges to solve. Even companies who otusource their projects usually have a CTO or separate contractors with technical background just to understand the specifications and processes and give educated feedback.  But what if they don't?

This is often the predicament of smaller companies and startups, though larger orgs can also be found lacking in this regards. I'm sure some of you have been contacted by founders, CEOs and managers who, simply speaking, had no clue about software development at all. Some common indicators would be:

• Lack of understanding on the purpose of certain parts of a project (especially refactoring, maintenance and other non-UI stuff)
• Mockups made on a sheet of paper or in PowerPoint (if you were so far lucky: yes, these exist. I've encountered both)
• Extremely frequent meetings & calls that have no stated purpose and contribute to nothing (can also be a sign of bureaucracy; my personal fave is a customer demanding 4 calls a week for a simple CRUD with 3 fields)
• Instructions summed up as "copy competitor X"; this also shows a lack of product management capabilities, as the markets & end users might differ in even slight ways
• Frequent questions on meaning of certain jargon phrases (good sign) that repeat continuously and seem to never be remembered (bad sign)
• No idea about Agile, Sprints and usual processes & development cycle; worse yet, active opposition towards Agile development with no good reasons
• Constant back-and-forth changes that burn precious time and provide little to no value
• "Just make it work"

As you can see, some of these can often be caused by neglect, lack of time or general bureaucracy. However, when you see any of these red flags, it's good to step back, take a deep breath and try to gauge if the person you're speaking to has any understanding of software development, or at least advisors with such knowledge.

Newbies have no bad intentions - they simply don't know any better and put in as much effort as they can.

Impact on your proposals

Newbies will usually try to aggressively cut the costs down - going as far as demanding full, important parts of a project to be thrown out. This might be quite severe, as many customers of this kind will first tell you to skip mobile development altogether, only to complain about the product being botched on iPhones a week later.

They are also prone to unconscious feature creep: since they don't fully understand the complexity of certain actions ("It's just 1 button, right?"), they might ask for many additional changes without regards to deadlines or budget. In extreme cases a massive volume of such requests can derail the whole project or make it non-feasible for you.

It's a good practice to state the cost of additional development (such as hourly rate), with examples of how many hours perceived/common additional functionalities might take. This will give the customer some level of orientation in pricing and ballpark figures to lean back on.

What can you do about newbies?

First and foremost - educate and guide. Whenever you speak on a call, write an e-mail or open Slack, take a second look at your words. During price quotations, explain everything in great detail. Go point-by-point. Prepare enough time to take and answer questions.

Does your message contain any jargon words? Not just actual jargon, but even things you might consider simple, but would pose a challenge to a newcomer. For instance, writing "testing environment" might be self-explanatory to me and you. To a complete outsider, it will pop up questions: what is an environment? what is being tested? how? can I access it? How will I know the test results? and so on.

I know it takes serious time and effort to elaborate. Worse yet, often you will feel unfulfilled and underappreciated when somebody ignores your explanations. However, this is the only way. You absolutely must do the 3 Es: Explain, Elaborate, Enlighten.

If you feel any kind of negative emotions (anger, stress, irritation, tiredness) - take a break. Don't answer or reply until these go away. We're all just humans and we all have a right to feel bad. We also often look for others to blame and vent internally, in our minds or to a team. As humans we also often make mistakes and don't fully get the situation of another person. We might joke and curse on a customer asking seemingly moronic questions mid-development, but it's possible they are currently fighting a crisis in their company or desperately trying to stay afloat. During the recent pandemic many restaurant owners had to develop or integrate delivery systems. Many of them had the desire to learn and be more knowledgeable, but this is quite hard when you're facing 10+ months of lockdowns and savings are rapidly diminishing.

Sadly, there's no better advice to be given here: just like a teacher in school, any parent or a travel guide, you have to be patient and forgiving. The upside being, once you show the good will and give your customer some knowledge, they will trust you more and develop together with you. In the end, both of you will learn something and improve your processes.

Persona 2: the griefer

Sometimes you will encounter a person that has the required knowledge, or at least seems to be learning fast on their own. The project does not go very well though, with very common signs being:

• Nigh-impossibility to get any decisions made of the customer's side
• Very frequent negative remarks about the previous developers (often found with updates, migrations and modernization of services).
• Constant demands of proofs, reports and basis of technical decisions
• More weight being put on documentation than the end product itself
• Constant comparisons to other vendors, tools and competitors (usually negative)
• Threats about contract terms even before the deadline
• Direct comparisons to past projects, be it yours or completely different
• Once again, way too frequent meetings & calls. This time they do have a purpose, which is usually to ask you "what are you even doing now"
• Lack of patience from the get-go
• General lack of mutual trust

These are common signs of a griefer: a person who had done other software development projects in the past, got burned, and is now (consciously or not) being ever too careful, ever controlling and ever fearful. Similar to a partner with very bad exes, at times their decisions will be affected by the bad memories and light traumas of days gone.

Griefers are traumatized by past projects - even ones in different companies, countries or decades. They have been scarred and are trying to cope.

Impact on your proposals

Griefers are rarely concerned with the initial budget or deadlines. You might get remarks such as "according to us, this should take around 10 hours, not 70". Mind that a newbie would not say this, as they don't know how much time a specific development subset takes. Griefers usually know, because someone else did it in 10 hours - most likely poorly, otherwise they would continue the cooperation and not become griefers in the first place.

Major problems usually arise later on, when they become control freaks always afraid of you slacking or trying to inflate your work hours. As some of you sadly know, enough bureaucratic requirements on customer side can grind any project to a halt, and lack of decisions might break the whole thing apart.

How to deal with griefers?

It's very hard to check the history of software development cooperation of a particular customer. Depending on how negotiations go, you might learn this yourself or be able to ask such a question directly. If so - good for you! The more you know, the better you can prepare.

If you find out or suspect a customer might be a griefer, I recommend long-term building of rapport. Don't wait until they ask - give frequent updates on your own. Communicate and underline successes, even minor ones. Whenever possible, show them the product in action, be it on video or a separate environment.  When important decisions are needed, don't write e-mails. Call them instead, state the urgency and effects of further decision delays. Show that you care about the project, that you truly want it delivered on time and with great quality. The more insight and tips you give, the better. This might sound hard, but usually isn't. Once your day starts, go back to the griefer's project and ask yourself if there is anything that you can do to impress, any still-standing obstacles to overcome and when did you last report to the customer.

When comparisons to other services become too common, try to cut them short. There's not much purpose in going over details ("our data sync happens every 5 minutes instead of hourly"), as most likely neither you neither the griefer know the other product too well. It's also impossible to be better in everything. Instead, try to gauge or ask about the customer's actual priorities and try to address them.

If the situation becomes extremely hostile, one last thing you can try is to state that you are aware they might have had bad development experiences in the past, but you are a different company and team. Ask for benefit of the doubt and earn respect with your great work.

Summary

Obviously, the newbie and griefer and by far not the only customer archetypes you encounter out in the wild. In fact, for many they pose specific niches and are rare encounters. However, dealing with them is crucial, as they often break your sales cycle and cause major headaches.

And what about YOU? Have you encountered any newbies or griefers so far? Or other interesting customer types? Let us know in the comments below!

Stay tuned for the next time 👋

‍