Your off-the-cuff brainstorming can land you in trouble. Here's how to avoid it.

Some thoughts on how to handle it when all those great ideas suddenly become contractual roadmap items.

In the kickoff workshop for my startup's first large enterprise contract, there were twenty-five people from the customer. We were seven people in our entire company.

We'd spent six months on contract reviews, endless meetings, and way too much money on lawyers to win this massive deal. We had outcompeted companies 100x our size. Once we got past this stage with our previous customers, things kind of just worked itself out.

"Working itself out" isn't really how giant, multi-national corporations do things. Enterprises are built to eliminate risk. Startups are built for it. They love the idea of working with someone who moves fast, but that speed is risky, and the natural response is a contract that tries to contain it.

That meant we had accrued a bunch of unintentional commitments. The small agreements we made in passing, or an idea that got shared in a meeting, turned into contract clauses, which turned into Jira tickets, and started affecting our roadmap. You're familiar with technical debt. You can call this promise debt.

The lawyers spent weeks arguing over liability caps and payment terms. Everyone took those seriously. The product often doesn't get that treatment. You get to dream alongside your customer and promise things that already sound close to your plan. Unfortunately, the exciting brainstorm over lunch becomes something your team is contractually expected to ship.

That's why you have to assume the contract will be treated as roadmap. Read every feature-related line with the same care as liability clauses. Once written down, items that weren't really on the roadmap two weeks ago now have hard deadlines.

Promise debt doesn't just weigh on your roadmap, it weighs on your team. Instead of asking what to build next, you start asking what's left to deliver.

In enterprise sales, the leverage isn't equal. Customers set the tempo and they have the budget. You want the deal. Which means, sooner or later, you'll agree to something you didn't plan to close. That doesn't have to mean giving up control.

A key approach is to commit to outcomes instead of features. By framing the conversation around the problem, not the implementation, you get the space to build in a way that fits your product and aligns better with your roadmap.

In addition, you can dedicate a portion of your quarterly development capacity to customer-driven initiatives. They can all submit requests, which you prioritize based on impact and feasibility.

Finally, adding a price will separate the nice to have from the need to have. If they insist on a development during the contract process, it can be scoped as a billable project outside of the shared capacity. By adding a cost, you increase the tension around actually calling for the job to be done. It'll only be requested if it is considered valuable, and worth the budget allocation.

You will accrue promise debt. There is no way around it. But if customers trust your vision, they'll be less likely to try to define it for you. You'll be in the driver's seat, with only the occasional backseat driving.

I've spent 20 years building products, largely on intuition. Now writing to put some method to the madness. Mostly tech, AI, and product thinking across startups and enterprise. Read the full article on Substack for more depth.