Yes! Note that you can get halfway to the place McDerment (and Patrick McKenzie) were at simply by not charging by the hour. Simply moving your pricing increment from hours to days or (ideally) weeks changes the conversation you're having with your client.
McDerment had to develop serious sales skills to pivot inbound requests for website paint jobs to strategic marketing engagements. But you don't need sales skills to establish a minimum billing increment of a day. Doing that will pull you towards more strategic discussions and allow you to dip your toes in the water of solution sales.
Incidentally, while my hat is definitely off to McDerment for pulling this off, I assume he'd be the first to tell you that this is the moral of every book on consulting ever written.
I'm completely on board with the "bill by the day, not the hour" idea. Having implemented it in our own consultancy, it's done wonders.
But it hasn't gotten us to the stage you're talking about - we're definitely making headway in establishing ourselves as (Python) experts, but I don't think we're really at the stage where we can sell based solely on the customer's value - building software is simply too replaceable a commodity (See note). Nor do I think we necessarily want to be there - lawyers don't sell on value, after all, nor do most professional services firms.
Also, increasing the billing increment too much and selling based on value starts taking you into "fixed-project pricing" territory, which is a whole different field. Not that it's better or worse, just different, with its own set of needs. This we discovered in retrospect after practically switching all our work to fixed-pricing, then realizing what a big difference that was (that we weren't equipped to handle).
Note: Building software is too replaceable in the sense that there are plenty of alternatives to get some software built (hiring, cheaper freelancers, etc). We certainly manage to sell ourselves as better than alternatives because of speed an expertise. But that's a far cry from building projects and selling on value, which IMO is again, a whole other field which is hard to shift into from any old software consultancy (different customers, different sales pitch, different needs). I mention this because tptacek's basic point of "switch to daily billing" is better advice in that sense - it's easy to do from just about any position with just about any set of clients, and by magic improves your life.
Why is hour < day < week? I read the patio article where he said that, but since I've never been a contractor, I don't understand the difference that would make.
Also, since an hourly rate is standard and job postings say how much they pay by the hour, isn't it common to be rejected when you ask for a daily/weekly rate?
Smart customers have their own method of pricing to compete with the value-based pricing suggested in the post. It's called market-based pricing. Even if my programming work will make the client $100,000, if the client is convinced he can get that programming work done for $5,000, he will pick that over my $20,000 quote.
I've read these several posts along these lines. The one huge assumption they make is that you have good clients who aren't on a budget and won't go shopping. Those clients are much harder to find as a freelancer.
"The one huge assumption they make is that you have good clients who aren't on a budget and won't go shopping. Those clients are much harder to find as a freelancer."
Agree. And it's not even so much budget as "not a schmuck" (sorry not a better way to put that).
When I saw this, I laughed:
"As an example, if I was proposing to build a website capable of creating an additional $100,000 of profit annually, I would ask the client to make an investment of $40,000 in their website."
So we are taking a totally speculative number of profit ($100,000) and charging $40,000 to get there. You would have to either be working for a large corporation (using OPM) and have no clue to buy into a proposal phrased like that or be new in business and totally naive. The entire presentation to me smacks of naiveness.
But here's the good part. I can totally see how things like this could and do work. That said you will have to find the type of customers who will fall for something like this.
Most business people who have been around can smell a sales presentation a mile away and to many of them (me in particular) it's an instant turn off because it reaks of "you are going to be paying a lot for this that's why we won't tell you upfront the cost. Because we are going to do some smoke and mirrors to make you go for it."
Lastly, one of the reasons in favor of discussing pricing in advance of a presentation is also to qualify people. I've seen to many salesman stupidly come in and not qualify people in advance simply not realizing that the local small restaurant simply isn't going to part with $10,000 no matter what you promise or tell them (or will have contract signers remorse and back out.)
Can a smart customer really get the job done for $5,000? Of course, because this customer will have clearly defined his requirements up-front. The average client will not have clear goals or requirements thus forcing the programmer to iteratively come up with a solution that meets the client's unwritten expectations. This overhead will generally add up to the amount of the higher asking price. So in the case of a poorly defined project, a $5,000 job will be woefully inadequate and will require the client to start over from scratch.
Unfortunately I just got hit by 2 projects in a row that passed 3x overage. I quoted 2 weeks to finish, but they both ended up taking over 6. I'm probably not even making minimum wage for the last couple of months.
So if you are going to quote by the job, be sure to put in limits in case it goes over your time budget so you can renegotiate.
Also I would not recommend having a "friend rate". Your workload just goes up exponentially with a proportionate decrease in pay.
If anyone could play devil's advocate on the article, with solutions to warning signs, I would sure appreciate the insight! (Not that I disagree with the article, just, my track record is really tiring me out).
I think you're missing the idea (but I could be wrong, I've never consulted): You're not supposed to promise when a project will be finished, you just set your rate per days/weeks. You estimate when it will be finished, but you don't promise.
Unfortunately I just got hit by 2 projects in a row that passed 3x overage. I quoted 2 weeks to finish, but they both ended up taking over 6. I'm probably not even making minimum wage for the last couple of months.
Those are fixed-bid projects, not time & materials with time increments of days or weeks.
But the real reason I am commenting is to point out that your results - 3x overage - are exactly the rule of thumb that gets cited for fix-bid: Take your expected level of effort and triple it.
"As an example, if I was proposing to build a website capable of creating an additional $100,000 of profit annually, I would ask the client to make an investment of $40,000 in their website."
You can only do this if what you offer is not a commodity. Otherwise, what you charge is the minimum of expected value and the market rate for the work you do.
An alternate pricing strategy that's worked well for me: charge by the "sprint" (roughly 80 hours) and peg it to an hourly rate. Now hire developers to help you with implementing the brilliant strategies you help come up with and make a reliable spread on the cost of your junior developers. Key: don't hire people to do things you can't do yourself, hire them to do things so you don't have to do them yourself.
When I sell, I'm still linking it to business value--I just make sure it's pegged to hours, which is my most direct cost (other than my time, which I make sure ends up being a very high number if calculated as an hourly rate + profit on developers) Clients know it's typically not me doing the actual implementation work, but because I've linked the overall solution to business value and presented it as an investment--which it is--it doesn't matter.
The problem I have with fixed bid projects is overages and who pays for them. In this business, they're quite common and quite often not the fault of an idiot programmer--but if you do fixed bid, you'll have to eat these costs sooner or later unless you are very good at estimating (I don't know anyone that is...)
My plumber estimates and doubles for fixed price work. This is to cover the cost of e.g. discovering rotten floorboards under the bath halfway through replacing it. Paying a fixed price is on average a worse deal for the buyer, but most buyers think that paying by time incentivises low productivity.
Whenever I see a page selling anything and it won't tell me the price and I can't find it in a click, I move on. My time is valuable, and someone who plays games to waste it is not someone from whom I want to buy anything.
I used to think like that, and it used to piss me off, until I learned about market segmentation.
If SIAI approaches me to buy $WIDGET and Google approaches me to buy the same $WIDGET, I'm charging Google an order of magnitude more than I'm charging you.
> If I felt my agency couldn’t deliver the full solution, I saw that as an opportunity to partner with another service provider. I would pay them for the work, developing a lasting business partnership along the way. And in the process, I’d learn about their area of expertise to get better at both selling and delivering it to my clients.
This seems a little off to me. Would you tell the client that you're outsourcing?
I would venture into guessing that the client wasn't told about this. If I was in a similar situation and I'd be told the company I'm paying to work on my project is outsourcing it, I'd think they're either a) they're too busy for me/I'm too small of a client for them, b) money is money so they're taking my project, but I shouldn't bet on spectacular results. Also, there'd be some broken trust involved. There would also be the risk of losing the client altogether the moment they hear you won't actually be working on their project, but someone else would be instead.
I think Patrick McKenzie / patio11 once threw out a recommendation for The Strategy and Tactics of Pricing. I'll add my voice, it's one of the better business books I've ever read.
Essentially, the core insight is as per the blog post. Identify what you are worth to the customer, prove it, then charge based on that. In the book Nagle, Hogan and Zale give examples of quite dramatic price changes where the customer agreed with the reassessment of value. The sellers could prove that a new product would quintuple productivity, so asking for a doubled price was damn near an act of charity, not highway robbery.
Also useful was their treatment of calculating the cash effect of pricing changes. Financial accounting 101 calculations can sometimes be misleading about the best pricing scheme.
What do you guys think of pay by milestone? Client and seller both agree to a milestone with a checklist that, when complete, signifies the milestone is complete. This provides clarity, transparency, and predictability. As a buyer, I prefer milestones.
As a contractor, I avoid milestones like the plague. They're appealing to buyers because, on average, buyers use them to extort additional work out of the contractor or as an excuse to defer payment (because the contractor's only recourse is court). I used to make an exception and do milestone projects for clients I trusted, but I even got screwed by them. It's just too hard to estimate software projects for both sides to come out of a milestone project on top.
EDIT: Note that I'm not claiming that people who use milestones are evil. The problem is that milestone billing for software creates lots of incentives on the client side to underestimate and underspecify work, because the contractor eats most (if not all) of the cost of identifying those problems and negotiating to get the milestone revised to include them.
That's sort of difficult to compare, because you're paying by milestones, but you probably didn't get estimated by milestone, e.g. "if we make it to the 3rd milestone you owe us this much." Your vendor is probably assuming you want all milestones completed.
I have to respectfully disagree. While I think the ideas have merit, the book reads like "the secret" or some other motivational junk. It feels simplified or dumbed-down to the point where it doesn't feel authentic anymore. He got the wrong person to write his story, IMHO.
Value pricing is a great idea for many spaces, but the headling and intro rang "I'm being sold to" alarm bells. The copy is a little too SEO sorts of people for tastes around here.
tptacek|12 years ago
McDerment had to develop serious sales skills to pivot inbound requests for website paint jobs to strategic marketing engagements. But you don't need sales skills to establish a minimum billing increment of a day. Doing that will pull you towards more strategic discussions and allow you to dip your toes in the water of solution sales.
Incidentally, while my hat is definitely off to McDerment for pulling this off, I assume he'd be the first to tell you that this is the moral of every book on consulting ever written.
edanm|12 years ago
But it hasn't gotten us to the stage you're talking about - we're definitely making headway in establishing ourselves as (Python) experts, but I don't think we're really at the stage where we can sell based solely on the customer's value - building software is simply too replaceable a commodity (See note). Nor do I think we necessarily want to be there - lawyers don't sell on value, after all, nor do most professional services firms.
Also, increasing the billing increment too much and selling based on value starts taking you into "fixed-project pricing" territory, which is a whole different field. Not that it's better or worse, just different, with its own set of needs. This we discovered in retrospect after practically switching all our work to fixed-pricing, then realizing what a big difference that was (that we weren't equipped to handle).
Note: Building software is too replaceable in the sense that there are plenty of alternatives to get some software built (hiring, cheaper freelancers, etc). We certainly manage to sell ourselves as better than alternatives because of speed an expertise. But that's a far cry from building projects and selling on value, which IMO is again, a whole other field which is hard to shift into from any old software consultancy (different customers, different sales pitch, different needs). I mention this because tptacek's basic point of "switch to daily billing" is better advice in that sense - it's easy to do from just about any position with just about any set of clients, and by magic improves your life.
tieTYT|12 years ago
Also, since an hourly rate is standard and job postings say how much they pay by the hour, isn't it common to be rejected when you ask for a daily/weekly rate?
badclient|12 years ago
I've read these several posts along these lines. The one huge assumption they make is that you have good clients who aren't on a budget and won't go shopping. Those clients are much harder to find as a freelancer.
larrys|12 years ago
Agree. And it's not even so much budget as "not a schmuck" (sorry not a better way to put that).
When I saw this, I laughed:
"As an example, if I was proposing to build a website capable of creating an additional $100,000 of profit annually, I would ask the client to make an investment of $40,000 in their website."
So we are taking a totally speculative number of profit ($100,000) and charging $40,000 to get there. You would have to either be working for a large corporation (using OPM) and have no clue to buy into a proposal phrased like that or be new in business and totally naive. The entire presentation to me smacks of naiveness.
But here's the good part. I can totally see how things like this could and do work. That said you will have to find the type of customers who will fall for something like this.
Most business people who have been around can smell a sales presentation a mile away and to many of them (me in particular) it's an instant turn off because it reaks of "you are going to be paying a lot for this that's why we won't tell you upfront the cost. Because we are going to do some smoke and mirrors to make you go for it."
Lastly, one of the reasons in favor of discussing pricing in advance of a presentation is also to qualify people. I've seen to many salesman stupidly come in and not qualify people in advance simply not realizing that the local small restaurant simply isn't going to part with $10,000 no matter what you promise or tell them (or will have contract signers remorse and back out.)
reedlaw|12 years ago
zackmorris|12 years ago
So if you are going to quote by the job, be sure to put in limits in case it goes over your time budget so you can renegotiate.
Also I would not recommend having a "friend rate". Your workload just goes up exponentially with a proportionate decrease in pay.
If anyone could play devil's advocate on the article, with solutions to warning signs, I would sure appreciate the insight! (Not that I disagree with the article, just, my track record is really tiring me out).
tieTYT|12 years ago
Amadou|12 years ago
Those are fixed-bid projects, not time & materials with time increments of days or weeks.
But the real reason I am commenting is to point out that your results - 3x overage - are exactly the rule of thumb that gets cited for fix-bid: Take your expected level of effort and triple it.
chrischen|12 years ago
You can only do this if what you offer is not a commodity. Otherwise, what you charge is the minimum of expected value and the market rate for the work you do.
dave_sullivan|12 years ago
When I sell, I'm still linking it to business value--I just make sure it's pegged to hours, which is my most direct cost (other than my time, which I make sure ends up being a very high number if calculated as an hourly rate + profit on developers) Clients know it's typically not me doing the actual implementation work, but because I've linked the overall solution to business value and presented it as an investment--which it is--it doesn't matter.
The problem I have with fixed bid projects is overages and who pays for them. In this business, they're quite common and quite often not the fault of an idiot programmer--but if you do fixed bid, you'll have to eat these costs sooner or later unless you are very good at estimating (I don't know anyone that is...)
dreamfactory|12 years ago
Tichy|12 years ago
To be honest I wouldn't know how to guarantee a client that a new web site would earn them 100000$ more. I suppose that is simply SEO territory.
Eliezer|12 years ago
benmanns|12 years ago
Additionally, this is not about playing games -- it's about finding what is valuable to a client and delivering it.
oz|12 years ago
If SIAI approaches me to buy $WIDGET and Google approaches me to buy the same $WIDGET, I'm charging Google an order of magnitude more than I'm charging you.
jackschultz|12 years ago
This seems a little off to me. Would you tell the client that you're outsourcing?
pallandt|12 years ago
jacques_chester|12 years ago
I reviewed it at my blog -- http://chester.id.au/2012/09/12/review-the-strategy-and-tact...
Essentially, the core insight is as per the blog post. Identify what you are worth to the customer, prove it, then charge based on that. In the book Nagle, Hogan and Zale give examples of quite dramatic price changes where the customer agreed with the reassessment of value. The sellers could prove that a new product would quintuple productivity, so asking for a doubled price was damn near an act of charity, not highway robbery.
Also useful was their treatment of calculating the cash effect of pricing changes. Financial accounting 101 calculations can sometimes be misleading about the best pricing scheme.
ww520|12 years ago
rdouble|12 years ago
chatmasta|12 years ago
kevingadd|12 years ago
EDIT: Note that I'm not claiming that people who use milestones are evil. The problem is that milestone billing for software creates lots of incentives on the client side to underestimate and underspecify work, because the contractor eats most (if not all) of the cost of identifying those problems and negotiating to get the milestone revised to include them.
themodelplumber|12 years ago
rch|12 years ago
bostonvaulter2|12 years ago
http://breakingthetimebarrier.freshbooks.com/
kohanz|12 years ago
triplesec|12 years ago
unknown|12 years ago
[deleted]
unknown|12 years ago
[deleted]