Why does internal corporate software suck?
I came across this article titled Why does internal corporate software suck?
It laments the sad state of internal software and hypothesizes about why things are the way they are. The author claims that internal software should be every bit as good as our external products.
The problem is no one in life wants anything to be just fine. You want things to be fantastic and you should aim for fantastic.
It's certainly correct that the developers of the internal software are not bad developers, they're not making bad technology decisions and it's not that they don't care.
It seems perhaps that the blame lies with the PMs of this software who do just enough to solve the problem that the internal teams have but doesn't go that extra mile to make the tool fantastic.
This is where the PM comes in – the dev team and PM have a couple of meetings with the business where they discuss a high-level requirement and then break it down into smaller chunks like what kind of access will they need, what users will use the system?
From this, we design a couple of rough wireframes which solves this problem and agree on the MVP. We deliver the MVP for testing in a few weeks time.
The end result software is fine. It does solve the problem, the business can’t argue with that, so they sign it off and it gets released.
It certainly is the PM's responsibility to go out and meet the end users and help the team translate their problems and requirements into a user experience which will solve the problem.
The processes for doing this are well known and honestly, it's drastically easier for internally-facing PMs than it is for externally-facing. If I want to spend time with the end users of my internal applications all I have to do is hit them up on Slack and ask to go down and sit with them. I can spend almost as much time as I want deeply embedded in my end-users workflows. Most external PMs would kill for this level of access to end users.
And I do want to do this. I really do. I have the exact same drive to create elegant applications that the developers and designers. I had it when I was a developer myself and I still have it now. I want the code to be elegant and maintainable, I want the UI to be beautiful and I want the UX to be the smoothest most intuitive thing you ever saw.
So why wouldn't I?
Economics dictate that it often makes the most sense to stop when the end result is "good enough". Why?
The key difference between internal software and external software is proximity to profit.
Let's compare the Uber mobile app with a random inventory app your internal team is working on. Millions of people (I'm inventing this number but it must be at least millions) use the app to give money to Uber every day. Maybe 50 people will use your internal inventory app ever.
Next, let's compare the potential value that Uber can glean from a UX improvement or a new feature to what you can achieve as an internal inventory tool PM.
Uber's net revenue in the first quarter of 2018 was $2.6 billion (I hope I'm understanding that source article correctly). If you spend 3 months designing a UX improvement that bumps revenue by one-hundredth of a percent you're adding $260,000,000 to revenue. The cost/benefit equation is simple. You could put an entire team of people on the problem for a year and that revenue bump would still easily cover their cost.
If you spend the next 3 months optimizing your internal inventory tool then you're just not getting the same benefit for time spent. It doesn't make sense to solve that problem.
The inventory people do still need something they can use to do their jobs at some minimum level so the company doesn't fall over but the upside of optimizing the crap out if it just doesn't exist.
This doesn't mean you have a license to release the worst UX the world has ever seen. It is possible to make software so awkward make people so unhappy in their job that they quit. This will lead to high turnover and demoralized employees. This is bad.
When this doesn't apply
You have to be really careful about bad UX in internal software when the software has the ability to do critical harm. Take deployment tools for example. The potential upside of an internal deployment UI improvement is capped at some point.
But the downside is potentially huge. A confused operator could potentially take down production services at your company, causing outages, irate customers and lost profits.
In summary, internal software is often productized quickly and cheaply because it makes sense for the specific situation that internal tools are in. Sure it sucks in some philosophical way (and it might suck in a practical way for the people in inventory) but you often just can't beat the math.