‘The Expert’ does not display the right kind of expertise

Exec Summary

The comedy sketch ‘The Expert‘ shows an ‘expert’ that never tries to understand the customer’s needs. Customers are customers because they have problems that need to be solved. Yes, they may have some ideas of their own (e.g. 7 red lines, some transparent), but their real need is to solve the problems that they are facing. Telling a customer why their idea is not possible is time-wasting. Asking a customer what their problem is allows you to offer a real solution. It also raises the credibility of any ideas you may offer because you have demonstrated to the customer that you are listening and that you understand.

Experts are the Best!

By now, I’m sure that you’ve all seen the comedy sketch called ‘The Expert‘. It shows an “expert” (our hero) sitting with “business people” (sales, marketing, project managers: aka – the ignorant villains). The expert tells the others how wrong their ideas are, but those non-experts just won’t accept facts, gosh darn it! And, as an engineer, I laughed along when watching it the first time, recognising the intended comedy derived from “experts are the best” trope.

However, when watching the video for a second time, it really started to grate with me. In fact, it seemed to me that the main villain is actually the ‘expert’.

(For this blog post, I am going to pretend that the ‘expert’ is an engineer. This is because I am an engineer, and I can confidently talk about how they should act. I cannot, for example, talk with credibility about how creative designers should act, because I’ve never been one. But the principles are presumably the same for experts in all fields.)

The Video

The video shows a customer who is asking for all kinds of mutually-exclusive and/or impossible objectives. The salesperson and project manager (PM) on the engineer’s side of the table are both clueless about the engineering fundamentals of the request. The salesperson seems to be a “yes man”, promising the customer that they can deliver exactly what has been asked for (thus “selling what he doesn’t have” – a fundamental error in sales). The PM seems to be cosy with the salesperson, and also keen to suck up to the customer.

Therefore, the engineer has no “allies” – not even on his own team. He stands alone against the forces of ignorance! (insert John Williams score here)

This is quite a common feeling amongst techies who are called upon to deliver products by a disconnected sales & marketing department. In fact, communication between silos (or even between people in the same silo) is certainly a huge problem within companies, failing to keep everyone aligned with the company’s strategy, etc.

This blog post, however, is not about intra-company communications.
This blog post is about the failings in the sales process shown in this video, because such failings are also seen daily in the field.

Nobody Looks for Problems

Fundamentally, no-one is doing any “needs identification” in this video. OK, maybe the salesperson has already had that conversation with the customer, but it’s not relayed to anyone in the room during this meeting. A vague buzzword-laden strategy is given at the beginning from the customer, and there are objectives on the whiteboard (invisible to us). The customer states what it is that they want, and the ‘expert’ engineer says why the customer cannot have it.

Nobody mentions “the problems”.

Being an engineer is all about solving problems. But at no point does the engineer try to figure out the problem that he’s supposed to solve. He simply takes the customer’s request at face value (7 red lines, all perpendicular, transparent, etc.) and tells the customer why it’s not possible. It’s true that the engineer does try to explain to some degree why more than 2 lines cannot be perpendicular (I won’t go down the 3D route here), but he’s not very good at the explanations (I think). The engineer patiently tries to show them all how silly they are with their crazy, impossible ideas.

What grated with me was why he was even bothering to attempt such an explanation.

Not Everyone is an Expert

It’s not that an engineer shouldn’t explain things. The issue is that explaining why something is not possible does not (in this case) move the meeting forwards. It’s just an engineer showing off a bit and acting superior. This is not problem-solving – it’s a lecture.

Furthermore, a real-life engineering problem would usually be a lot more complicated than simple geometry. Therefore, trying to explain why something very complicated is not possible (especially to non-engineers) is probably not going to help matters. In fact, all it does is bring negativity into the meeting, and possibly cause the customer to go on the defensive.

It is always worth keeping in mind that the customer is not an expert in your field. In fact, the customer knows that they are not an expert – that is why they are a potential customer after all – and very probably they do not want to be an expert.

People want Solutions

The engineer should be asking “what is the problem that you’re facing?” Once they have a problem to address, an engineer can offer practical (and, yes, physically-possible) solutions to that problem. This is how to achieve customer success – offering the customer a solution, and explaining how it will solve their problem.

The crux of the matter is that, while the customer is not an engineers, the customer does understand their own problem very well. Therefore, framing a solution in a way that explains how it helps to solve that problem will make the customer feel more engaged and, as a bonus, massively increase your credibility in their eyes. It shows then that you understand them.

In other words, explaining to a customer (i.e. a non-engineer) the details of how a solution works can be far less important than explaining the details of how a solution will help to solve their problem.

So the next time you are inwardly laughing at the silly people asking for “red lines drawn in transparent ink”, ask yourself this – why do they feel that that is what they need? The answer to that question will bring you towards the real problem that needs to be solved.

(Aside: It is very possible that a customer does not yet know their specific problem. This is why it is so important to ask questions – it will help to narrow down and figure out what the problem is and what the customer’s pain-points are. This will (a) force the customer to think about what their real problem is and (b) ensure that any solution addresses the actual problem, thus not wasting anyone’s time or money.)

(NOTE: Any genders used above are based on the people in the video. I am not suggesting that all engineers are male, etc.)

Advertisement

Why do we need APIs? (and a product roadmap)

Exec Summary: No company can cater to all customers. A roadmap allows customers to see if your product is right for them. An API allows customers to create their own, customised interface to your core product.

A while back, I wrote a blog post explaining what an API is. However, I never explained “why” APIs exist…at least not from a business perspective (I did explain that an API allows for customisation of the interface to a product).

However, there are more fundamental business reasons behind APIs.

Many small companies and startups produce a single software product. Even large companies have been known to spin-off a smaller company for single product development (outside of the silos) because of the flexibility inherent a smaller company.

A small company has its limitations, not least of which is manpower. All of the developers within a small software company will be working on the core product, whether that be bug-fixes, new features, or examples to showcase the product.

In order to sell the product, however, a company needs to cater to the needs of its customers. Customers always have their own specific wants (which will be presented as “needs”), their own preferred ways of doing things, and, most importantly, their own software dependencies. Startups, in particular, will bend over backwards in order to get customers at the start. The product features will be shaped by those early-adopter customers.

But kowtowing to customer demands is not scalable. No company, no matter how big, can afford to tailor their product towards one particular customer’s desires and technology (unless their business model is to only have one customer). Moreover, constantly tailoring a product to multiple customers’ desires is a recipe for disaster and burnout (and probably insolvency).

Thankfully, there are ways to address customer needs while still providing a best-in-class core product. Two of the most important weapons in an expanding software company’s arsenal are (1) a product roadmap and (2) an API.

Product Roadmap

What executives in business want more than anything is stability and certainty, especially when it comes to small companies or startups. They want to know that, if they invest in your product, that the product will still exist (with support) in a year’s time. Having a product roadmap will address these fears by showing that your company has planned for the future, and that the founders are concentrating on the product and not just an exit strategy.

More importantly, from a limited resources point of view, a product roadmap tells customers, “this is the direction that the product will take, and if you don’t like it, then you’re not our target customer”. Not only does the product roadmap filter out “bad” customers, saving the sales and marketing people time, but it also puts in stone the upcoming new features of the product. This in turn allows salespeople to point at the roadmap and say “that feature is due in August” or to say “that feature is not planned, but I will try to get it put on the roadmap”. If the feature is subsequently added to the roadmap, the customer will know for when it is planned, and can plan accordingly. If the feature is denied, then the customer may not be the target customer for that product.

While turning down a customer may be possible for more established businesses, it is particularly difficult for a startup (they need the cash-flow) and for a salesperson (they want the commission).

This is where the API comes in.

API

An API has been described (by me) as the strings by which a controller (the custom portal/interface) is attached to a marionette (the product). The controller can be customised for the user without affecting the underlying core product.

By providing an API, you are asking customers to develop their own interface to your product. In this way, the customers themselves can provide the tweaks necessary to fit their own needs, while still using the core product.

For example, a customer might want your product to pull elements from a database. If you build native database support into your product, you are now either limited to supporting one specific kind of database, or you are setting yourself up to develop and support multiple databases for multiple customers. This kind of support and development is not the core of your software product and, therefore, a waste of time.

If the API allows users to import and export files from your product, there is no need to build in native database support. Any customer can write some code that will pull an element from their own database and then import it into your product (or vice versa). This generic hook allows for the greatest flexibility when it comes to meeting customer requirements.

An API must, however, be well built. Terence Eden writes in his blog about the minimum requirements of an API in order to attract developers. Companies like APIphany can help with this. If your API is well built and easy to use, customers are not going to resist doing their own customisations (well, not as much) leaving you free to concentrate on development of the core product and features.

(update: 08/08/2012)

I forgot to mention IFTTT (IF This, Then That) which is a small “if” statement for webapps. You can trigger something in one webapp if something else happens in another webapp. It’s a great example of what one can do with APIs in terms of integration (or making two products play nicely together).

Conclusion:

So, remember:
Roadmap – reduces customer uncertainty, enables salespeople to sell the correct (core) product
API – enables customers to build their own customisations to meet their own needs, enables the integration of other products for easy partnerships that drive sales

User Experience as a USP

Exec Summary – User Experience (UX) is increasingly becoming the USP of similar products. Easy-to-use means lower costs and quicker efficiencies gained on the learning curve. This in turn can be used to show the bottom-line benefits of a product.

The learning curve is also a reason why User Experience (UX) is becoming such a hot issue at the moment. As our world and gadgets become more complex, there comes a point at which the law of diminishing returns kicks in and some things are simply not worth the effort. If, however, that effort is minimal, then the value offered by the product does not have to be as huge in order for people to buy it.

Obviously, this doesn’t change the basics of strategy/sales – you still have to offer a larger benefit than your competition. However, if the products offer a very similar outcome, the one that is easiest (or more intuitive) to use will usually win. This is more and more becoming something that customers value as a unique selling proposition (USP).

Consumer attention spans are waning. People want the outcome itself, not to spend time learning how to achieve that outcome.

For example, I was recently examining technical support ticket desk SaaS products. My needs were as follows:

1. access for external customers controlled via login
2. simple and automatic segregation of tickets based on a customer
3. reports to show time spent on a particular customer
4. submission of tickets by email
5. knowledge base (also access-controlled)

Some products were aimed at internal IT desks within a large corporation (and seemed very good at that job) and therefore I did not fit their customer profile. However, many (most?) other products were aimed at customers exactly like me. Of these, all of them addressed the points on my checklist above – but they did so in very different ways.

I’m not going to name any names, but, in my eyes, there were clear winners and losers.

One product in particular (let’s call it “Product A”) had a powerful and flexible product that met my needs. Unfortunately, all of that complexity was visible at once when using the product. There were so many menus and buttons shown that my poor 13″ laptop screen was overwhelmed – nearly half the screen was taken up by them, leaving me with little room for anything else (1024×768 people!).

The other products I saw (also complex and powerful) had far simpler interfaces, with the complexity…not hidden, but tucked away inside an intuitive menu system. The same functionality as in Product A was easy to find, but did not use up all of my screen’s real-estate. Furthermore, were I to place one of my non-technical salespeople in front of Product A, they would be just as overwhelmed as my screen by all of the options. Simply answering a ticket would be a struggle. Many would need to be answered before any efficiencies would kick in. For this reason alone, Product A did not make the cut.

Product B, the product that was eventually chosen, provides a far simpler experience to the end-user. My salesperson can log in, see what tickets are assigned to them, and answer those tickets via a simple interface. The complexity is hidden from the user and only accessible to an admin like myself – which is, I think, how it should be. The time that I invest in setting up the system is an up-front/one-off chunk of time. Once the system has been set up, it should then operate in that way for as long as is needed. The complex options do not need to be visible to everybody.

In summary, user experience and the learning curve are very closely linked these days. The internet has made it cheaper and easier for products to be launched, many of them attacking the same user segments. The key differentiator of these products is increasingly becoming how easy they are to learn/use. Easier to use means quicker efficiencies gained, which means lower training costs, which means it is easier to justify expenditure on that system with a cost-benefit analysis.

Update – 17 Sept 2012: This is a really good article along the same lines from Fast Company Design. It talks about how a good User Interface will play a huge part in any startup’s bid to be great.

The Learning Curve

Exec Summary – The learning curve is real. It maps how quickly task efficiency can be gained by repeating that task. This can be used to predict the cost of introducing a new task to a workforce for cost-benefit analysis.

Maybe it’s because I’m an engineer, maybe it’s because I’m just a little bit crazy, but I love assembling my own furniture! Ikea is like “big-boy Lego” to me. Opening the boxes, reading the instructions, putting the pieces together, swearing as I drop the side of a wardrobe on my foot, etc. – it’s all part of a process of creation. I feel a lot more attachment to furniture in which I have taken part in creating.

In fact, when I had moved home from Germany and was looking for a job, my parents’ new bed was delivered to the house. It was a complicated bed with remote controls for raising and lowering the head and legs. I opened the boxes and assembled the bed in about an hour. An hour after that again, the doorbell rang. It was the bed-assembly guy. I had to explain that I’d done his work for him.

Having just moved to a barely furnished flat in London, I’ve been assembling quite a bit of Ikea furniture this week. One of the pieces of furniture was a sideboard for the hall with four drawers. These drawers were the easiest to assemble while sitting down, so I started with them. The first drawer was a bit slow, because I had to decipher which screws, etc. to use. For the second drawer, I had the pieces of wood lined up in the correct places, and the bags of screws to hand. By the third drawer, I had all of the required screws out of the bag up front, and was motoring along quite happily.

“Learning Curve” is a phrase that we use in everyday language. If we say that something has a steep learning curve, we mean that it is difficult to learn, or takes time to learn. However, the learning curve is a concept used in management accounting and economics for describing the efficiencies gained by people who are doing the same task over and over again. The curve itself is a mathematical model that graphs some measure of productivity vs time (or the number of times the task has been performed).

What the learning curve boils down to is how quickly your efficiency in doing a task rises as you repeatedly do that task. On the job learning, so to speak. Simpler tasks, like building Ikea drawers, are a lot faster after only one or two iterations of the task. More complex tasks, such as partitioning a hard-drive in order to install a computer operating system, require more learning and, therefore, it will take longer to see the same efficiencies.

This relationship between productivity and time is the learning curve for that particular task.

But why is it interesting?

One reason that it is so useful in management accounting is that it can be used to predict the productivity of a workforce when a new task is introduced. This productivity information can, in turn, be used to see if profits will outweigh costs in the long run and, ultimately, if that new task is worth introducing in the first place.

In other words, it can be used to avoid costly mistakes – and if you’ve every worked in sales, you’ll know that the primary concern of most managers is to not be seen to make a mistake (especially a costly one).

The Middleman

Everyone knows that it costs money to tender a bid, due to wages, hardware, travel, etc. used when setting up the bid. This is just another example of “spending money to make money” in business today.

However, without rigidly defined needs from the outset, both the bidder and the customer are wasting money.

If the customer-company doesn’t know what the end-result should look like, the tender process will become a mess. The resulting contract (if one is even agreed) will not cover all the bases and the whole thing will become a project that is mired in “we need this/you never said that” blame games.

When starting a tender process for a single product, the needs from that product will usually be well-defined (or should be), and the tender can be put to manufacturers of those kinds of products (e.g., SaaS accounting software). This is something that we do every day when, for example, buying a new TV. We know that we want Freeview/Saorview and HD (and 3D) capabilities, thus allowing us to disregard the ones that do not meet those requirements.

However, when starting a tender process for a system, there is a very good chance that no one company does the whole system that will be required. This means that each bidder will be a partnership of smaller companies, each with their own product. In this case, it is possible that no bidding partnership will be a good match for the required project. Furthermore, if an agreement is reached, the needs post-tender may not match those that were originally stated during the bidding process, which will lead to professional services costs for the customer, and possibly a lower ROI for the bidder.

At some point, the ROI of a bid will no longer be worthwhile, leading to a reduced number of bidders in the process. The bidders who are left either (a) do not understand “bad business” or (b) are really expensive due to massive margins that can cover the costs of drawn out tenders. In case A, the risk is that the bidder will run out of money and the project will never be finished. In case B, the customer-company will end up paying far more than they should.

For that reason, when starting a tender process for a project, it is far better to approach a consultant or systems integrator. While these people may not be “product agnostic“, they will have a much better ability to adapt to changing requirements in any project, and will have been through the process a number of times before. Additionally, they will be adept at needs identification, leading to a “best possible” solution for the customer.

For example, if the accounting software portion of the system was suddenly required to be an on-site solution rather than a SaaS solution, the consultant can very easily eschew one vendor in favour of another. The costs incurred by the customer-company of such a change will be the hourly rate of the consultant, while the costs incurred by the vendor will be the opportunity cost of not having an on-site solution and the cost of the salesperson finding out that a customer was no longer one of their target customers.

So, while it is possible to “skip the middleman” in business, in some cases the middleman adds a whole heap of value. In fact, the middleman can be the difference between a project that comes to a successful conclusion, and one that never comes to any conclusion, staying mired in red-tape, professional services, and good ol’ fashioned feature creep.

TLDR; Know what you need or know who to ask about what you need.

Give a man a fish…

Give a man a fish, and he’ll eat for a day.
Teach a man to fish, and he’ll eat for his whole life.
If that man innovates fishing methods, he’ll catch more fish than he needs, thus being able to sell the surplus fish, the technology, or both.
In other words, innovation will give the man disposable income.

I attended the Dublin Investment Summit on Friday 30th September 2011. CEOs, entrepreneurs, authors and investors were present to discuss business topics relevant to today’s economy. There were also pitches from companies that were looking for investment (including some very exciting nanotechnology from Vasorum and Alta Science).

The overriding message from both the summit and from my recently completed MBA is that innovation is king in today’s world. Hypercompetition is where companies and firms try to both increase their own competitive advantage and erode the competition’s advantage. This erosion is only avoidable through either patents or constant innovation in the marketplace. This continuing innovation keeps changing the goalposts so that the competition cannot keep up.

Patents give legal protection in their jurisdictions, but cannot offer protection against underlying ideas. In fact, one company present at the Dublin Investment Summit (SolarPrint) has not patented its technology, claiming that the ideas are too valuable to be released into the public domain. A founder, Dr. Mazhar Bari, explained that keeping the technology secret would hinder the competition more than having a patent.

This could become a growing trend in the marketplace, as companies (especially startups) work to retain their competitive advantage. However, I do not think that it is a sustainable model. Loose lips or a defection from within that company could lead to the underlying idea leaking to the public domain. Keeping something secret is a very shaky premise for a business model. Furthermore, the technology could be impinging on another patent. This is what patent examiners and search firms do: they find out if an idea is either patentable or infringing.

Enter constant innovation!

At the summit, there was a copy of Innovation Demystified by Richard Lawler to be given away. This book is a compilation of simple techniques designed to unlock one’s creativity. I have not yet read this book, but a glance through it spoke to me on a creative level. It’s the whole “walk away from the crossword for a while, and the answers become obvious” idea.

Personally, I use juggling, painting and lock picking as ways to take my mind off issues at hand. However, I think that I will purchase this book for it’s desk-ercises as well its simple mind distraction techniques.

But it does show that everyone can be creative if they put some time into it. This innovation is key in today’s business marketplace, and having some staff doing full-time innovation work on products, marketing, strategy and even the company’s business plan is essential.

In times of hypercompetition, innovation is the means to survival.