From idea to system

Product ideas do not arrive as specifications. They usually start with a real problem, a few examples, an intuitive solution, and pressure to begin. That is normal. Trouble begins when everyone fills in the missing details differently and the disagreements appear only after development is underway.

When I join a new project, I first try to understand what should change for the user and why the product is worth building. Screens, technology, and features come later.

That is also the purpose of a product architecture sprint.

Do not start with the feature list

“We need an AI assistant” describes a possible solution, not the problem. “An operator spends twenty minutes finding the source behind a claim” is more useful. It identifies the user, the current cost, and what an improvement might look like.

AI may be part of the answer. A better search, a rule, or an integration between two existing systems may be enough. Choosing the solution before understanding the decision it should support is a reliable way to build the wrong thing well.

The same applies to a platform or marketplace. The word “platform” does not say who may publish, who approves changes, which data is required, or what happens when a participant makes a mistake. Those are product decisions, not minor implementation details.

A map that is good enough to begin

The first version does not need an enormous document. It needs clear answers to a small set of questions:

1. Who uses the product, and who else is affected?
2. What are the important objects in the domain, and who owns them?
3. Which steps does the user take?
4. Where does the data come from, and how trustworthy is it?
5. Which rules and permissions apply?
6. What can fail, and how do we recover?

This is where expensive contradictions become visible. A “real-time” feature may depend on a source updated once a day. An apparently automatic step may require legal approval. A recommendation can look precise even when the data behind it is missing.

The working loop

I use a simple loop. It is not a new methodology and does not need a grand name. It is merely an order that makes it harder to skip important questions.

Intent says what should change. Context describes the current situation and known constraints. Expectations define what the product must do. The specification and plan turn those answers into working decisions. Code and tests show whether we understood them correctly.

At the end of each stage, I compare the result with the original intent. If we learned something new, I update the documents before the next stage. Otherwise, the team ends up working from an outdated explanation of the product.

The first slice should cross the whole system

A useful stage is not ten screens with no real data, nor a backend service that nobody can use. I prefer a narrow but complete slice: read one source, validate the data, apply a rule, show the result, store the decision, and allow an error to be corrected.

That slice quickly shows whether the links between product, data, and architecture work. The rest can expand after one real path has been verified.

Version one does not have to solve the future

Future ideas always appear during design. I record them, but I do not let them quietly enter the first delivery. I separate decisions that would be expensive to change later from decisions that can remain simple for now.

Before serious development begins, I want a compact package: purpose, users, domain vocabulary, important workflows, data sources, first-version limits, risks, acceptance criteria, and the first implementation step.

Documentation is not the final result. Its job is to help product, engineering, and operations talk about the same thing and challenge a decision before it becomes expensive code.