Interesting points, but it reads like a parable, rather than something that actually happened.
This is something that irritates me about business writing. Parable != evidence, since I construct a parable after the fact, to make a specific point.
Also, like witty aphorisms, it's just as easy to support either side of an argument. E.g. "the early bird gets the worm" v.s "the second mouse gets the cheese".
I've been in that exact position - we kept hiring high powered sales guys and expected them to sell a product that was close, but not close enough, to what customers actually wanted.
It's the classic mistake of confusing sales (selling an existing product) and marketing (finding out what people really want).
That's a great point. There is a third branch in the trifecta, which is advertising/PR to tell people about what you have.
Be wary of someone great at advertising/PR but not at market fit. Those are two distinct questions. Often the founder needs to "own" market fit, probably with the help of others, and advertising/PR can be somewhat delegated. However since market fit drives every decision, it can be hard for that person to be anyone else but the founder.
Absolutely: the plural of anecdote is not data. But Steve is not marshaling evidence for a proposition here, he's teaching a concept by telling a story to bring the concept alive. That's quite a different thing, and exactly what parables are for.
The problem is that a parable isn't even an anecdote. One of the other posters on here, saying "this happened to me" is an anecdote, and I found that useful.
parable <- propaganda
anecdote <- something that happened, but generalize at your own risk.
data <- often useful, but subject to horrible flaws in interpretation
"The word "parable" comes from the Greek "παραβολή" (parabolē), the name given by Greek rhetoricians to any fictive illustration in the form of a brief narrative. Later it came to mean a fictitious narrative, generally referring to something that might naturally occur, by which spiritual and moral matters might be conveyed.[3]"
On the other hand, while the story sounds like a parable, I didn't notice anything in the text that actually implies that it is fictional. In any case, it was highly effective for Steve to get his point across to me. Whether the point is true is another question which I can't answer from experience.
Is the overall argument about is you shot with your blind eyes and miss the target, then you move the target and say you hit it, so you are a great master and never miss a shot.
"the early bird gets the worm" v.s "the second mouse gets the cheese". But I think that for the second to be true there must be some trap for the mouse. If you foresee the traps of the future then you can take the cheese.
Excellent article. This was something we learned at our last company, especially early on. Sales people that had previously excelled at large tech companies with a full suite of presentation, training, marketing, and support materials, with a mature and relatively stable product, did not do well in a fast moving environment that required more thought and digging into detail. In the end, our consulting organization (which was much more familiar with our product and customer requirements) ended up being our best pool of sales talent. I'd suggest considering technical consulting types who are working on actual implementations for sales roles.
I think it's less "job titles that", and more "job titles can". The hiring model for employees in the tech industry has shifted from "I'm hiring a (insert position here)" to "I'm hiring someone who can (skills x, y, and z)". Old industry HR practice is to look for a title, but new industry needs to focus on skillsets. Especially in the fluid world of startups, flexibility is core.
Actually he says that the specific conditions did not come up in the interview. They used the terms customer validation and pivot, but did not specifically say "we don't have a well-understood group of customers" or "we don't have a scalable and repeatable business model."
Steve Blank is a writer and knows that wrapping his point in a story makes it more enticing to read. And I agree that this post has less to do with job titles, than hiring people who have the right kind of experience.
Having worked in big companies, (Gap, Wells Fargo, Guess) I know that they all have their time tested processes and you walk in and there are step by step instructions on how to do your job (any job, all the way up). Even at IDEO there's a tried and true methodology, design thinking. You dont know what you will come up with, but you know each step to take.
Startups change day to day, which makes them exciting. But hiring a seasoned big company employee is suicidal if they come in trying to execute a time tested routine.
It's not about titles per se, but about hiring someone with the right mentality.
Steve Blanks' "Building A Business Model" is the idea that you iteratively develop your startup based on what you discover about your customer's needs. Ie. your first attempt at a project is almost never what your potential customers will actually end up paying for.
He espouses that you should build a minimal product based on your idea. Then iterate over the following points seeking traction and revenue
1) "Get out of the building" and go talk to a lot of your potential customers
2) Based on what you learn from those people: Reevaluate your idea and decide if you should iterate more, or start a new direction
3) Develop #2
4) goto #1
Think of it as the scientific hypothesis/experiment cycle for startups
[edited to add the below]
As usual, Steve says it more succinctly and powerfully than I. I guess that's one reason why he gets to teach at Stanford :)
Here's how he puts it [1]
Your startup is essentially an organization built to
search for a repeatable and scalable business model. As
a founder you start out with:
1) a vision of a product with a set of features,
2) a series of hypotheses about all the pieces of the
business model: Who are the customers/users? What’s
the distribution channel. How do we price and position
the product? How do we create end user demand? Who are
our partners? Where/how do we build the product? How
do we finance the company, etc.
Your job as a founder is to quickly validate whether the
model is correct by seeing if customers behave as your
model predicts. Most of the time the darn customers
don’t behave as you predicted.
...
How do you know your business model is the right one?
When revenue, users, traffic, etc., start increasing in a
repeatable way
"He espouses that you should build a minimal product based on your idea. Then iterate over the following points seeking traction and revenue."
No, he doesn't. He really really doesn't. In fact, that's the exact opposite of what he advocates and what his customer development methodology attacks - the old school product development approach of building the product first and then collecting feedback to refine it, figuring out how to market it, finding out who the target customer is, etc.
Developing your customer base (rather than developing your product) means that you talk to customers and learn their existing pain points before you design or build a single thing. His Four Steps To The Epiphany MBA textbook calls it Customer Discovery, or step one. Everything in the #1-4 loop you described is step two - Customer Validation - where you then try to validate your hypothesis about the customer pain points with your product ideas and/or prototypes.
I'm ripping off this giant rant because for some reason, I see this on HN a lot. A lot. It's really common for people to conflate MVP with customer development and to also reverse the order that you do it. I think you see this on HN in particular because it's filled with coders that prototype in code the way designers prototype on paper, so they think "hmm, how hard could it be for me to throw something together in a week or two and see if anyone will buy it?" instead of "how hard could it be for me to go talk to people and see if there's a potential customer base for this idea I have?" It's not just that the second path is easier, it means that the product you build afterwards is way better informed. On the other hand, MVP seems to appeal to HNers because it's like the Nike message of startups - Just Do It. Just go ahead and build something already because all you need to do afterwards is refinement. A little bit of a/b testing magic on landing pages here, a bit of keyword research on Adwords there and then bam, your app is paying the rent while you drink margaritas on the beach.
Off the top of my head, one of the more recent examples I can think of was just this last month when Zach Burt (zackattack) unveiled Awesomeness Reminders and someone asked him about all the stuff he's built this year, so he wrote about his personal process for throwing tons of little MVP apps against the wall and then why he'd ditch each one before moving on to the next:
Not to pick on the guy, but this was a particularly egregious example. Explaining why he abandoned one of his apps (CustomerFind), he wrote:
"I did do some Customer Development meetings related to CustomerFind, and pivots suggested room for a potential enterprise-y Social Media dashboard product."
No, you didn't! You didn't do Customer Development - you did Customer Validation, where you did a little bit of research after you built the product to see if the product you already built solved the problems that you just plain guessed your customers had. In other words, you tried to skip a step and validate your product against customer base that you didn't create in advance and then surprise! There wasn't a fit and the app wasn't monetizable. An interest list based on email signups is not the same as purchase orders. Rinse and repeat for 4 or 5 apps and there went his 2010 so far.
So when do you do MVP and when do you do Customer Development?
Easy - it depends on whether you're building something where you're also the target audience, scratching your own itch, eating your own dogfood, Tim O'Reilly's "fishing with strawberries", etc, or if you're building something for other people.
Both approaches are still just different versions of PG's "make stuff people want" but you need some kind of internal compass to guide the way. If you know the phone in your pocket sucks and you can build a better experience, then Apple can go make something that's clearly better without having to do a lot of market research. So they do. And if you think you'd like to get a call every once in a while and hear a real human being tell you that you're awesome, then there you go. But if you're building something for other people to use that have problems that you don't experience on a daily basis, like say, an app for bloggers that get a good amount of traffic and are looking to get into direct sales rather than relying solely on Adsense's anemic payouts, then you better do your homework and get on the phone.
using the information for feedback and iterating to improve your business model is not enough. When you are learning cycling you iterate and use the feedback but you fail, then you get some sense of equilibrium and maturity, but these are human capabilities that are not so common in business, perhaps a missing capability is needed to succeed in business.
The idea is, that it's highly unlikely your initial business model will be successful and generate big revenue. Instead, you iterate and analyze customers/market in order to pivot and refine your business model until it's optimal. Sometimes that can mean a radical change, sometimes just a realignment.
The initial idea rarely becomes the sustaining business for successful startups. The reason for this, is that your idea is a "wild ass guess" until you talk to real potential customers, to see if you're actually solving a problem they need solved.
The idea for a startup is usually just a hypothesis. Once you go out and talk to real customers about what you're offering you'll gain some insight and new information. Most of the time, your original hypothesis is off the mark. Your idea may be slightly off, or completely wrong together, but armed with your new knowledge you can alter your hypothesis.
Repeat the process and eventually your evolving hypothesis will become more refined until you have a scalable and repeatable business model. This is the "search" that he's referring to.
Of course you always start with a business model! But then you find out that it doesn't work (customers don't need your product, or are not wiling to pay for it, or you simply can't make money). So you have to switch business models and try something else. You cannot know everything before you start.
Some companies do, others don't. Often what you think would be your business model turns out to be totally wrong and you need to change it. Even if you have a business model you should still be looking for others until you know the first one works.
A great addition to this post is the "Sales Learning Curve" paper written by Mark Leslie. What's great about the SLC is Mark gives some actual data and a framework for how to think about who/when to hire sales people. http://altgate.com/blog/2007/07/sales-learning-curve.html I recommend it to every entrepreneur.
All the great salespeople I have known were nervous control freaks hiding inside a breezy exterior. The great ones are like painters who would never let you touch their canvas. Of course they will freak if you keep changing the product. Stability is a primal urge (for customers, not HN readers) and sales people know that.
The solution: Hire crappy salesmen who will call anyone you want? Not exactly.
Find the smartest customers you can and practically pay them to work with you. After all in the scenario outlined, you don't even have a product they want. The salesperson needs to "get" that they are selling the team not the product.
Good post thanks. Besides optimists and pragmatists, boards also need skeptics to remind everyone of where the company really is before it gets ahead of itself.
The main underlying cause of the problem here is always (in my opinion) the fact that boards and founders tend to build companies only by looking forward at what they hope the company will be in X quarters. In this example: I suspect they are really excited at having the big shot VP of Sales because usually, where there is one, there is revenue. But they don't seem to face the truth of where they really are at this stage: a company still struggling to find its model.
The thing about titles, is that sometimes even though they don't reflect what you really do on a day to day basis, they do help with career management - i.e. finding the next job if the current one goes bust. So sometimes its ok to give someone a high-falutin' title as long as they understand up front that they have to earn it.
And the thing about salesmen is that in the interview they're selling themselves. Of course he said what Rajiv wanted to hear! That's what he does for a living!
This is why you can't tell an interviewee what you want in an employee. You need to hold your cards close to your chest and get THEM to tell you what they deliver.
If it doesn't fit then you need to consider finding someone else.
The worst thing you can do is bring in someone for an interview, tell them what you want to hear, and then allow them to echo back to you what you want to hear. Which is what most humans will do.
> "This is why you can't tell an interviewee what you want in an employee"
I disagree. If a company cannot clearly state what is expected of an employee then how can it expect to attract/retain great people? The interviewee should also be assessing their potential employer so being reluctant to share relevant information probably wouldn't come across well (at least not to me).
Interviewing is a skill and a good interviewer needs to be able to inform applicants about the job requirements while also probing to ensure that the candidate actually does possess the necessary skills. It is not easy.
Easy. In the interview you present the candidate with scenarios and let them run with them. In an interview you are rarely looking for specific facts; rather you want to discern the candidates thought process.
> "Of course he said what Rajiv wanted to hear! That's what he does for a living!"
In my mind, that marks out a bad salesman. Telling people what they want to hear is not sales. At best, it's inept and at worst it's deceiving. Simply put, you shouldn't sell something you don't have.[1]
[1] If sales people are 'selling' before a product is finished then it should be clear that it's the vision they're pedalling, not the product.
I'll give anyone working with me any title they want, including CEO, just as long as they do everything within their power -- and stretch out of their zone -- to accomplish work and move the company forward.
I think any titles period will hurt your startup. Who has the biggest dick? Who fucking cares? I can't stand titles... whoop-dee-doo you're an art director.
This is something that irritates me about business writing. Parable != evidence, since I construct a parable after the fact, to make a specific point.
Also, like witty aphorisms, it's just as easy to support either side of an argument. E.g. "the early bird gets the worm" v.s "the second mouse gets the cheese".