February 9, 2018
An API is not a business goal
In order to value price a project, you need to have a sense of the client’s desired business goal.
When folks are getting started with value pricing, it’s very common to confuse a large deliverable with a business goal.
They are not the same thing.
Here’s a hypothetical question that illustrates this common misconception:
Hey Jonathan,
I’ve been listening to the Ditching Hourly episode about value pricing agile projects (with Jason Mundok) and I’m not 100% sure I get it.
Here’s what I’m thinking... I have a potential client who wants us to quote a project for them. The scope of the project is very loosely defined but the goal is not. The business goal is to expose all the functionality of their existing SaaS through a new API.
This sounds reasonable to me as far as business goals go but to define a scope around that goal - especially since the existing functionality is extensive and in flux - is pretty much impossible.
Is that scenario a bad candidate for value pricing?
A new API is a deliverable. It is a project goal, but it is not a business goal.
(ASIDE: I like the term “business outcome” better than “business goal” because it’s more obvious that something like an API is not an outcome)
If a client tells you the goal the project is a new API - or migrating to AWS, or rewriting an Angular UI with React - you have to dig deeper if you want to value price the work.
How do you dig deeper?
By asking questions like:
“How specifically are you hoping this new API will improve your business?”
Or
“What business metric are you hoping this new API will improve?”
Or
“What can we measure along the way to make sure we’re moving the needle for your business?”
The answer could be any one of lots of things, like:
- Decrease customer churn
- Increase lock-in
- Enable a b2b partnership
- Create a third party app ecosystem
- Breakdown internal data silos that are stifling progress
- Box out competitors by being the favorite of developers
Even some of these examples could be drilled into more deeply.
I realize that your client may not be interested in entertaining these sorts of questions from you. If they are not, it’ll be hard to value price profitably.
It will also be hard to value price profitably if the client has lots of alternative to choose from (i.e., they see you as interchangeable with other alternatives)
If you can’t value price the work, other alternatives would be:
- Quote the entire job at a VERY HIGH fixed price. If the client pushes back, suggest breaking the project into smaller phases and only quote one at a time.
- Give the client two options: an hourly estimate at $X and a fixed price of $X+85%. If $X+85% feels too risky to you, your hourly estimate is too low. Raise your hourly estimate $X until a fixed price of $X+85% feels reasonably safe.
- Sell large block of hours, paid in advance. Make no guarantees how much work will get done in a block. If they want a guarantee about what will get done, go back to option 1 (i.e., VERY HIGH fixed price)
Did I explain that well?
Yours,
—J
P.S. Friends don’t let friends bill hourly. Gift options available at checkout-> http://hourlybillingisnuts.com