In different opportunities IT organisations need to develop internal tools/code to be used for its developers. The reasons for it are a lot of times questionable, like in some cases of creating shared code, but there are moments when they are the right option. With the rise of continuous delivery, deployment automation tools is one of the examples where common tools can be useful for a company.
When that happens, internal teams are often assembled to deal with this problem, and create solutions to be used internally. Unfortunately, these teams seem to suffer from a “too much introspection problem”, and often forget lessons learned about product development when going on their mission.
There is a perception that because something is developed internally and “approved” by the head office (after all, they are putting money on it), other people will be much more receptive and understanding about problems and poor customer service.
Since there are no real paying customers and everyone will have to use the tool at the end (at least we hope for), the need for short product iteration and constant feedback doesn’t seem that necessary, plans are made to architect something that could solve all the problems, just not the one that the users are having.
The problem is that, in reality, market laws operate internally to a company as much as they do in the outside world, and poor over architected solutions that are forced upon users are still not a big hit, even between the organisation’s walls.
For real products (the ones that people pay for), the current solution are lean startup techniques and product teams, and I believe the frame of mind when entering the world of internal development should be the same.
Start with a vision, not a complete solution – Even when the problem is supposed to be known and understood, it usually isn’t as much as we hope. Over-architecting is a problem here as in any other software project and the only way to avoid the plan to fail when facing reality is to start small and validate your idea as you go along. Yes, Im talking about a MVP.
Get out of the building – In this case, your users are probably inside the same building, so there are really no reasons to avoid them. Walk around the floor, find the people that you will help with your product and get them to help defining what needs to be executed from your vision.
Iterate fast, close to the customer – Get your solution out there to be used from the beginning. Sit with your users, help them adopt it and treat feedback appropriately (as in hear it and do something about it).
Use metrics, track adoption and problems – Metrics are there to be used, so why not get them to help understanding how your tool is being used and adopted by your colleagues (or not)?
In summary, despite not having paying users, internal software is also supposed to help somehow, and if it doesn’t, it will be left behind and forgotten, so companies should give it the importance it deserves.