You just closed a $300,000 deal. The team is popping champagne. But as the founder or product leader, you feel a pit in your stomach. You know exactly what’s coming next: a new client, a new salesperson, a new delivery scope—and you’re going to start the entire sales process from absolute scratch.
You think you’re selling a B2B software product. You’re not. You’re running a custom project factory, and your revenue is hiding the truth.
Revenue doesn’t validate your product; it just proves you have a really good sales team willing to suffer through chaos.
We see this all the time in B2B. You build a solid piece of software. Your internal team knows what it does. Dev knows the standard features. PM knows the roadmap. You think, “The product is done, hand it to sales.” Then the friction starts. Sales asks: Do we sell the whole suite or just the analytics module? Is the hardware included? Do we charge per user or per device? The client wants a custom API, is that extra?
Nobody knows the answers. So the salesperson improvises. The pre-sales engineer redesigns the solution on the fly. The CEO jumps in to arbitrarily slash the price to close the deal. Delivery weeps.
When leadership sees poor sales, they do the same thing every time: they buy new pitch decks, rebrand the packaging, and send the sales team to training. But the problem isn’t your salespeople. The problem is you never defined what you’re actually selling.
A product organizes what you can build. A commodity organizes how you get paid for it. If you haven’t defined the second, you don’t have a business—you have a chaotic consulting agency.
Let’s get real about the gap. A “Product Baseline” organizes your internal capabilities. It answers: What are we building? What’s standard? What’s a custom edge case? But a “Commodity Baseline” is entirely different. It organizes your transaction logic. It answers: Who is actually buying this? Why are they spending budget on it right now? What exactly are they taking home? How do we price it? And what are we obligated to deliver?
Take an energy management system. The product has data collection, anomaly alerts, and reporting. But a client walks in and says, “I only want the analytics and reporting. I already have the sensors.” Can you sell it that way? If they double their facility size, does the price double? If they want SaaS pricing instead of a one-time fee, can you support it?
If your PM, sales, and delivery teams don’t have a locked-in, unified answer to these questions, you don’t have a product. You have a bucket of features waiting to be reassembled into a bespoke project every single time.
And here’s the dangerous part: the better you are at project execution, the longer you can hide this missing step. You can muscle through deal after deal, booking revenue, while never actually building a scalable commercial asset. You’re mistaking your ability to execute custom projects for product-market fit.
Flexibility without a baseline isn’t customer-centricity; it’s just chaos disguised as service.
Building a commodity baseline doesn’t mean turning your software into a rigid, take-it-or-leave-it fast-food combo meal. B2B clients will always have different scales, existing systems, and unique scopes. The baseline exists so you know exactly where the standard ends and the custom begins.
Without it, sales promises “we can integrate with anything,” delivery drowns in unpaid custom dev work, and the product team is forced to maintain one-off features for the rest of time. Every deal becomes a zero-sum negotiation instead of a predictable transaction.
Stop trying to fix your sales motion with better PowerPoint slides. Sit down and answer the five hard questions: Who, Why, What, How (Transaction), and How (Delivery). Lock them into a baseline. Only then will your next sale actually be easier than your last.
FAQ
Q: But every B2B client is different. How can you have a standard baseline?
A: B2B clients are different, but their core problems aren't. A baseline doesn't eliminate customization; it defines the starting point from which customization deviates. If you don't know your baseline, you're not customizing—you're just building from scratch every time.
Q: What's the first step to building a commodity baseline?
A: Stop looking at your feature list. Map out your last three successful deals and identify the exact scope, price, and delivery constraints that made them profitable. That intersection is your baseline.
Q: Isn't bespoke project work more profitable than standardized products?
A: In the short term, yes. But it doesn't scale. You're trading long-term enterprise value for short-term consulting revenue, and eventually, your delivery team will burn out under the weight of unmaintainable custom code.