How to scope a digital product for an industry that doesn't have one yet

Most digital products get scoped with a reference close at hand. Build something like Spotify, but for podcasters. A community platform, like that competitor. Those comparisons are useful. They anchor feature decisions, give you a sensible timeline, and make the budget conversation honest.

But what happens when that reference doesn't exist? When a client wants to build something in an industry that has never had a digital product, or where the entire process lives in spreadsheets and paper forms that haven't changed in a decade? That is a fundamentally different starting point, and it requires a fundamentally different approach to scoping.

At Livewall, we work in that territory regularly. Platforms for sectors that have never had a digital product. Web applications that replace workflows nobody has touched in years. These projects are not harder than others, but they demand a different way of thinking about scope.

Start with behaviour, not features

The classic mistake when scoping a product with no reference is jumping straight to a feature list. What does the system need to do? What does user A need, and user B? What do we want in phase two?

The problem is that you cannot answer those questions well without understanding how people work now. Not how they say they work, because that is almost never accurate. How they actually work.

So we start with observation. Interviews, walkthroughs of current processes, questions until we understand the real operation. Only then can we judge which parts of that process become better when digitised, and which parts do not.

When building the Zorg van de Zaak platform, there was no comparable B2B product on the market. We started by mapping how employers and case managers actually communicated, where information got stuck, and where the real bottlenecks were. That determined the scope, not a market analysis.

Make the scope small enough to be wrong

When there is no reference, the temptation is to put everything in version one. Because you do not know what you are missing, you try to cover it all. That is exactly the wrong response.

A product without a reference has a higher chance of containing a wrong assumption than a product in an established market. That is precisely why the first version needs to be small. Small enough to discard if it does not work, without having burned through an entire budget.

Our approach is rapid prototyping: building something that works, but deliberately limited. Not to cut costs, but to learn. A prototype that has actually run with real users tells you more than a hundred interviews.

For Lefboom, there was no existing market for a sustainability rewards platform in the Netherlands. We built an MVP narrow enough to test quickly, discovered what users actually cared about, and built from there.

Flip the question: what is the smallest thing that is genuinely useful?

With products that have no reference, it helps to invert the scoping question. Instead of: what does this product need to do? Ask: what is the smallest thing that would be genuinely useful to someone?

That question forces choices. You cannot keep everything in scope once you are honest about the difference between useful and wished-for.

MVP development at Livewall is not a cost-cutting measure. It is a strategic tool for producing the first working proof before committing to a large investment. In an industry without a digital precedent, that is not risk management, it is just sensible building.

For Sportvisunie, a digital community for sport fishers was something that had never existed. We started with the core problem: members who had no connection to the organisation. Everything we built followed from that one problem. The rest came later.

How to handle stakeholders who want everything

One of the practical challenges with products that have no reference is that stakeholders often have no calibration for what is realistic. Without a comparable, every feature request carries equal weight. There is no market to tell you what is baseline functionality and what is nice-to-have.

Our approach: we work in week goals. Not quarterly roadmaps, no large backlog that creates the illusion of control. Each week a concrete goal, a working deliverable, and a conversation about what it revealed.

That rhythm forces prioritisation. When everything has to fit into a single week, you naturally pick what matters. And when it does not fit, that becomes an honest conversation about priority, not a technical debate about capacity.

This is also what digital strategy looks like in practice at Livewall: not a document you write once, but a living process of making choices based on what you learn.

When AI helps with products that have no reference

An industry without a digital product almost always also lacks clean data. Processes live in people's heads, in scattered files, in email chains. That makes digitalisation more complex, but it also makes AI genuinely interesting as part of the solution.

Where traditional systems demand clean input, AI can help make unstructured information workable. Our sister label Mach8, which specialises in AI automation and intelligent workflows, often collaborates with us on products where the data itself is part of the problem.

The KLM Scalable Growth case shows how an AI-driven workflow can take over a process that was previously manual, scattered, and time-intensive. No reference product, but a clear problem. And that is always enough to start.

For InShared, the same applied: a visual platform for on-brand imagery in a category that did not exist yet. We worked from the problem toward the solution, not from an existing product to a better version of it.

Scope is not a document, it is an agreement

The biggest misconception about scoping is that it is something you do once. You write a document, sign it, and then execute it. In a market with good precedent, that is already a risk. In a market without a reference, it is genuinely dangerous.

Scope is a living agreement about what you are building now and why. It changes as you learn. And in new markets, you learn a lot, quickly.

At Livewall, we build products with web application development as the backbone, but the real value sits in how we take the first step. Small, fast, honest about what we do not yet know. That is the only thing that works when there is no map for the territory you are entering.

For Dumpert, rebuilding a video streaming app from the ground up meant starting without assuming any of the old architecture was right. We treated the scope as something to discover, not something to define in advance. The product that shipped was better for it.