How do you position a product that can become many different things?

I’ve been struggling with how to explain the product we’re building.

Holacrafts is intentionally flexible. You can use it for a client, a project, a deal, company records, personal documents, tasks - or build something completely different.

We’ve actually gone through several different ways of trying to explain it.

First, we led with ownership.

Your work is yours. Holacrafts is local-first, your content is encrypted, and you don’t have to build your working life on top of a stack of rented tools you don’t control.

I still believe strongly in that idea. But we ran into an interesting problem: ownership and privacy are things almost everyone says they want, but they aren’t necessarily the reason people switch products.

Privacy can make a good product more compelling. It doesn’t automatically make someone want the product in the first place.

Then we tried security.

Your sensitive information doesn’t need to be scattered across different services. You control access. Your data stays encrypted.

Important, yes. But again, it explains why Holacrafts might be a safer place to work - not really what you would do with it.

Then we leaned into flexibility.

Documents, communication, workflows, collaboration, different kinds of Spaces and templates.

That was accurate too. But the more possibilities we listed, the harder the product became to explain.

Which is a strange problem to have: the flexibility that makes the product useful also makes it harder to position.

So now we’re experimenting with something much simpler:

The Page is the core primitive.

You create a structured Page around what you’re working on - a client, project, deal, company, personal records, or something entirely your own.

Information, documents, tasks and discussions can then live around that Page instead of the context being spread across separate tools.

That leaves us with two very different ways to position the same product:

Use cases:
“Use Holacrafts for clients, deals, company records, personal documents…”

Core concept:
“Build Pages around your work.”

I’m increasingly leaning toward the second.

Ownership, privacy, security and flexibility still matter - but perhaps they’re reasons to trust and choose the product, rather than the first thing that explains why you need it.

Curious how other founders with flexible products have handled this:

Did you lead with the problem/use case, or teach users one core product concept and let the use cases follow?