And how you can learn from them
From the series "the most common mistakes" in the app business, today it's the turn of the corporates, i.e. large, often internationally active companies with several thousand employees. First things first: corporates are not speedboats, but tankers. And once a tanker is underway, it stays on course. A quick left or right turn is generally not possible. This results in challenges, especially in the extremely fast and agile app world.
Here are my top 5 most common mistakes made by corporates in the context of the app business 💼🏢👓
1. "The app must meet all our internal requirements."
It often works like this: as part of the "digitalization initiative", the digital team is tasked with developing an app or replacing an old one. As is usual, there are a large number of interest groups, guidelines, legacy systems, targets and process specifications with which the digital team has to juggle. The aim is then to develop a concept that a) has a chance of being approved and b) satisfies the boss, division manager or board member. Where is the error?
Although the concept fulfills the internal requirements, it completely ignores the customers. After all, the project owner conducts his annual meeting with his boss and not with the app users. I have seen many a product owner on the verge of despair because of this dilemma. My recommendation is to first give the digital team maximum freedom and only check the concept for compliance with cross-company guidelines afterwards and not the other way around. Otherwise, there is a risk that good ideas will be nipped in the bud.
2. "The app must be better than that of our competitors."
Ok, logical. But what if the competitors' apps are really bad? Is "better" enough then? I don't think so, because sooner or later a speedboat will come along and overtake all the tankers. Most corporates are risk-averse and tend to defend their market rather than expand it. This is understandable in view of shareholder pressure, but it is not conducive to app development.
My recommendation is not to look at the competition, but at leading apps in other categories. There are numerous best practices here, for example for onboarding or for engagement and retention, from which you can learn. Unfortunately, many large companies do this too rarely. German engineers in particular tend to look at things from the technical side rather than the customer side, which leads to apps that are too cerebral and not very user-friendly. Do you play to win or not to lose? The answer to this question makes a big difference in how you approach your app project.
3. "We put out a tender and look for an IT service provider to implement our concept."
Large IT service providers are tankers that operate for even larger tankers and therefore do not necessarily make the project faster and better. The requirements are usually defined very precisely in the tender. The result is that the IT service provider no longer thinks, but implements what is specified. This is simpler, more efficient with a given budget and, above all, less risky. Because with good ideas, he would possibly risk being excluded from the process. So it's better to implement 1 to 1 what is desired and not question anything. I'm sure you know apps that have been developed (not designed) following tenders with huge amounts of state funding and where the result is really sobering. My recommendation: Look for the small, the hungry, the creative ones in the concept phase before the tender criteria are formulated in such a way that only the tankers are able to participate and "work through" the criteria.
4. "We commission an agency to carry out user surveys, then we are on the safe side."
If Apple had asked its Mac users what they wanted, nobody would have answered "a smartphone without buttons". However, Apple is not a big fan of user surveys and instead lets its own employees do the thinking. The great danger of user surveys is that employees "hide" behind the survey results due to a lack of creativity.
User tests - ideally in a test environment that is as close to reality as possible - are definitely useful for validating aspects of app usage and hypotheses as early as possible. However, the translation of these observations into the product can only come from experts who can assess the opportunities as well as the risks and costs. In my experience, innovation tends to come from individuals who have the ability to see things that others don't - be it while sleeping, in brainstorming or when observing a usability test.
5. "The app team reports to the divisional board and the board decides."
This is perfectly fine under one premise: the divisional director must have relevant experience in the app business. If he does not, he cannot assess the consequences of his decisions and runs the risk of unwittingly jeopardizing the project. How great this risk is, in turn, depends on the corporate culture. Is open feedback rewarded or rather punished? Does "fail fast and learn" apply or are mistakes sanctioned? And what freedom do the individual team members have? My recommendation is to either "interpose" someone who has the relevant wealth of experience and the standing to put their cards on the table for the division manager, or to ensure that the responsibility lies with someone who can do justice to it professionally. Unfortunately, this is often not the case.
So that was my last post in the series "The most typical mistakes".
Whether you're a startup, SME or corporate - I hope my tips were helpful for you or at least gave you something to think about.
See you next week,
Tom
PS: If you like my blog, please recommend it to someone who might find it useful, too.