9
Aligning technical and business requirements
No comments · Posted by Christian in Product development
If you ask a developer what he needs to work you will get a long list of stuff. If you ask a product manager/developer the same question you will get an equally long list of things.
Even if both work on the same product the lists won’t match and not all points will be sensible to achieve.
Developer lists tend to list slow pace and steadiness. Clear todos that can be planned far into the future with a clear vision. Developers like to work concentrated and focussed. Nothing wrong with that.
Product manager lists tend to list speed and reactiveness. The ability to change 180 degrees with no further notice. If an idea was good can only be proven when it’s out and live. If it’s not it needs to be changed. Nothing wrong with that either.
A first reaction to this where I work is that the development team introduced fixed sprint times that as a result lead to fixed deployment times of every two weeks that allow enough time to test everything before putting a change live. We’re fine with that.
The product I’m talking about however is a website that makes money by selling advertising space and its target audience to advertisers. Online marketing in general however doesn’t care about deployment times. When a booking is made it has a date attached when to go live and another when to end. For most standard advertising like skyscrapers and stuff this isn’t a problem.
However the more lucrative deals are custom partner integrations that the ad format needs to be custom made for. This is only one simple example where business requirements contradict technical ones.
Unfortunately the business requirement always wins as there is a price attached to it that is either earned or lost. No one will care for the processes underneath when in that situation.
The more important it is to make this a requirement to the technical platform you use.
In the example above we need the possibility to make changes to the website outside deployment times. Those changes don’t have to be permanent but stable for as long as they last. This can be a defined process or a tool. A technical solution will not cover everything but limit those situations where processes will be overruled.
IT#s important to be clear about the business requirements when working with development in order to produce reliable and sustainable solutions.
