On #2, that's the easy read and it's not wrong! But what got me about this one was that Sales wasn't really ahead of anyone. They were selling based on what they understood. Product was building based on what they understood. Both were reasonable. The gap was that nobody checked whether those two understandings matched.
My direct experience was of sales overselling capacity rather than features. I was on both sides of this at different times. Adding a feature is one thing; adding a couple of orders of magnitude of scalability is another.
The difficulty with job costing ripples backward from accounts payable. The question was a simple and obvious one: how much money does this project have left in its budget, right now? It proved impossible to answer *because of accounting controls.* How did you solve it?
How did we solve job costing? Short answer: painfully.
The org units architecture was a ground-up rebuild, which meant existing customers had to be reimplemented from scratch if they wanted the new functionality. And then we discovered that many of our enterprise clients had multi-dimensional costing structures that were... let's say aspirationally complex. In some cases the bigger unlock was helping them simplify their costing policy before we tried to build it.
On the overselling capacity point: I hear you, and I've seen that version too. But in this case Sales wasn't out over their skis. Product and Engineering signed up for the work. Everyone agreed on the plan. The problem was that the plan meant different things to different people. Which is arguably harder to catch than a team overselling, because nobody feels like anything is wrong until it very suddenly is.
And in summary: job costing is surprisingly hard 😂
1. Job costing is surprisingly hard.
2. Sales are *always* writing checks the product can't cash.
Ha, yes on #1.
On #2, that's the easy read and it's not wrong! But what got me about this one was that Sales wasn't really ahead of anyone. They were selling based on what they understood. Product was building based on what they understood. Both were reasonable. The gap was that nobody checked whether those two understandings matched.
Thanks for reading, Frank!
My direct experience was of sales overselling capacity rather than features. I was on both sides of this at different times. Adding a feature is one thing; adding a couple of orders of magnitude of scalability is another.
The difficulty with job costing ripples backward from accounts payable. The question was a simple and obvious one: how much money does this project have left in its budget, right now? It proved impossible to answer *because of accounting controls.* How did you solve it?
How did we solve job costing? Short answer: painfully.
The org units architecture was a ground-up rebuild, which meant existing customers had to be reimplemented from scratch if they wanted the new functionality. And then we discovered that many of our enterprise clients had multi-dimensional costing structures that were... let's say aspirationally complex. In some cases the bigger unlock was helping them simplify their costing policy before we tried to build it.
On the overselling capacity point: I hear you, and I've seen that version too. But in this case Sales wasn't out over their skis. Product and Engineering signed up for the work. Everyone agreed on the plan. The problem was that the plan meant different things to different people. Which is arguably harder to catch than a team overselling, because nobody feels like anything is wrong until it very suddenly is.
And in summary: job costing is surprisingly hard 😂