What that looks like in a kickoff
We had a company, that wanted an app alongside the new brand presence, and instead of talking about platforms and timelines we first had a closer look together. What is the app supposed to solve? For whom exactly? And does that really need an app? In the end the answer was no, a good website does the job.
That is not a particularly heroic story, which is exactly why I tell it: nobody in the room was smarter than anyone else, the question had simply never been asked, because the app had landed in a presentation at some point and had belonged there ever since. This happens in quite a lot of projects, and because it usually surfaces during the build, by then the timeline, the budget and a few expectations are already hanging off it.
The Nielsen Norman Group has been arguing in the same direction for years, namely that an app pays off mainly when the use case is genuinely mobile and repeated often, and that a well-made website is otherwise the cheaper and more robust route. But there is of course the other case too, where an app is exactly right: in our work on the BVB app the question was never whether it should exist, only what it had to be able to do.
Why we get to ask that at all
I think questions like that are an important part of our job as an agency. We come in from outside and know very little at first, and that is a good thing. Because of it we ask again about things that look long settled, and inside a company nobody does that after a few months, since the decision has become part of the furniture by then.
This is not distrust towards the idea, by the way, and it is certainly not an excuse to build less. An agency that nods at everything in the brief earns more in the short run and ends up delivering a product nobody dares to say is unused. That is why the question sits at the start with us and not in the retrospective.
And it has a pleasant side effect that we now plan for at Silberpuls: once somebody has answered it properly, the decision is argued rather than merely present, and that helps later in every discussion about what belongs in the first version and what can wait for the second.
Especially with AI
With AI I find this pretty relevant, because suddenly a lot is technically possible and you land quickly on questions like: can we build AI in here? Can we automate that? Can we ship this feature? You can ask all of it, and the answer by now is almost always yes.
But before that I would probably ask the annoying question once: do you actually need it? Because an assistant sitting on a page where people are really just looking for a phone number is not progress, it is one more window to click away. Our AI principles therefore do not start with the models, they start with the question of which problem the thing is meant to solve.
The honest part is that here too the answer is often yes, just for something other than planned: the chat window turns into a better search, cleaner data, or a form that fills in half its fields by itself. Nobody afterwards notices that as AI, even though that is exactly where the value sits, and to be honest that is also the part we most enjoy building.
What that means for your next project
When you start a project, write one sentence for every large building block saying which problem it solves and for whom exactly. Everywhere that sentence does not come together, you either have not understood the problem yet or do not need the block, and both are better known before the proposal than in the third sprint.
The second one is less comfortable: ask about the things everybody considers settled. The app, the portal, the login, the second platform for the sales team. In web projects that is often the item carrying the timeline, and when it falls the rest gets better rather than smaller.
And if you are already live, a look at the usage helps more than any discussion. A UX Audit shows pretty quickly which areas are really being used, and it is remarkable how often the most expensive feature in a product is also the loneliest one.
