(I loved phrasing this as "You could certainly have your engineering team do this, if you want to write a $10,000 payroll check with the memo 'Reading free information on the Internet'.")
This is probably one of the best arguments for niche specialization that you'll find. Say you're a Ruby developer, but you know a lot about CPA, ARPU, LTV, churn, and other terms SaaS types care a lot about.
Yes, you might cost significantly more per week than a peer Ruby developer who might be employed by a prospective client of yours, but the cost of getting that employee's knowledge to around where yours is outweighs the difference.
Additionally, clients want to lower the risk that a project will fail (note: this doesn't mean technically fail, as in the code doesn't work.) By "leveling up" in a niche specialty, you'll lower the risk that you'll fail when a project in that niche comes your way. (Clients also have a tendency to reach deeper into their pockets when the risk of failure is lower.)
Clients also have a tendency to reach deeper into their pockets when the risk of failure is lower
Yep. Basically, it's an expected value calculation: your project actually costs the sticker price divided by chance of success. (If you quote $20k and the customer's experience is that 20% of projects fail the "true cost" is $25k after they self-insure for risk of project failure.)
Decreasing their estimate of project risk thus lets you justify higher rates. Also, as your client has lower perception of project risk and execution risk, their perception of the probable magnitude of the success for your engagement will likely increase. (The logic of that goes something like "He's clearly a pro at this, as demonstrated by his execution ability, therefore if this were not likely to be a major win he'd already know that and we wouldn't be having this conversation.")
Beware that some companies calculate the cost of existing employees at zero. If someone else is paying the employee, but you come out of their budget. Find out how the money flows.
Then you are talking to someone too low down the tree.
The person who signs the cheques as big as you want them to be will be the person with P&L for employees and contractors
Possibly across IT and marketing or accounts or ...
It can be a little bit outdated but the main points remain the same.
I experienced it first hand: We realized that the "energy" to spend in selling USD 100K/yr on a specific product is one or two orders of magnitude of selling a service using/embedding that product. And there are cases where there is a dilemma and products can eat your service profits.
Thanks for that recommendation. I'm going to sit down with that paper and have time to digest it in detail, since it seems like likely the most relevant-to-my-interests link I've seen on HN this month.
Wow. The writing here is concise, and easy to understand. Just a few paragraphs in I realized I've been doing my consulting wrong (which makes the hopeful transition to a products & services company even more challenging).
In terms of benefit-per-sentence, this is right up there with the best books on business I've ever read.
Thanks, that is one of the best compliments I've ever gotten for my writing. (Since I tend to write 4,000 words at a time, my biggest worry is always that I'm fluffing up one good idea into excessive length. I aspire to always covering something in enough meaty depth to justify the length, not to have the length pre-fixed and need to pad to hit my quota.)
The impact of the writing -- the frequency with which I read something and it made me sit back and go, "hmm" -- is comparable to Rules for Revolutionaries, still my favorite book on business.
I don't give out enthusiastic compliments easily.
Seriously, if you enjoy doing this, you might consider turning it into a book. With your writing style, your domain expertise, and your marketing acumen, you'd probably make a mint.
I would not worry too much on that score - I managed to read your blog post and have three chunks mailed off to people with "OMG this bit .." and, oh yes, decided I need to be building products first in order to sell around them.
You have an exciting idea per paragraph ratio higher than anything since pg in the early days - you are hirin your stride about now
(Ok that does sound a bit brown tongue - but it's honest so apologies all round)
Excellent article. I've worked in product companies ranging from startups to the top 5 over the years, and also spent a few years in consulting organizations so I can really appreciate the insights here. Product companies (in general) create cost centres while consulting companies are profit centers. So the attitude toward cash flow is quite different. Consulting companies tend to "invest" their money while product companies tend to "spend". What else, product people tend to take their time to build things that they feel the customers will need, instead of building exactly what the customers need. Sense of urgency is a trait that a product company can learn from the consulting business. Consultants work with customers directly and they always possess domain knowledge learnt from experience while product people rely on research to pick up a subset of the knowledge. Imagine the power of a large product organization that can run more like a consulting organization!
I wish I had something more to say, but this is phenomenally good. It may be the most genuinely informative and well-written piece I've seen on HN in months, for the startup crowd.
I'm amazed at the number of product companies that don't do this. Or stop doing it as soon as they think they've found product/market fit.
If I had to pick between A/B testing and talking to my customers (and it would, of course, be dumb to pick only one of those options) I'd pick talking to my customers without hesitation.
A/B testing let's me optimise. Talking let's me discover my customers' problems.
On the other hand, I am incredibly annoyed when hosting companies give me personal phone calls to ask how I'm doing or tell me about their new service. There's probably a middleground but I just don't really like talking to salespeople.
Agreed. Rarely has someone called me who really really wanted to know my experience with something, and nothing more. I think I've had one call like that in the last year, and even it was sort of a... well, not salesy. I'd signed up for an Azure test drive. 1 month in someone called to ask what I was doing with it. Based on what I said, they assigned a support person to me, sent me that person's info, and said to contact them if I had any support/tech questions. No sales pitch, no upsell.
Pretty much every other thing I sign up for, if someone calls, it's inevitably a salesperson who does not understand the tech behind the tech they're selling, trying to push the latest version of something they don't know.
Please - call me and ask me if I'm using it. If say 'no' - as in, 'no, I don't use subversion, and I've not worked in an enterprise situation for 9 years' - that should be enough to take me off your list. If I say yes, and have feedback, take it, listen, record it, say 'thanks', and get it to the right people. If I'm using something, and it sucks, and I tell you it sucks, a followup from someone telling me you'll make it better would net a customer for life. No one has yet done that for me.
Wait - I did have a service company in town that was in startup mode take their site down, then proceed to call a few of the really early adopters (me included), do moderately long interviews by phone, and then tell us they're pivoting the company based on our feedback. Time will tell if that works out for them, but it was unexpected.
tldr = if you're calling for feedback, call for feedback, take it, and act on it. do not try to sell me something at the same time.
Remember - talking to your customers != cold phone calls.
* You can arrange a phone call. Email 'em first, or use a tool like ethn.io, or just hack something into the workflow of your site that lets people opt-in to a call right then.
* You can give options for customers to call you outside of support calls. Set up some office hours on ohours or whatever. Get your customer to call you.
* Find a local customer. Go out for coffee. Buy them dinner.
* Whenever you go somewhere not-local - see if you have a customer there. Go out for coffee. Buy them dinner.
* If you find there are non-local locations that have groupings of many of your customers - find an excuse to go visit that location.
Loved the post. I just signed up for the newsletter so that I'll get more of these pushed to my inbox in the future.
Patrick: do you think it's a good idea to add a date of publication to your articles? Most people wouldn't care, but I found myself trying to find it to see how current the content was.
No, in fact I think this would be a terrible idea, because if I put 6/21/2007 people would perceived it to be sharply less valuable without changing a single word of the article or a fact about reality as it exists in 2013. Dating it is just asking people to discount my advice after a 48 hour window from publication.
I agree with you that as a reader, often a publication date would be useful information. However, from the point of view of the publisher, it's often better to publish 'evergreen' content, that is always maximally valuable to visitors, and to the publisher (advertising, personal branding, authority-building, etc). So if you're trying to do anything like that, it may be best to leave off dates.
And as Patrick says, the advice in this post would have been useful 5 years ago, and will probably be useful 10-20 years hence. If you're going for evergreen content, you can write in such a way too.
I believe Isaac Asimov mentioned this one time. I think he had mentioned an athlete's name in a story, and said that he regretted it, because in a few years no one would remember the athlete, but otherwise his story would still be relevant.
This is probably one of the best arguments for niche specialization that you'll find. Say you're a Ruby developer, but you know a lot about CPA, ARPU, LTV, churn, and other terms SaaS types care a lot about.
Yes, you might cost significantly more per week than a peer Ruby developer who might be employed by a prospective client of yours, but the cost of getting that employee's knowledge to around where yours is outweighs the difference.
Additionally, clients want to lower the risk that a project will fail (note: this doesn't mean technically fail, as in the code doesn't work.) By "leveling up" in a niche specialty, you'll lower the risk that you'll fail when a project in that niche comes your way. (Clients also have a tendency to reach deeper into their pockets when the risk of failure is lower.)