If you’re in the B2B business, your clients are paying for a specific set of outcomes. They don’t care about your feature set - they’re buying a specific outcome - the net result of using your product.
Your business objective is to maximize the size of transactions that deliver the specific outcome. A transaction is the moment a customer gets a measurable outcome and you get paid for it: a signed contract, a successfully filled role, time or money saved.
This simple & reductive framing often eludes early stage founders well into their first or second product.
For Netflix, the product is not the product, it’s their stock.
What do B2B clients even buy?
Sometimes, the outcome that your client is buying, is actually a by-product of your product.
- If you’re running a recruitment platform, your client’s desired outcome is a great hire who stays 18+ months, not time spent in your UI.
- If you’re running an expense reporting platform, your clients are not looking to make it pleasant for their reps to track expenses, but, essentially, curtail unnecessary expenditure
Founders confuse
- Time spent in the tool ≠ value created
- Feature depth ≠ likelihood of a transaction
- Product completeness ≠ customer willingness to pay
Hearing this, begrudgingly, some founders are able to let go of some features. I’d argue for taking this approach further - extreme reductionism.
Zooming out
Let’s look at how your company will be judged by others. In the critical decision points in your startup’s lifecycle - fundraising, exit, bankruptcy - outsiders will be looking at the value of your company. How will they measure it?
For publicly listed companies - stock valuation. The product of Netflix is not the platform, or movies, but their stock valuation. As with any reductive statements, it’s true only to a point, but also provides a useful perspective how decisions are made.
For startups that barely make any money? Methods varied across time and business-models. Valuations are ultimately built on evidence of repeatable transactions.
Essentially, the goal is to demonstrate that someone has exchanged their version of value for yours. If someone is already paying you in cash, your credibility and valuation increase significantly. You could also argue that your value rises—though to a lesser extent—when clients show intent through actions such as subscribing, attending a webinar, signing a letter of intent, or committing to a performance-based contract.
If you squint really hard and try to be reductive, you could argue that your goal is to maximize transactions between your company and your clients. Quantity, speed or size, you want growth.
If you apply this frame to your startup motions, you might find that most of the things you are doing are irrelevant.
Putting this into practice
Real life example - we’re structuring and setting up a new venture, a recruitment marketplace with a special sauce. Our team had a difference of opinion of what is the starting point regarding the scope of the product.
Option 1: Build the platform first
We need a barebones marketplace where the end customer will be selecting, interviewing and signing talent on their own and pay for the platform.
Option 2: Deliver the outcome first
We need to place talent in companies and get paid for it, channels and interfaces don’t matter.
If you agree, that only transactions matter, #2 is the valid choice. My argument for selecting #2 is reductive too - only transaction matter. If that’s too extreme, here’s a few supporting arguments:
- Advantages “in” the product platform won’t outweigh the economic fundamentals (crowded market, poor match between candidates and clients, cheaper alternatives, etc.)
- The effort your team, and your client, will need to go through to be convinced to try it are higher if you opt for self-service. If you’re testing waters, why spend more?
- Build nothing until you have 3 paid placements - prove demand manually first while tracking unit economics (time-to-hire, fee size, repeat customer rate)
I believe the net result is positive for early-stage companies and promotes capital expense reductions.
So next time your team is debating a massive backlog, ask one question: “Does this get us to the next transaction fastest?”
If the answer is “no”, you’re building product, not business.