From Project to Product: What We Learned from Our Digital and Branding Projects

Only Real-World Use Tests All Assumptions

When we look back at our projects, one moment keeps coming up: the day everything goes “live”.

On paper, that is the goal. In reality, it is more like the moment when you see for the first time whether your assumptions are actually right. This is exactly where the mindset shifts: from project (handover) to product (relationship).

We learned early on how expensive it is to treat a website or app like a finished piece of work. This is not just about features, but also about impact: visibility, conversion, trust, brand loyalty. The fact that many digital initiatives fail in the long term is not just a gut feeling – one analysis puts the figure at around 70 % , often because the approach remains too “project-like” and evolution fails to happen. Technology.org↗

That’s why our first “secret ingredient” is both banal and difficult to implement: We never plan the launch as a full stop, but as the start of a learning rhythm.

In practice, this means: Even before go-live, we clarify what happens afterwards. Who looks at the numbers? Who collects feedback? Who prioritizes? And how do you even know whether the thing is working?

We like to call this internally the “North Star Check”: Before implementation, you define a single, easy-to-understand value that shows you are creating real value. Not “Feature X is finished”, but “inquiries are increasing”, “applications are becoming more complete”, “users find content faster”. This outcome logic is the small lever that changes everything.

And here comes the second part: We tie this to a clear, steady cadence. No constant frenzy, no endless fine-tuning. Instead, fixed time windows in which you measure, understand, decide and implement – and then observe again. This is how “We have a new website” gradually becomes “We have a digital product that delivers”.

If you’re starting a digital initiative today, one simple question is worth asking: What should be better 90 days after launch – measurably? If you don't have an answer to that, it's very likely that you're planning a project. And not a product.

The product delivers on the brand promise

One of the biggest misconceptions we see in projects: that branding is the “shell” and the digital product is the “function”. In real-world use, they are inseparable.

A brand is a promise. And a website or app is the moment when that promise is put to the test – silently, without a sales pitch, often within a few seconds.

At Blueforte this was particularly visible. The task was not just a new look, but a clear stance: to present complex Data and AI topics in a way that people understand and take seriously. In a context like this, if you deliver a website as a one-off project, it quickly stands still – while thought leadership thrives on movement: new content, new cases, new perspectives.

That's why the real decision wasn't “Which color?”, but: How does the website become a lasting communication product? Technically, this meant an architecture that the team can use in everyday work (e.g. headless CMS), while editorially it meant structuring content so it doesn't have to be reinvented every time.

Our second “secret ingredient” here is a very concrete approach that has proven itself equally well in branding and product work: the Touchpoint thread.

We draw a thread through all the touchpoints that users actually experience: homepage, service pages, case study, contact, newsletter, social posts, PDFs. Then we check: Do we sound the same? Do we feel the same? Are decisions consistent down to the details?

And yes – this goes all the way into microcopy. A single button label can be “coolly advisory” or “invitingly supportive”. These nuances are brand. And they are product.

Why this matters so much is also shown by looking at the impact of design culture: design-oriented companies significantly outperformed the S&P 500 over a long period. Design Management Institute via Medium↗

We don't derive a simple formula from this (“more design = more profit”), but a robust observation: When brand and product speak the same language, friction decreases. People understand faster, trust more, and stay longer.

And one more Pola-typical point that is often underestimated: Accessibility and brand impact belong together. Good contrast, clear typography, clean hierarchies – these aren't just WCAG topics, they are also brand qualities. Clarity feels like competence. Accessibility feels like respect.

So when you're planning branding, don't just ask yourself “What does it look like?”, but also: How does it feel in use – and will that still be true in six months?

Clear value beats a long feature list

There is a temptation we almost always feel – on the customer side just as much as on ours: If we are already investing time and budget, then in the end there should be “a lot in it”.

That sounds reasonable. But it is often the beginning of overwhelm.

Because in digital products, there is an uncomfortable truth: A large part of what gets built is later barely used. Depending on the analysis, 64 to 80 % of features are rarely or never used. Roikonen (2025)↗

We have turned this into a very practical lesson: It is not the feature set that decides, but clarity.

At Ureka – for a learning platform that was deliberately designed to be light and playful – this was exactly the central challenge: Content and functions could have expanded endlessly. In the early stages, you quickly notice how quickly “completeness” eats away at your UX goal.

Our third “secret ingredient” is therefore a method that we now use consistently: the Core‑Value Cut.

We do not cut based on “nice to have”, but based on “does it really move users forward”.

The approach is simple and nevertheless effective:

1) For each function, we formulate a hypothesis: What change should occur for the user?

2) We define how we can observe this (analytics or test).

3) We build the smallest possible version that allows learning.

4) We cut it without a guilty conscience if it delivers no value.

That sounds harsh, but it is fair – also toward budget and time. A very tangible example from the product world: A team reduced a planned dashboard from 47 metrics to the few that were actually used. Result: three weeks less development, around €42,000 saved and 40 % higher usage in beta tests. Metapress↗

What we love about it: It is not “less because we cannot be bothered”, but “less because we take it seriously”.

And here comes a point we rarely see in agency copy, but that is particularly important for purpose organizations: Fewer features are often more sustainable. Less complexity means less data load, less maintenance, less energy consumption. Sustainability in digital is not just hosting, but also a culture of decision-making.

So if you are currently accumulating a backlog, try a counter-question: What if we were only allowed to do three things really well? Often, that is when it becomes clear what your product really is – and what was merely project decoration.