A small suggestion (and boy I do not have this all figured out yet)
Charge by feature, estimate in your head how long a feature will take, multiply by your secret hourly rate, and say that will cost X dollars and be ready at the end of iteration one.
This is good for several reasons
It ties the billing cycle to a feature a client wants instead of to your time which they could care less about.
It focuses on the clients features - so you are always talking their language. I am trying to get client to write a press release for the feature (think scrum story but more visceral)
The aim is to break down the project into chunks the client cares about and thinks about in their terms and then to charge for it in increments that are of value or interest to the client. Usually this is on the order of days - this way you are charging very small fixed cost projects - reducing your risk whilst getting off the per hour billing mindset
It also allows you to find any way, some way to measure business value from the feature (hits per day, minutes saved per sales call - whatever)
Being the person who talks in their ideas, and shows how they brought in more revenue or higher kPI is a good place to be.
Then raise your secret hourly rate, and features just get more expensive. Instead of arguments about hourly rates and full time salaries
I like this approach; the other reason it is good is that when the client sees the proposal, they get choices. They can see the breakdown, see which feature costs how much, and customize how they want it.
This involves the client more, making it more of their project, and also it changes the dialogue from "Should I hire them?" to "Which features should I hire them to do?"
The only thing I would change is that your expected time per feature times your hourly rate is the floor cost of each feature. Be aware of your costs but do not charge solely based on them. If feature X is a huge win for the client but is easy for you (due to your years of experience, built-up tech-stack, or home-built tools), don't give it away for peanuts!
Yes it makes it very easy to shift features around to get a decent spread of easy and hard in a week / iteration.
It's also useful to have a check - more than a three day estimate basically means its too big - redo the press release
As for the floor cost - maybe. You still need to keep your feet on the ground at some point so increasing your rates and multiplying up is a fine approach. When you have an obvious winner go for much bigger rewards - but not everytime
It has the difficulty of justifying to clients who reckon they know the standard industry rates, why a feature costs so much. Having a per-feature price doesn't get round questions about why this costs so much.
Clients who have a little technical knowledge are the most dangerous. I have one with a large-agency background in the mid-'90s who quibbles every single time over the cost, whether fixed for per-hour. Because he expects it to always be a quick 5 minute/1 hour fix. So even on fixed price, he's sat there going "Well this costs $400, it isn't complex and will only take 2 hours, so they're charging... $200/hr?!!". Cue the same old justification of effort fight again, where "because there are unknowns and it could take 2 hours to debug the network issue" doesn't justify charging for it, because computers are simple, I'm the expert and I should know what I'm charging for...
Quite simply we have moved from discussing my hourly rate and onto "you will deliver valuable feature X, that I estimate will improve sales by Y - but you are charging too much for it"
Now that is a much easier argument to have - plus if I have many other features I can swap some around, split X into xx and xy and so on. Talking about features for the client is always good
that's great if you're really, really certain that your definition of a "feature" is one that the customer will accept. A few years ago I was working for a consulting firm that had this bad habit of pitching something, and the customer would somehow think they were getting something much much bigger than what we promised, and we'd either end up working for free or the client would end up angry and walk away.
Oh, that's clever! A press release is going to be much better than any acceptance test or design document. I can't believe I've never heard of anyone else doing it that way!
Comments
A small suggestion (and boy I do not have this all figured out yet)
Charge by feature, estimate in your head how long a feature will take, multiply by your secret hourly rate, and say that will cost X dollars and be ready at the end of iteration one.
This is good for several reasons
It ties the billing cycle to a feature a client wants instead of to your time which they could care less about.
It focuses on the clients features - so you are always talking their language. I am trying to get client to write a press release for the feature (think scrum story but more visceral)
The aim is to break down the project into chunks the client cares about and thinks about in their terms and then to charge for it in increments that are of value or interest to the client. Usually this is on the order of days - this way you are charging very small fixed cost projects - reducing your risk whilst getting off the per hour billing mindset
It also allows you to find any way, some way to measure business value from the feature (hits per day, minutes saved per sales call - whatever)
Being the person who talks in their ideas, and shows how they brought in more revenue or higher kPI is a good place to be.
Then raise your secret hourly rate, and features just get more expensive. Instead of arguments about hourly rates and full time salaries
I like this approach; the other reason it is good is that when the client sees the proposal, they get choices. They can see the breakdown, see which feature costs how much, and customize how they want it.
This involves the client more, making it more of their project, and also it changes the dialogue from "Should I hire them?" to "Which features should I hire them to do?"
The only thing I would change is that your expected time per feature times your hourly rate is the floor cost of each feature. Be aware of your costs but do not charge solely based on them. If feature X is a huge win for the client but is easy for you (due to your years of experience, built-up tech-stack, or home-built tools), don't give it away for peanuts!
Yes it makes it very easy to shift features around to get a decent spread of easy and hard in a week / iteration.
It's also useful to have a check - more than a three day estimate basically means its too big - redo the press release
As for the floor cost - maybe. You still need to keep your feet on the ground at some point so increasing your rates and multiplying up is a fine approach. When you have an obvious winner go for much bigger rewards - but not everytime
It has the difficulty of justifying to clients who reckon they know the standard industry rates, why a feature costs so much. Having a per-feature price doesn't get round questions about why this costs so much.
Clients who have a little technical knowledge are the most dangerous. I have one with a large-agency background in the mid-'90s who quibbles every single time over the cost, whether fixed for per-hour. Because he expects it to always be a quick 5 minute/1 hour fix. So even on fixed price, he's sat there going "Well this costs $400, it isn't complex and will only take 2 hours, so they're charging... $200/hr?!!". Cue the same old justification of effort fight again, where "because there are unknowns and it could take 2 hours to debug the network issue" doesn't justify charging for it, because computers are simple, I'm the expert and I should know what I'm charging for...
Quite simply we have moved from discussing my hourly rate and onto "you will deliver valuable feature X, that I estimate will improve sales by Y - but you are charging too much for it"
Now that is a much easier argument to have - plus if I have many other features I can swap some around, split X into xx and xy and so on. Talking about features for the client is always good
I have re-read the comment you made. Ditch the client.
that's great if you're really, really certain that your definition of a "feature" is one that the customer will accept. A few years ago I was working for a consulting firm that had this bad habit of pitching something, and the customer would somehow think they were getting something much much bigger than what we promised, and we'd either end up working for free or the client would end up angry and walk away.
Small features. With the "press release" written by or with the client
Oh, that's clever! A press release is going to be much better than any acceptance test or design document. I can't believe I've never heard of anyone else doing it that way!
Apparently it's a common practise at Amazon - start with the customer and work backwards