A while back when I was discussing a project with a potential client, I was amazed at how little willingness to invest into analysis and design there was. Instead of trying to understand the underlying problem space and projecting what would have to happen in near and mid-term future, the client wanted an immediate solution recipe – something that simply would fix it for now.
What had happened?
I acted like a product developer – the client acted like an IT organization
This made me wonder about the characteristic differences between developing a product and solving problems in an IT organization.
A Question of Attitude
Here’s a little – incomplete – table of attitudes that I find characterize the two mindsets:
| IT Organization | Product Organization |
| Let’s not talk about too much – make decisions! | Let’s think it through once more. |
| The next goal counts. No need to solve problems we do not experience today. | We want to solve the “whole” problem – once and forever. |
| Maintenance and future development is a topic for the next bugdet round. | Let’s try to build something that has defined and limited maintenance needs and can be developed further with little modification. |
| If it works for hundreds, it will certainly work perfectly well for billions. | Prepare for scalability challenges early. |
| We have an ESB? Great let’s use that! | We do not integrate around something else. We are a “middle” to integrate with. |
| There is that SAP /ORCL consultant who claims to know how to do it? Let him pay to solve it! | We need to have the core know-how that helps us plan for the future. |
I have seen these in action more than once. Both points of view are valid and justified: Either you care about keeping something up and running within budget or you care about addressing a problem space for as long and as effectively as possibly. Competing goals.
It gets a little problematic though when applying the one mindset onto the other’s setting. Or, say, if you think you are solving an IT problem but are actually having a product development problem at hand.
For example, a growing IT organization may discover that some initially simple job of maintaining software client installations on workstations reaches a level that procedures to follow have effectively turned into a product – a solution to the problem domain – without anybody noticing nor paying due attention.
The sad truth is that you cannot build a product without some foresight and long lasting mission philosophy. Without growing and cultivating an ever refined “design story” any product development effort will ends up as the stereotypical big ball of mud.
In the case of the potential client of ours, I am not sure how things worked out. Given their attitude I guess they simply ploughed on making only the most obvious decisions – and probably did not get too far.
Conclusion
As an IT organization make sure not to miss when a problem space starts asking for a product development approach – when it will pay off to dedicate resources and planning to beat the day-to-day plumbing effort by securing key field expertise and maintaining a solution with foresight.
z the world 