Concept development

Typical starting situations

• An idea exists, and the first implementation proposal costs more than the undertaking seems worth.
• Several people use the same word and describe different things.
• An undertaking is too large to start and too vague to quote for.
• There are requirements, but no order of priority and no boundaries.

How we work

First what has been lumped together is pulled apart: who is meant to use the result, which problem does it solve for that person, and how will it show that it has been solved. Only then is it time to talk about features.

We turn the requirements into a model of data, roles, states and processes. From that model we define the scope: what belongs in the first viable version, what comes later and what is explicitly excluded. Those boundaries are what distinguish an actionable concept from a wish list.

What can come out of it

Not every engagement covers all of these. What is produced depends on the undertaking and is agreed beforehand.

What matters here

A concept only becomes useful when it also says what does not belong to it. Without that boundary the scope grows during implementation — and it grows at the most expensive point.

Second, a concept has to stay implementable: a design that pays no regard to existing systems, data and responsibilities describes a different company. And third, it should name the assumptions it rests on — they are the first thing to change.

Where this ends

Concept development ends before implementation. Whatever is built afterwards belongs in software development.

If it is still open whether an approach holds up technically at all, research and development comes first. And if it is less about a design than about choosing between paths, technology and business consulting is the field.