Building products

A new product starts with one real journey.

Before the feature list gets longer, follow one person from the first action to a useful result.

By FlowField24 Sept 20263 min read

One complete journey crosses the interface, the business rules, and the saved result. It gives the first release a clear boundary.

01 / Building products

Name the result before the features.

A product brief can become a list of screens surprisingly quickly. Dashboard. Settings. Notifications. An editor. Each sounds reasonable, but the list still does not explain what a customer can accomplish when the product is finished.

We start with a sentence about the work. For example: an operations manager creates an approval process, sends a request through it, and sees the decision. That gives us a person, an action, and a result. Now there is something concrete to design, build, and discuss.

02 / Building products

Follow it all the way through.

The useful questions sit between the screens. Who can change the process? What happens to requests already in progress? Where does a decision get stored? What does someone see if a required piece of information is missing?

Walking through a real example exposes these decisions early. We can connect the interface to the business rules and the data behind it. A beautiful editor is only one part of that journey; the product also needs to behave coherently after someone presses save, leaves, and comes back.

03 / Building products

Separate essential from next.

For each proposed feature, ask whether the first journey works without it. A basic approval history might be essential to understand a decision. A custom dashboard for every department might be able to wait. The answer depends on the business, not a universal checklist.

Keep those later ideas visible without quietly moving them into the first release. It makes the trade-offs easier to discuss: what we are proving now, what remains uncertain, and what would justify the next investment. A smaller first release should still complete the work it promises.

04 / Building products

Give new work a clear boundary.

Greenfield does not have to mean an entirely new company or an empty technology stack. A new editor can connect to an existing product. A new customer portal can use an established service. What matters to us is that the component has a clear purpose and a defined boundary.

We work on new products and self-contained new components. We do not take over existing implementations. For a connected component, we first agree what information crosses the boundary, which system owns it, and who is responsible when either side changes.

05 / Building products

Bring the problem, not a perfect specification.

You do not need to arrive with every screen mapped out. Bring an example of the work people do today, where it becomes difficult, and what a better outcome would look like. The uncomfortable details are useful: exceptions, workarounds, and decisions currently living in somebody’s head.

From there, we can define the first complete journey and the systems it needs. That is a better basis for a scope and price than counting screens alone. You are investing in a working product around your business, so the proposal should explain that product clearly.

How we scope and price projects

Inside FlowField3 min read

A website you move through, not just down.

Why we built FlowField as a connected canvas, and the decisions that keep it a website people can actually use.

22 Sept 2026 Read article

All articles

Svelte Flow

Let’s talk