This is my story about how we sit alongside our customers as co-drivers at Blis Digital. Not to nod yes and write for hours, but to intervene, challenge and work together for the best result at the right times.
From PRINCE2 to Agile
My career as a project manager started in the era of PRINCE2. One advantage of this method, largely forgotten, is the absolute focus on the business case. The motto: if you're not making money with it, you should quit.
I also liked the clarity about responsibilities: you always know who the budget owner is, who represents users and who should deliver what value.
After that, I experienced the shift to Agile (Scrum). Agile is about creating value quickly and working iteratively towards a good product. Powerful, but certainly not a silver bullet. At large organizations, I saw that teams quickly fell into a biweekly rhythm, without knowing anything else why they actually did.
The pitfall of 'infinite' budgets
In many Agile projects, the budget initially feels like an inexhaustible resource. As a result, iterations are carried out that provide little value afterwards. The sigh “we should have looked at that more critically” is familiar to you then.
Even if the product owner is warned that a certain direction is awkward and the MVP should be prioritized first, there is a tendency to make features just more beautiful, complete or extensive. The result: at the end of the project, when the money is almost empty, much less is suddenly possible than expected.
An underlying problem is that during the process, it is not always clear who exactly owns the budget. In practice, a line manager sometimes suddenly interferes with the outcome, bypassing the product owner. This leads to ambiguity, delays and choices that are no longer in line with the original vision.
Frameworks are sometimes presented as the solution for every project issue. In practice, this is much more nuanced. There is no method that works anytime, anywhere.
What does always work? Common sense.
Your common sense and your MVP
I'm from Goeree-Overflakkee, and that's where “common sense” comes from. Flakkeese farmers are 'economical': they always wonder if something is really necessary and whether the investment is worth it. The same is in my vision for software development. I always ask that one question: why do we actually do this? And the answer must always have to do with value for the user.
After all, that user sees only one thing: what's live today, not what's planned, not what's on the roadmap, not what's “coming soon”. A user wants to be able to work. Point. And he's right: after a “first version”, the budget often runs out or the priority has been moved.
That's why an MVP really needs to be a Minimum Viable Product: not the minimum excuse to go live, but a fully-functioning product that meets the functional requirements as well as the requirements for performance, availability and safety.
You can only get there by daring to delete. Delete a lot. That is difficult, especially with many stakeholders. But that's exactly where common sense comes in: daring to make choices and, above all, dare to leave choices.
The role of the product owner
In theory, this is entirely up to the product owner: he sets priority, manages the backlog, who distributes the budget. But in practice, that is a heavy responsibility for one person. Especially when someone has more or less “bombed to PO” without experience with complex processes.
In addition, the mandate is often missing. Then you officially have a product owner, but in fact, the decision-making authority lies with a line manager or budget holder who intervenes much later in the process.
We have experienced this several times. In one project, we had sharpened the MVP with the PO, including removing features, but during implementation, it turned out that the PO had no internal mandate to make such decisions at all. The result: delay, unrest, extra work.
That is why clear responsibilities and mandate are crucial, but are still far from obvious in many organizations.
The 'co-driver' concept in action
Blis Digital plays an important role in that dynamic. We are not a supplier who executes what is asked, but a co-driver who thinks along, counters and asks the right questions.
Our strength lies in recognizing dead ends, unnecessary complexity and choices that cost too much for too little value. That's why we don't just think about the product, but also about the customer's wallet.
For each requirement, we ask two simple questions:
- Is this really necessary?
- Is this the most efficient solution?
Sometimes something is technically wonderful but practically a bad idea. Then it's better to choose a simple alternative, such as a temporary manual action in the back office, so that end users do get value on time.
That's not skimping, that's common sense.
“Thanks for testing, but we won't fix it”
Even when testing, you should carefully consider what is really important. Our testers can crash almost any application, that's their job, but that doesn't mean that every bug found needs to be fixed automatically. Fixes cost time and money, and always require team attention. Sometimes it's smarter to accept a small risk.
For example, we had a feature where the app crashed when someone tapped a toggle switch extremely quickly. Of course, we were able to fix that, and we did, but afterwards it turned out to be over-engineered. We could have said better: how often does this really happen? And when it happens: a user can restart an app just fine.
So common sense.
Don't fix everything because it's possible, but fix what matters.
Pragmatism in multi-tenant applications
Another example. We work a lot on multi-tenant applications. This involves additional complexity: features have to be rolled out to multiple tenants and integrations often configured per tenant.
From an MVP perspective, you have to be smart about that. Maybe a new feature doesn't have to go directly to every tenant. Perhaps you can temporarily share one API key so that the feature can go live quickly and provide immediate value.
In one project, this pragmatism saved several days of work and, at the customer's express wish, we were able to put the feature live just before Easter instead of weeks later.
That provides an advantage. And that creates value.
Where we make no concessions
Don't confuse this approach with sloppiness. Common sense doesn't mean doing things half way or ignoring technical debts. On the contrary: certain principles are sacred.
Security is one of them. Everything we build meets strict safety requirements, and we don't skimp on that. In addition, we repay technical debt consistently and quickly. Refactoring is prominent on the backlog, precisely because tech debt slows down innovation in the long term and even jeopardizes stability and security.
Our co-driver role also means: setting clear boundaries. When we know that something is harmful to the customer's business, we take the emergency brake.
That is not stubbornness.
That is responsibility.
Zoom out occasionally — and what it means to be “AI-first”
Blis Digital is not a secondment company and not an 'hour factory'. Now that we're working AI-first, that only becomes clearer. Hours are becoming less relevant because AI takes over a lot of executive work and we can fully focus on the role that makes the difference: that of co-driver.
In fixed-price projects, we share the budget risk with the client. That makes responsibility clear: if we allow the wrong choices, it costs us all time and money. That is why influence on strategy, backlog, quality and decisions is not a luxury, but a necessity.
We summarize this in two words: Down white.
Not “their project”, but “our project”.
That means: being well prepared. Fulfill appointments. Get help on time. Honestly indicate when something is not feasible. And constantly looking for ways to work faster and smarter. Of course, AI is part of that.
And that's common sense too: zoom out from time to time and honestly see if you're still doing the right things, in the right way.
Cup of coffee?
Curious about what “common sense” can mean for your project? Let's have a chat about your challenge and see where it can be done smarter, easier or faster. Send me a message (a.vandervelde@blisdigital.com) and we'll have a cup of coffee soon.
