So you’ve been nagging at your boss for months and he finally gave in: you’ll get this new software project that would (at least, according to your pitch) dramatically simplify and speed up your daily work doing X. You call up your local IT company, brainstorm about the product and sign the contract. The project is a go.
You come to work the next day and have an email with questions waiting for you. “Great”, you think, “the guys are at it”. You scribble a quick reply and go on with your stuff. Only this is not the end of it. In a few hours, there’s another email. And someone poking you in Skype. And the phone rings. All about “Should we do X” and “…but what if Y?”. You start to get a bit annoyed. Who do they think they are? Don’t they know what I want, didn’t I tell them exactly what to do?
This goes on for a few weeks until you can stand it no more and blatantly boycott all attempts to communicate.
The above scenario is exaggerated, but quite true in some cases. The product owner begins a project and is all excited about its coolness, but when the time comes to actually work on it and iterate, the motivation vanishes.
Here’s the thing - the development team could answer their own questions, but you know your business and they don’t. In the end, it’s your product and hence your responsibility to put all the required effort and then some into making sure the project is the best it could be.
The harsh truth is that most projects might seem quite straightforward, but once you dig deep there are a surprising number of complexities and scenarios to solve. Like how exactly the ordering process looks like on each step…. or what happens when the user provided two contact addresses, which takes precedence and when?
Getting what you actually need over what you think you want requires effort from all the stakeholders - including the client. It’s expensive, it’s draining, but you’ll thank each other in a few years when the project is still successfully generating revenue.