Skip to content

Posts tagged ‘Sourcing Basics’


It Takes a Village to Raise a Factory

These days there is a great deal of debate raging around the topic of manufacturing, with many former and aspiring manufacturing centers looking to attract factory investment from the worlds multinational corporations.

At this very moment I am in a hotel in Bangkok, which is seemingly the only place in town where one can escape the barrage of stakeholders extolling the advantages of opening a factory in Thailand. Their reasoning is not unfounded, and it does not take much looking around to see the fertile ground where upon the next global manufacturing powerhouse may arise.

Read more »


Who wants to be a sales guy?

This morning I attended a meeting of our local “lean startups” group here in San Diego.  The lean startups movement, as put forth by Steve Blank and Eric Ries, is the study of customer development as a method for bootstapping the early stages of startup growth, and is one of those things that you wish you had heard about before you joined your first startup. There is a local group of lean startup executives here in San Diego, and periodically, thanks to the efforts of a few of our members, we sit down to breakfast together to talk about all things startup.

During the meeting, one of my colleagues was speaking about his company, and in the course of describing his technology made the comment “I don’t want to get too sales-y;  I mean, who wants to be a sales guy?” (cue nods of sales-guy disdain from folks around the table)

A few other people interjected, talking about his technology, and asking about his early successes.  When it finally came time for me to speak up, I immediately countered his earlier statement.  Having spent nearly half of my career in startups, I have heard similar statements from nearly every founder.  This is to be expected, given the nature of startups.  Startups, in my experience, are founded by a person or group of people that are driven by a passion for the solution or the product that they have created.  The question that needs to be answered, however, is do you have a solution that addresses a customer’s pain well enough for them to make a purchase?

Too often passionate people find themselves building or creating technology for the sake of the technology. While creating for the sake of creation is important, at a certain point it needs to change.  Startups that survive share similar DNA in this regard.  While almost all companies start singularly focused on technology, early successes drive the need to continue selling their product to more and more customers.  I read a recent article by Carl Eibl at Enterprise Partners, where he discussed that nearly all startups that get funded share one major trait in common: they not only have customers, they know exactly why those customers made a purchase.  This is the core premise of the lean startup methodology, which put simply, states that startups should sell their product, find out why early customers purchased, and then capitalize on that pain point to sell to more and more customers.  I encourage everyone to read Steve’s book “Four Steps to the Epiphany” to learn more.

Back to my point about not wanting to be a Sales guy.  Almost every engineer I have ever met has one image in their mind when they think “Sales Guy” and it’s this guy right here:

This is a really unfortunate situation, as this is not what I mean when I counter that

you do, in fact, want to be a sales guy.

Being a “sales guy” doesn’t mean some high-pressure, used-car, software-pushing salesperson who looks at clients and sees dollar signs. Being a sales guy means being able to speak to executives about the solution that your company has to offer.  Being a sales guy means speaking to a different crowd, and as a result, using a different vocabulary.  At the end of the day, the sales guys and the engineers are all striving towards the same goal: to solve problems through the use of technology.

The main problem, when you talk tech, is that you are generally speaking to the people who will be implementing your solution, the IT manager and that general area of the company.  their concerns are “does it authenticate against our AD server” or “can it render our existing embedded files”. As an engineer, you can speak to this goup, and it is probably the group of people that you are most comfortable working with.  The problem is, for the most part, your average IT person is not the one that signs the check. At most they tend to be the “technical buyer” to use the Miller-Heiman description.  They can recommend a solution, but they can’t write a Purchase Order and send it over to you without approval.

If, instead of talking tech, you spoke about your solution in terms of the business problem that you solve, now you can speak with executives using their language.  Executives don’t care about how efficient your SQL queries are compared to the competition.  Executives care about solving business issues.  You need to be able to frame your conversation in terms that they are familiar with.  If you could, instead, meet with a manager or executive and say “You are spending an average of 10 minutes with each customer in your call center; with our new Phantasmotron 2000 software, you can cut this time down to six minutes.  Imagine the savings across all of your call centers that you will realize right now by deploying our solution!”, Now you are speaking in executive language.  Extra points if you say “decreasing your variable overhead costs by 40 percent will save you millions in the first year alone”!

Of course the manager is going to ask his IT manager if your solution will work with their existing data center structure, and now, by all means, feel free to geek out with the IT guys and sell them on the solution as well or maybe you sold them ahead of time or delegated the technical details to your Sales Engineer.  Regardless, in this scenario, you have tackled the hard part first, selling the buyer on the business case for purchasing your solution.

It is important to note, that although you first spoke to an executive and then he brought his IT manager into the conversation, it is much, much harder to push things along in the other direction.  I have seen salespeople drive themselves to the brink of madness by speaking with IT managers and then trying to get them to push the decision up the chain of command.

I am a big believer in investing in personal self improvement (for example…the total cost of my education, up until this point, exceeds the cost of every home I have ever owned), and while many startup founders have brought in salespeople early in the life of the company, I do not think that this is the best path.  As founder or even an engineer, you need to understand why you are building the solutions that you are building.  If the time comes to think about bringing in financing, VCs will want to see that you are one of the best salespeople in the company.

There are a lot of sales books and sales methodologies, and all have their perks;  However, the best education that you can receive in from information that is available right in front of you:  find out why customers purchased your product. Not just who (it’s an CIO) or where they are using it (accounting uses our software to manage payroll) but rather seek to understand WHY EXACTLY, did they spend money on your product.  You want an answer that you can re-use a part of your sales process.  Ideally, you will hear that they had a problem that they knew was costing them money (e.g. – the call center example above) and they tried other solutions, and none worked until they tried yours.  Look for pain points, understand how your solution eases the pain, and now you are armed with a fantastic business case to present to the next client.

Who wants to be a sales guy? You do.


Idea vs Strategy

I had a conversation recently that I have had a number of times before, and so I wanted to discuss it here: there is a great divide between having a great idea and having a successful product. As Apple, Microsoft, and many others have proved, success is often less about what you have and more about how you sell it. DOS, windows and the iPod all share the common trait that they were not the first to market in their respective categories; they were however executed better than all of their predecessors.

The most common trap that I have seen in the marketplace has been companies that create “solutions looking for a problem” or simply technology for technology’s sake. If you have not identified the target market for your product during the development, you will be facing an uphill battle once that product is ready. A good way to increase your chances for success is to identify a group of potential users whose needs have not been addressed with current solutions. Real solutions address a legitimate need, in a way that is simpler or better than what is currently on the market. This brings us to our most important point; the key to successful innovation and product development is a resonating focus on the needs of the customer. It is not enough to add value; you have to add value to the customer. Ask them questions. Listen to them. And most important of all, allow them to drive your innovations.

The Project Pre-Mortem

Last year, The Harvard Business Review featured an article which discussed the technique of performing a “pre-mortem” on your project. I won’t spoil what is quite a good read (click here for full text, registration required), but the basic premise is, to test your project’s likelihood of success, turn the tables; pretend for a moment that the project has already failed. Get the team into a room and discuss the hows and whys of the failure. Identify key things that might have been missed, or steps which could have been taken to reduce the probability of failure. The article brings a number of issues to the forefront, the first is, most projects fail; the second is, most team members probably saw it coming, even if you didn’t. The pre-mortem is a great way to free unpleasant from the shackles of organizational hierarchy that would otherwise prevent feedback from reaching the people who need to hear it. At the very least, it can help you reduce your losses by cutting off projects desitined to fail, and at best, hopefully, it will help to design projects which have a higher probability of success.