“We can't impose our will on a system. We can listen to what the system tells us, and discover how its properties and our values can work together to bring forth something much better than could ever be produced by our will alone.”
― Donella H. Meadows, Thinking in Systems
“It is quite a three-pipe problem and I beg that you won't speak to me for fifty minutes.” - Arthur C. Doyle
For some reason, a big chunk of projects I have been involved with as a PO/PM in the recent past was targeted at internal clientele.
That means lots of admin panels, hidden features, easter eggs and the heavy machinery the unenlightened never see.
But it is supposed to be working; otherwise, you might jeopardise deals, other teams, those teams’ members’ mortgages, or even land yourself into a lawsuit if you are not careful with the stuff no one sees.
And as it happens to something we repeat with some frequency, I have compiled a list of things I am trying to cover when building the MVP of a feature requested by the internal stakeholders I happen to work with at that moment.
Every button needs a purpose.
The frequency of interaction defines the size of the investment.
Logs are about the trust you shouldn’t have.
Come up with data schemas and work out the tracking templates yourself.
Refactoring is reasonable and totally squeezable.
Validation guards your sleep at night.
1) Sometimes, I see people overthinking the solutions they can offer. As the internal customer often seems to know what needs to be built, quite often you end up building overpumped matrasses no one sleeps on. There is always an argument to face here - some marketing people, knowing the hard business of getting a space on the backlog of yours, tend to think out myriads of features they might be using (future assumption) just to make sure they have it built to the max so they don’t have to return to you.
Don’t do features.
Figure out the issue at hand and make that pruning with no remorse.
If you don’t overdo the pruning, they might never come back, or you will have a solid case if they do (#4).
2) In a way, this one’s extending the previous idea. Sometimes the stakeholders are so afraid they will miss something so they are requesting a full-blown battleship to cover an area of the pool.
When building an MVP, you can’t really say no like you would with external customers who actually don’t see the whole picture, but you can prune the whole thing down a lot.
When drawing out the concept in Miro (a diagram or a mockup), I try to assess the frequency of use here and there to propose the cheapest solution I might have.
An example scenario - you don’t serve a drop-down with options you might need to build a whole API for, you just stick with an input field one needs to type into.
Yes, there won’t be any validation but given the fact that place X or Y would be used once a month at best, I would build in the cheapest interaction medium I can think of.
Maybe there is a way to prevent its existence at all?
The most used features have to be built with the biggest focus, with almost a holy attention to detail.
Pay your dues to Taylorism here, and make sure to draw a diagram of actions needed to do A or B (again, make sure to assess if the latter needs to be done in the first place; craft the JTBD at scale here).
If the existence is indeed justified, timing things and borrowing ideas from other tools to make it as user-eloquent as possible - that’s the ultimate goal here.
As the tool is internal, you can go wide and deep, stealing ideas from other tools not for the sake of time savings (this one’s solid though), you do this for convenience. The internal clientele tends to use… say, Hubspot or Google Ads and the models of work they have integrated into their routines might help you with the education.
If you mimic the flow and make the product talk for itself in common terms, you are in for a treat. No one will notice the feature you have built which is an ultimate achievement. Remember the tenth law of Rams - ‘Good design as little design as possible’. Don’t go for useless quirks and features, build an almost dull but comparable tooling, something that needs no instructions to start.
If the internal tooling is good, you don’t see it. That’s what we are aiming for.
3) Never trust your customer. Given the internal nature of the module you are building, there is a chance it is going to become a link in a long chain of other modules. Disappearing messages, downtime, timeouts - traces and change history (if there is specific manual human interaction involved) will ensure you know exactly what happened and who did what. Not for the blame game’s sake (I presume some of you would smirk here) but for faster fixes. I see many POs going with no data on the matter until something breaks. They apathetically shrug thereafter.
At times while looking at empty Grafana dashboards.
4) Always think about data collection before you launch anything. The vast majority of internal users are always so ingrained and stale in the usual routine, at times people won’t think twice about something new. You may start having no request to collect data and that’s okay, they will be pleasantly surprised this topic has been covered by you.
It is also the same data for you to assess one feature’s future feasibility (to build or not to build).
I have seen many times when the module went live with no analytics enabled or even planned in advance.
Having the good side of humanity under your wing (developers), make sure to think of the data you would need to improve the feature and analyse its usage. Think of all the edge cases and ways to identify them (the recommendations are bad? Find a way to collect display events and ‘show more’ buttons to see how often those get engaged. Obviously, for every event I’d collect the max amount of signals, keeping some key in mind; there needs to be a key to glue it all together under the umbrella of a session or pin it all to a particular user).
5) If you get to dive into the old codebase, make sure to squeeze in some refactoring into the mix; yes, it is an ungrateful activity no one will appreciate (can’t put a price tag on it) but trust me, if there are modules for you to take over - make sure to study them by reserving times in your sprints over and over again.
Create technical tasks or spikes to ensure you all understand the leftovers you are now responsible for.
Internal features happen to touch the most ancient pieces of the codebase, something no one wants to touch anymore. By doing that, your team will gain some extra creds and become irreplaceable.
6) Last but not least.
Sometimes, with internal tooling, you may avoid some of the backend validation for user input and choices but I’d never skip the frontend validation of every little thing being sent to the backend (unless it is an API you are building, dismiss this then).
Be it an input field, a combination of inputs per language, or an image - make sure to validate the incoming and foresee every edge case out there. The danger of internal tooling is in its invisibility. Everyone uses it (like pricing components or stats calculation jobs) but there is little overwatch dedicated to data accuracy, testing and so on.
By blocking meaningless inputs, you will win a lot of enemies among marketing/sales people along with a couple of new pals on the development side.
A healthy dose of antagonism is acceptable.
But it is not a 3310 in your hand, it is an iPhone, for God’s sake.