Dealing with a Client with Bad Priorities

Question

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?

1. 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.
2. 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.

Answer 1

IMHO I see problems here. And yes, it was a bad thing not cause he addressed issues to another developer, but because he told you that.

Is this a local partner or remote one?

Do you have to make another project as a partner? Can you be a partner in project 1 and do others as a paid contractor?

From technical aspect, you obviously need a good project management software where you can rate tasks by priorities. This way you can mark his silly requests as low priority.

However, the most important aspect is Division of Roles. You have to make it %150 clear: he does the Business side you do the Technical side. You don't interfere to his role, he does not interfere to your. Any of you can suggest things to a role leader, but the role leader has the final work. If you say it's low priority, then it is. If he complains, then he should find another partner. As clear as this.

Do tell him what bad thing he did talking to another developer. Maybe be does not understand that.

As I see, you two have inter-personal communication issues and one person not respecting a Role and boundaries of another partner. Unless you solve this asap, you will have hard time finishing this project.

PS. When I read this, I am glad I don't do partnership with anyone :)

Answer 2

Take your dumbed down version of the problem that you have right now and take it to another manager/marketer/business development person and ask their opinion about the problem. Bring it back to your "partner" so he can have an understanding of the situation...

Seriously though, it sounds like it might be time to either, 1) Move on, or 2) as the other answer says, talk about your roles within the organization, and possibly think about setting up a contractual agreement between the two of you so that your roles in the future are more clear.

I wouldn't want to continue to work with someone that doesn't respect my professional opinion when they have no experience or technical knowledge of the domain.

Answer 3

A few points:

1. I don't think you have your partnership well defined. It certainly doesn't appear that you have anything on paper to attest as to what the partnership is and what it isn't.
2. I don't get the sense that any money has changed hands yet. It is important for you to recognize that your work product is in your existing code. Your * cough * partner is already shopping for solutions with another developer. Does he have the capability of sharing, or even giving, your code to anyone else? The fact that he's involved a second developer, probably without consulting with you first, would be a huge red flag for me.
3. As the others have written, you DO need to define your roles, and both of you need to respect them. But given what's happened already, you might consider an exit strategy AS WELL as how to define those roles.

Answer 4

Whenever possible, you should have a complete and thorough specification of what is being built, including every detail of the user interface and any backend technologies. Many specifications even include method-level detail regarding what each method will do in the implementation.

A thorough specification helps eliminate risk, because it documents exactly what is to be built and how it's to be built. In a flat fee contract, the contractors are absorbing all of the risk, including any risk introduced by ambiguous requirements, because the contractor is paid a flat fee to complete the project, despite the ambiguous definition of the project.

In a situation like yours, it's particular vital to write a complete and thorough specification, because the client is not clear on what they want built. That's a huge warning sign that this could be a major project failure, unless you force a clear definition of the project at the start. You need every little minute detail on paper.

The alternative - which you can spell out to the client - is that if you aren't sure what needs to be built, you need to start multiplying the project cost estimate by a factor of 2 or 3 with the assumption you'll have to rebuild it several times, until the client is happy. Or charge an hourly rate.