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.)

Advertisements

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

Exec SummaryUser 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.

Exec SummaryThe 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).

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.

In my current job, I’ve had a lot to do with our product’s Application Programming Interface (API) – namely documenting it. For those of us who live in the technical world, we’ve dealt with APIs for many years and take them for granted. However, for those who live outside the technical world, an API is just another techie-TLA. The documentation with any API tells us how to use it, but not fundamentally what it is.

So here is my attempt at a simplified, non-technical analogy of an API.

Imagine, if you will, a puppet. We want to make the puppet dance. To do this, we grab the puppet by the arms, lift it, and make it perform a dance. This is akin to controlling a product (the puppet) through its native User Interface (its limbs). In other words, it is controlling the puppet using the bits that the puppet-maker made.

However, there comes a day when we want to control the puppet using two wooden sticks in the shape of an X.

Titiritero

Why would we want to do this? Well, for a start, it gives us a lot more control over our interface to the puppet. Because we have direct control over the sticks, we can customise them to fit our hands perfectly. We can paint the sticks any colour we want without affecting the puppet in any way. We could, if we wished, connect the same part of the stick to both the right arm and the right leg, meaning that these limbs would both move in unison with only one twitch of our hand.

This allows full control over the look and feel of the controlling interface.

With this in mind, we design our two sticks in the way that makes them a perfect fit for our hands. This leaves us with a puppet, and a controlling interface. All we have to do now, is hook them up.

With what does one connect a puppet to a stick? String, of course.

These strings allow for the movements made with the wooden X to directly control the movements of the puppet. And, as mentioned above, those movements can be customised, depending on where and how one ties the strings.

So a standard product (the puppet) is being controlled (via string) from a customised interface (the two sticks).

In this case:
– the puppet is the underlying product/program.
– the sticks represent the interface – designed, built and customised by you, the user.
– the strings are the API – they are what connect the controlling interface to the underlying product.

The end of a string is a somewhat generic connector. In other words, strings can be connected to almost anything. They could be tied directly to your fingers, meaning you’re the only one who can control the puppet; they could be tied to some kind of robot, which could make the puppet dance automatically; they could be tied to the two sticks, and those sticks can be given to anyone (or anything), allowing control of the puppet by whomever has the sticks.

IMG_0254.JPG

This is the same for an API. The API allows a custom interface to control a product using a generic/standardised method. This allows for the control of a product from a custom-branded portal/interface. The interface designed by you can be an intuitive interface for your customers’ needs, saving you the cost of developing the underlying product.

It opens up a whole new layer for user experience design – one that does not need to involve creating an actual product. If the product is good, and can be controlled via an API, then there’s nothing to stop you adding value through a more intuitive interface. This allows the product’s developers to concentrate on the core product, while you can create the interface. And, as Apple has shown, a good interface can go a long way.

Moreover, it opens up an easy route for partnerships between technical companies. A customer might want a whole solution, but the best companies might be the best because they have concentrated on one specific area (“core competencies”” and all that). Using APIs, an interface can be developed that will use the best products out there, and seamlessly integrate them via their associated APIs. This is a win-win situation – the customer gets the best products, and the companies get sales.

So, hopefully, this will demystify APIs somewhat for those from a non-technical background. They are simply a means to attach one’s own controlling interface to a product, allowing for custom designs and/or automation.

All that you need to worry about now is checking that the underlying puppet isn’t Pinocchio, about to develop a mind of its own and not obey the strings.

This article from the Irish Times mentions how engineers missed the “marketing boat”.

I firmly believe that this is true. Having completed a Smurfit MBA in order to get away from being “just an engineer”, I found that my transferrable skills were virtually unknown in the working world. Those engineers on my MBA course who wanted to stay in the engineering arena found jobs fairly quickly. However, those that wanted to get away from the “pure” engineering field were destined for a longer job search.

People talk about arts and commerce as “good, general degrees” (which they are), but that is rarely said about engineering. However, the critical thinking and problem-solving skills developed with engineering are applicable anywhere. Moreover, the ability to understand other people’s complex ideas that any engineer must have in order to get the degree is directly relevant to needs-identification in sales and marketing.

Furthermore, while not considered a “creative” discipline, engineering requires more creativity than people generally realise. The ability to break down a problem and then figure out a way to solve that problem is well understood, and the phrase “problem solver” is on everyone’s CV these days. But there is a difference between someone who solves a problem by going through a prescribed approach, and someone who solves a problem in a “creative” manner.

What separates a “creative” problem solver from a “by-rote” problem solver is a deep understanding of the underlying system (usually a very complex system). This understanding is a central point in coming up with novel (“new to world”) or creative solutions that have never been used before. Engineers spend a lot of time examining systems, so the interaction between elements is something that we don’t take for granted.

An example:
Coming from an electronic engineering background, one system that I would be used to are circuits. At the digital level, every element does a specific job, has at least one input (1 or 0) coming from another element, at least one output that goes to another element…and the whole thing creates a system. At a digital level, things can have quite simple causal relationships. But beyond that, an electronic engineer must take into account the real world. Signals that are analogue are not simply 1 or 0. Current flows around a circuit board following certain paths, which can interfere with the inputs and outputs of other elements if care is not taken.

At a Toastmasters meeting yesterday, one of the topics presented was, “Does the pressure on companies to reduce price also reduce quality?”. The answers given were all given by those who thought “Yes – a price decrease must equal a quality decrease”. We’ve all seen the “Project Triangle” at some point. This clearly shows us that it is possible to produce something a low cost and of good quality if we sacrifice time. The time element can, however, be minimised by having good problem-solvers involved, allowing for good, low-cost solutions with a low time-to-market (or at least lower than that of the competition).

In conclusion, the M.O. of an engineer’s brain can be useful in so many non-engineering arenas: CRM – a network of customers is a system; Sales – understanding of customer needs boosts credibility; Strategy – the market is also a system, with cause and effect; Marketing – a campaign is a series of linked occurrences, like a system; Project Management – a project is a system; etc.

Please remember that just because we’re engineers does not make us emotionally unintelligent Dilberts. Additionally, anyone with an MBA has fundamental business/economic/strategy understanding.

And, as I’ve mentioned above, the fundamentals are what really count.

Edit (14th March 2012): This article from the Globe and Mail tells of how engineers have overtaken MBAs in leadership positions. So just imagine what an engineer with an MBA can do. (thanks to Fergus for the link)