After two decades of building digital products, the most reliable lesson I have learned is also the easiest to ignore: the quality of the software is rarely the first question. The first question is whether the business behind it is clear enough to be built.
Founders naturally arrive with features in mind. They can picture the application, the dashboard, the customer journey and perhaps even the technology stack. That energy is valuable. But a feature list is not yet a product strategy, and a product is not yet a business.
Software is the visible part of a larger operating system
Customers see an interface. Behind it sits a chain of promises, decisions and responsibilities. Someone must acquire the customer, validate the request, deliver the service, handle an exception, collect payment, support the relationship and learn from the outcome.
When those responsibilities are unclear, software does not remove the confusion. It distributes the confusion at speed. The result may look polished while teams still rely on spreadsheets, private messages and manual interventions to keep the operation alive.
The purpose of a digital product is not to turn a process into screens. It is to create a dependable system for delivering value.
This is why I begin product conversations with the operation, not the interface. What is the promise? Who fulfils it? Where does information enter the business? Who owns each decision? What happens when the normal path fails?
Five questions to answer before discussing a roadmap
A founder does not need every detail resolved before starting. The business does, however, need enough clarity to make product decisions intentionally. I look for five answers.
1. What valuable outcome are we creating?
Describe the result from the customer’s perspective, without using the name of a feature. “A booking platform” describes software. “Reliable access to the right service at the right time” describes value. The second statement gives the product team room to solve the real problem.
2. Who participates in delivering that outcome?
Most serious platforms serve more than one type of user. Customers, operators, managers, partners, field teams and finance may all touch the same transaction. Product scope becomes clearer when we map their responsibilities and the information each person needs.
3. How does the transaction work economically?
Pricing, payment timing, fulfilment cost, cancellations, refunds and partner settlement are product questions. Leaving them until later can force expensive architectural changes because money follows the workflow built into the system.
4. Where does ownership sit?
Every important state needs an owner. Who approves, rejects, escalates or corrects it? A workflow without ownership becomes a queue. A dashboard without decision rights becomes decoration.
5. What evidence will tell us this is working?
Usage alone is not success. A useful product metric connects customer behaviour to an operating or commercial result: faster fulfilment, fewer exceptions, higher conversion, stronger retention, better utilisation or lower cost to serve.
If the team cannot explain the complete journey from customer need to fulfilled value—including exceptions and payment—the roadmap is premature.
Build the smallest complete operating loop
The phrase “minimum viable product” is often misunderstood as the smallest collection of screens that can be released. That approach produces demonstrations, not businesses.
I prefer to define the smallest complete operating loop. It begins with a real customer need and ends with value delivered, recorded and measurable. It includes the essential internal work, not only the customer-facing experience.
For a marketplace, that loop may include discovery, request, matching, fulfilment, payment and exception handling. For a business platform, it may include intake, validation, assignment, execution, approval and reporting. The scope can be narrow, but the loop must close.
This changes prioritisation. A beautiful secondary experience may wait while a modest operations screen becomes essential. That is not a compromise in product quality. It is a decision to build a business capability instead of a visual prototype.
Good architecture follows stable business boundaries
Technical architecture should not be selected in isolation from the operating model. The most useful boundaries are often already visible in the business: customers, orders, service delivery, payments, partners, permissions and reporting.
When these concepts are clear, teams can make better decisions about data ownership, integrations, automation and security. When they remain mixed together, the product becomes harder to change because every business decision touches every part of the system.
Scalability also means more than handling traffic. A scalable product can support more customers, more services, more teams and more decisions without requiring the founder to personally resolve every exception. That is an organisational property expressed through software.
This is a leadership responsibility
Product teams can challenge assumptions and expose gaps, but they cannot decide the business on behalf of its leadership. Founders must make the hard choices: which customer matters first, which promise the company is prepared to keep, which workflow becomes standard and which complexity will deliberately remain outside the first release.
At Kenzi.ai, the strongest engagements begin when commercial, operational and technical conversations happen together. It lets us design the product around a shared truth rather than translating three conflicting versions of the business into code.
Starting with the business does not slow development. It removes the most expensive kind of speed: building confidently in the wrong direction.
Mousa Alsheikh is the Founder and CEO of Kenzi.ai. He works with founders and organisations to shape digital products, scalable platforms and AI-enabled operating systems.