I have a client--perhaps business partner is a better term, he generally calls the shots and handles the business side of things but I'm also a member of the business and I'll be supporting the software and getting part of the income--who has, well, "a lot of vision." He set out with an idea of what he wanted to end up with for this website and it's not a bad design by any means, but the product has evolved and he still seems caught in his original expectations of perfection. I don't consider what we've changed to be compromises at all, we've made some huge improvements and made some processes way more automated than was ever imagined back in the days of V1. But now he's trying to apply the same degree of user-input and the same expectations to a completely different system. He's making suggestions that just don't really make sense and aren't necessary with the new workflow.
Anyways, we're still in the early stages of our beta--we haven't gone a full day without something going wrong at some point yet--and he's started focusing on a particular feature that only applies 2% of the time. He's calling it our top priority when, again, we haven't even gone a day without other, more severe problems popping up. But he insists that this 2%-case is much of what's holding up his work, even though he's still managing to get what he's supposedly blocked on done.
He doesn't understand the technical aspects so I try to explain things to him in laymen's terms, but today he emailed me to say that he had actually brought our problem to another developer asking for advice. Aside from the frustration that goes with his priorities being clearly wrong, this is also somewhat embarrassing to me: he went to a developer asking a dumbed-down question and saying I didn't know how to fix it.
How do I explain all this to him, but in a way that won't strain the relationship or provoke him to just start messaging me more and more about irrelevant things while I'm trying to work?
- I know what I'm doing, and he can trust me to design the software in a way that he'll learn to prefer after a couple weeks. Not to mention, he can trust that I'll resolve problems or ask for help on my own, and that I won't (and couldn't possibly) tell him every technical detail about every problem I face in the day, since facing problems is more or less my job description.
- That we should build a working product before we start worrying about the minor intricacies of how it works. Big picture is important, little picture is easy enough to throw in and not make a fuss of, but asking for major UI changes after we have something that mostly works just isn't my priority right now.