Some technical decisions are really product and business decisions with a half-life of years. Here are seven a product leader should ask about early, what weak answers sound like, and what each one costs to change later.
Most architecture decisions belong to engineers, and a product leader who second-guesses database choices or framework versions is wasting everyone's time. A small number of decisions are different. They look technical, they are discussed in technical vocabulary, and they get made in a pull request on a Tuesday afternoon. Then they quietly decide which customers you can sell to, which regulators you can satisfy and how long the next big contract will take to close. Those decisions are product and business decisions with a half-life measured in years, and the product leader should not let them happen without being in the room.
This is not an argument for overruling engineers. In my experience the better rule is simple: the product leader owns the question and the consequences, engineering owns the answer. Your job is to make sure the question gets asked at the right time, with the business context attached, and that the answer is a conscious choice instead of an accident of whoever wrote the first migration.
I use two tests. First, would changing this later require migrating live customer data or breaking a promise to someone outside the company, such as a customer, a partner or an auditor? Second, does it constrain what you can sell, or to whom? If the answer to either is yes, it is a long half-life decision. If both are no, it is an implementation detail and you should stay out of it.
The seven below pass both tests in almost every B2B product I have worked on, from payments to conversational AI for regulated industries.
Ask engineering: what are the primary entities, and how does a customer map onto them? Is an "account" a company, a legal entity, a workspace or a login? Are identifiers globally unique, stable and safe to expose externally, or are they sequential database integers that leak volume and break when you merge two databases?
A bad answer sounds like "a customer is just a user with an org_id field, we can add hierarchy later." Sometimes you can. More often, the assumption that one customer equals one organization is baked into billing, permissions, reporting and every integration, and adding parent and child organizations a year later touches all of it. Changing identifiers after partners have stored them is worse, because you now need to support two forms forever.
Ask: how is one customer's data separated from another's? Shared tables with a tenant column, separate schemas, separate databases? If a customer in a specific country requires their data to stay there, what would it take to run a second region?
The bad answer is "we'll never need that" from a company whose sales plan includes banks, governments or anyone in the Gulf or the EU. You do not need to build multi-region on day one. You need a model where tenant boundaries are explicit everywhere, so that splitting by region later is an operational project and not a rewrite. The cost of getting this wrong shows up as a deal you cannot sign, which is a cost the engineering team will never see on a dashboard.
Ask: if a payment request, a webhook or a message to a third party is sent twice, what happens? What are the states of a transaction, which transitions are allowed, and where is that written down?
A bad answer sounds like "the retry logic handles it" or "it's rare." In payment orchestration I learned that rare multiplied by volume is daily. Without idempotency keys and an explicit state machine, you get double charges, orphaned refunds and reconciliation that a person does by hand in a spreadsheet. Retrofitting a state machine onto a system that has been inferring status from a mix of booleans means reconstructing the history of every in-flight transaction, and you will discover states nobody designed.
Ask: can we answer "who changed what, when, and from what value" for any record a customer cares about? Is that history append-only, and can a customer administrator see or export it?
The bad answer is "we have application logs." Logs are for debugging, they rotate, and they rarely capture the before and after of a business change. An audit trail is a product feature that enterprise buyers ask about in the first security review and that disputes depend on. Adding it later is possible for new events, but you can never recover the history you did not record, and that gap is exactly what an auditor or a customer's lawyer will ask about.
Ask: which parts of our system are a contract with the outside world? What is our versioning policy, and how long do we support an old version after a new one ships?
A bad answer sounds like "the API is just our internal endpoints with auth on them." That means every internal refactor is a potential breaking change for customers, and the team will slow down to avoid breaking things they cannot see. Once a few hundred integrations depend on a field name, it is no longer yours to rename. Designing a deliberate public boundary, even a thin one, is far cheaper than discovering which internals your customers have been relying on.
Ask: is this capability something customers choose us for, or something they expect to simply work? If we buy it, what is our exit path, and who owns the data?
The bad answer comes in two flavors. One is building your own authentication, billing engine or feature flag system because it seemed interesting. The other is outsourcing the thing that is actually your differentiation to a vendor whose roadmap you do not control. The decision rule I use: buy commodity, build core, and for anything bought, make sure the data model on your side does not mirror the vendor's model so closely that switching becomes a migration of your entire product.
Ask: who can do what, and how is that expressed? Fixed roles, custom roles, permissions scoped to teams, regions or record types? Can an enterprise customer map their own structure onto it?
The bad answer is "admins and users, and we'll add roles when someone asks." Someone will ask, usually in the last week of a large deal. Permission checks scattered across the codebase as "if user.isAdmin" are among the most expensive things to unwind, because every one of them is a potential security bug when you change the model. A central authorization layer, even with only two roles in it at first, keeps the later change contained.
Take a B2B invoicing tool that grew by selling to small agencies. Each agency is one account, users are either admins or members, and all data lives in one region. Now a mid-size logistics group wants a pilot covering three subsidiaries in two countries, with finance staff who should see only their own entity, and a requirement that one subsidiary's data stays in-country.
Every decision above shows up in that single request. The data model has no concept of a group with subsidiaries. The permission model cannot express "sees entity A only." Residency was never considered, and tenant separation is a column that some queries forget to filter on. The buyer's security team will ask for an audit trail of invoice edits, and the logs do not have one. None of these were wrong choices for agencies. They were unexamined choices, and the bill arrives all at once, during a sales cycle, with a deadline set by someone else.
Had the product leader asked the seven questions two years earlier, the team would not have built multi-region or custom roles. They would have made smaller choices: an organization entity with room for a parent, a single authorization function, tenant scoping enforced in one place, an append-only change history on invoices. Each costs days at the start and months to retrofit.
The fair objection is premature generalization. Teams that try to design for every future customer ship nothing, and a product leader waving these questions around can cause exactly that. The answer to most of these questions should be "not now, but we are not closing the door," and the job is to identify the cheap choices that keep doors open, not to build the rooms behind them.
This advice also does not apply everywhere. If you are still searching for product-market fit and might throw the code away in six months, optimize for learning speed and accept the debt knowingly. If you are building an internal tool with one customer who sits down the hall, most of this is overhead. And if you are a solo technical founder, you are already in the room, so the only discipline needed is writing your answers down.
Book an hour with your engineering lead and go through the seven areas with two questions each: what did we decide, and what would it cost to change? Write the answers in a short document and revisit it each quarter or whenever the sales plan changes direction. You are not reviewing their work. You are making sure that the next time a large customer asks for something the architecture cannot do, it is a known trade-off you chose, not a surprise you inherited.
Written by
Ratomir Jovanovic
AI makes producing specs, designs and code cheap, but judgment, review and integration stay expensive. How roles, rituals and hiring change on a small product team, and where it still breaks.
21 October 2026
Enterprise buyers do not just buy an AI product, they buy one their security team can approve. What reviews actually ask, why late answers stall deals, and how to build the evidence into the product.
4 November 2026
Generic AI features lose ground with every foundation model release. Durable AI products win on one painful workflow, proprietary context, trust and distribution in a single segment. Here is how to score and pick that niche.
2 October 2026