02 — Digital products
Products that spread.
I designed the methods and chose the foundations that let a small team move quickly from a business problem to a working product.
Technology foundation: SharePoint · Power Platform · AWS Serverless
The problem
There were more meaningful business problems to solve than a small team could ever handle one by one.
Across Deutsche Telekom, business teams kept running into problems that mattered — but were often too small to justify a traditional IT project.
If every new problem required a new technology rollout, its own infrastructure and a separate IT project, many of them would simply remain unsolved.
And a small internal team would never scale.
We needed to make meaningful business problems cheap enough to solve — and successful solutions easy enough to reuse and spread.
What I built
I designed the methods and chose the foundations that let a small team move quickly from a business problem to a working product.
We avoided rebuilding the same expensive basics for every new solution.
Instead, we reused:
- infrastructure;
- access and identity;
- security and corporate operation;
- common technical building blocks;
- recurring interaction and workflow patterns;
- a repeatable way of taking a problem from idea to working product.
That meant the team could spend much more of its time on the part that was different every time:
the business problem itself.
Over time, my teams built more than 100 digital products and solutions this way.
What made this possible
We deliberately built on foundations where most of the expensive, repetitive work was already solved.
At first, that meant SharePoint and later Power Platform — an environment already available to employees across Deutsche Telekom.
People already had access. Identity, security and corporate operation were already in place.
A new product did not have to begin with another rollout, another infrastructure project or another set of user accounts.
We could start with the business problem.
As our products became more ambitious, we added AWS Serverless technologies.
The technology became much more flexible, but we kept the same economics: no dedicated servers for every product, very little infrastructure to operate, and almost no fixed cost.
For products serving hundreds or a few thousand people, the underlying cloud infrastructure could still cost only a few dollars per month.
That changed which problems were economically worth solving.
A small team could afford to build a product for a relatively small audience — without turning it into a large IT investment.
How the products spread
Not every product scaled in the same way.
Some scaled through reach.
Our Kanban Board started from a concrete collaboration need and eventually became a Group-wide product chosen by around 100,000 colleagues.
Kanban Board →Others spread through reuse.
The same product could support different organisations, processes or ways of working far beyond the use case it had originally been built for.
The portfolio included products such as:
- OKR Board;
- Learning Journey;
- Magenta Quiz;
- Meeting Manager;
- and many smaller products built around specific business problems.
Products →
Not every one became a large platform.
That was not the point.
A product did not have to become huge to be worth building.
What changed
A handful of people could build once and create value repeatedly across Deutsche Telekom.
One product could reach tens of thousands of colleagues.
Another could solve the same type of problem in several organisations.
And when a genuinely new problem appeared, much of what was needed to turn it into a working product was already there.
The size of the team stopped defining the size of the impact it could create.
Why it worked
We removed as much repeated work as possible from every new product.
We did not want every business problem to arrive with a new infrastructure problem attached to it.
The technology evolved from SharePoint and Power Platform to AWS Serverless.
The principle did not:
reuse the expensive foundations, and spend the team’s effort where it creates value.
That made smaller but meaningful problems worth solving, successful products easier to spread, and the next product cheaper to build than the first.
Evidence
The original material includes working examples from across the portfolio:
- Kanban Board and its application code;
- OKR Board;
- Learning Journey;
- Magenta Quiz;
- Meeting Manager;
- SharePoint and Power Platform applications;
- AWS-based products and prototypes;
- product roadmaps showing how the portfolio developed.
What I would not claim
100+ products does not mean 100+ large or successful products.
The portfolio ranged from prototypes and small internal applications to mature products used across Deutsche Telekom Group.
Adoption, lifespan and business impact varied significantly.
What I can demonstrate is narrower:
we built a repeatable, extremely low-overhead way for a small internal team to solve many meaningful business problems — and some of those solutions spread far beyond the teams they were originally built for.