How do I handle this difficult client situation?
September 9, 2006 12:16 PM Subscribe
Software product manager: How do I handle this difficult client?
Need advice...
I have quite a few years experience working in product management and marketing roles -- working w/products teams in large companies and startups. I was retained as a contractor several months ago to manage development of an ambitious new educational product for a new company. It's sort of a CTO/lead-product-designer position. The new company had some general ideas what it wanted, but no experience or organized process for building a product from A to Z.
My problem is this: The CEO hired to run the company has very little experience using and developing software products. He comes from a consulting background. Right now there are only the two of us working for the startup, and I'm finding his desire to be involved in micro-decisions concerning product development to be extremely frustrating. Specifically, despite my efforts to document conversations, conclusions, consensus, use cases, and product features, and to begin to establish realistic timelines for completions of features that have been discussed and locked-down, the CEO continues to try to insert himself in the product design and development process -- by soliciting input from stakeholders on his own, and then designing new features in his head, and deciding that those features are extremely high priority and trivial to include in the product. In this quasi-product-design role, the CEO rarely applies much discipline or consistency when evaluating new stakeholder requests. Every new urgent 'nice to have' becomes an essential feature or product requiring urgent meetings and explorations. In and of itself this behavior would be maybe tolerable. The bigger problem is that the CEO's design instincts are so consistently poor, and his recollection of previous discussions concerning priorities and features so inconsistent, I spend most of my time explaining, re-explaining, and defending why we're doing what we're doing. It's really frustrating. I also feel like I'm on shifting sands because his notion of priorities is so out-of-step with nuanced market and user realities AND his overall understanding of the product we're building, the state of the art, design, is so immature.
Recently I told him directly that I felt he should focus on more CEO-like responsibilities (of which there are numerous) and let me do my job -- or find someone else to do my job whose judgement he can better trust. He says he does trust my judgement. Maybe the guy just really enjoys being in the mix.
By all accounts I do my job very well. All parties involved in the product development and stakeholders that will be using the product feel I understand their needs and how to translate them into elegant, highly-usable product.
The CEO is an otherwise good guy, and he seems competent to handle the business side of things. I just want him to stay the hell out of the kitchen when it comes to product design, development, and soliciting feature input from product collaborators. There are already a lot of other 'personalities' involved in this project, and I just feel it doesn't have a chance of success if I can't focus the majority of my energies on moving forward -- not taking a step back, then moving forward, then taking a step back...
After we discussed my comment about his focusing on CEO role more, he asked me to give it more thought and send him an email with suggestions, ideas, ways we could work together so it's less frustrating for me.
I've got some obvious ideas, but any suggestions would be *greatly* appreciated.
Need advice...
I have quite a few years experience working in product management and marketing roles -- working w/products teams in large companies and startups. I was retained as a contractor several months ago to manage development of an ambitious new educational product for a new company. It's sort of a CTO/lead-product-designer position. The new company had some general ideas what it wanted, but no experience or organized process for building a product from A to Z.
My problem is this: The CEO hired to run the company has very little experience using and developing software products. He comes from a consulting background. Right now there are only the two of us working for the startup, and I'm finding his desire to be involved in micro-decisions concerning product development to be extremely frustrating. Specifically, despite my efforts to document conversations, conclusions, consensus, use cases, and product features, and to begin to establish realistic timelines for completions of features that have been discussed and locked-down, the CEO continues to try to insert himself in the product design and development process -- by soliciting input from stakeholders on his own, and then designing new features in his head, and deciding that those features are extremely high priority and trivial to include in the product. In this quasi-product-design role, the CEO rarely applies much discipline or consistency when evaluating new stakeholder requests. Every new urgent 'nice to have' becomes an essential feature or product requiring urgent meetings and explorations. In and of itself this behavior would be maybe tolerable. The bigger problem is that the CEO's design instincts are so consistently poor, and his recollection of previous discussions concerning priorities and features so inconsistent, I spend most of my time explaining, re-explaining, and defending why we're doing what we're doing. It's really frustrating. I also feel like I'm on shifting sands because his notion of priorities is so out-of-step with nuanced market and user realities AND his overall understanding of the product we're building, the state of the art, design, is so immature.
Recently I told him directly that I felt he should focus on more CEO-like responsibilities (of which there are numerous) and let me do my job -- or find someone else to do my job whose judgement he can better trust. He says he does trust my judgement. Maybe the guy just really enjoys being in the mix.
By all accounts I do my job very well. All parties involved in the product development and stakeholders that will be using the product feel I understand their needs and how to translate them into elegant, highly-usable product.
The CEO is an otherwise good guy, and he seems competent to handle the business side of things. I just want him to stay the hell out of the kitchen when it comes to product design, development, and soliciting feature input from product collaborators. There are already a lot of other 'personalities' involved in this project, and I just feel it doesn't have a chance of success if I can't focus the majority of my energies on moving forward -- not taking a step back, then moving forward, then taking a step back...
After we discussed my comment about his focusing on CEO role more, he asked me to give it more thought and send him an email with suggestions, ideas, ways we could work together so it's less frustrating for me.
I've got some obvious ideas, but any suggestions would be *greatly* appreciated.
I second adamrice's advice, especially since it gives the CEO a grasp of the fact that your development capacities aren't unlimited and that he has to prioritize.
Also I have another idea: If he isn't being difficult out of principle or personality, but just likes to get involved, as you stated, why not give him some task to keep him busy? Next time he comes up with an idea in a part of the project that's not really important (think along the lines of the splash screen), support him and tell him this idea is great and make that part of the project his responsibility.
Probably you can think of better examples, I just want to get the general principle across: Manage him and get him out of the way while allowing him to have his desires fulfilled (after all, he's the boss) and to save face.
posted by Herr Fahrstuhl at 12:43 PM on September 9, 2006
Also I have another idea: If he isn't being difficult out of principle or personality, but just likes to get involved, as you stated, why not give him some task to keep him busy? Next time he comes up with an idea in a part of the project that's not really important (think along the lines of the splash screen), support him and tell him this idea is great and make that part of the project his responsibility.
Probably you can think of better examples, I just want to get the general principle across: Manage him and get him out of the way while allowing him to have his desires fulfilled (after all, he's the boss) and to save face.
posted by Herr Fahrstuhl at 12:43 PM on September 9, 2006
I've always worked for fairly small companies and I'm in Product Management too (pure PM -- no marketing role). My CEO is a lot like you've described and I think that some of it is a necessary part of a start up. The fact it, the CEO's vision makes for a successful start up. But he also needs to give you time to run with ideas.
It takes time to write vision docs, requirements, etc. and if your CEO isn't aware of the traditional PM process you follow (whether it's RUP or something else), educate him. Do a brownbag with the CEO and the development team -- this way, everyone is on the same page and everyone will feel good about the time being spent. Also, you can make good tradeoffs about the time being spent writing requirements and the level of detail necessary for those requirements, since you're probably under pressure to turn profitable soon.
If you want to talk about this more, feel free to drop me a note. michellerwnospam at gmailnospam
posted by wildeepdotorg at 12:43 PM on September 9, 2006
It takes time to write vision docs, requirements, etc. and if your CEO isn't aware of the traditional PM process you follow (whether it's RUP or something else), educate him. Do a brownbag with the CEO and the development team -- this way, everyone is on the same page and everyone will feel good about the time being spent. Also, you can make good tradeoffs about the time being spent writing requirements and the level of detail necessary for those requirements, since you're probably under pressure to turn profitable soon.
If you want to talk about this more, feel free to drop me a note. michellerwnospam at gmailnospam
posted by wildeepdotorg at 12:43 PM on September 9, 2006
On second thought, maybe you could even set him up a little pet project that he can concentrate his micromanaging needs on and which will not necessarily have to see the market ever. Anything that keeps him out of the way and doesn't do any harm would seem to be beneficial in your situation.
posted by Herr Fahrstuhl at 12:45 PM on September 9, 2006
posted by Herr Fahrstuhl at 12:45 PM on September 9, 2006
Nice to see other PMs here!
It sounds like you've been handling it pretty well so far. The other advice is all good. The only thing I would add is maybe sending him out to a product management course so he has a better idea of what you're doing. That might help him understand that he needs to keep out. You probably know the usual candidates, but if you don't, send him out to a Pragmatic Marketing course. If Steve is the instructor (about 99% odds), drop Steve a note and explain the situation to him. He'll give your CEO an earful. :)
posted by GuyZero at 12:52 PM on September 9, 2006
It sounds like you've been handling it pretty well so far. The other advice is all good. The only thing I would add is maybe sending him out to a product management course so he has a better idea of what you're doing. That might help him understand that he needs to keep out. You probably know the usual candidates, but if you don't, send him out to a Pragmatic Marketing course. If Steve is the instructor (about 99% odds), drop Steve a note and explain the situation to him. He'll give your CEO an earful. :)
posted by GuyZero at 12:52 PM on September 9, 2006
Also, a classic from HBR that might help: Managing Your Boss.
posted by GuyZero at 12:53 PM on September 9, 2006
posted by GuyZero at 12:53 PM on September 9, 2006
GuyZero, one of my colleagues has been to the Pragmatic course but I haven't yet, although I've been considering it. I've been working in the field for about five years now. Is it worth it? It sounds like it would provide me some new ways to think about things.
posted by wildeepdotorg at 1:15 PM on September 9, 2006
posted by wildeepdotorg at 1:15 PM on September 9, 2006
To non-software people, software is easy and apparent. There is no mystery. Just stick a button there and hook that over there and you're done - right?
'Course, those of us who've done this for years know better. But it's easy to lose track of how it looks to outsiders.
First, I think you need to sympathize with him a bit more. It's his company. This is his major product. He wants to give a lot of input. He's responsible to the shareholders. He has to make sure this thing is just right. It's only natural that he twiddle with things.
The thing you really need to attack is the gap in your understanding of software. He needs to be convinced that requirements, schedules, specifications, and designs are all necessary to the process. They should be respected. As should your technical contributions.
Here are some ways to approach that.
- Make it clear what parts are his and what parts are yours. Draw that line thick and black. Say stuff like, "OK, I've understood your opinion, and I'll do my best to implement it, but I'm reserving the right to change this if the engineering dictates it." Draw up a proposal for his and your authorities and responsibilities if you have to.
- One of the difficulties with software engineering is that it's invisible. The months of work result in indecipherable code. People don't realize that yes, building a large project can require as much painstaking intellectual work as designing a car, a bridge, or a factory. Get him to understand that.
- People respond well to analogy. You wouldn't nitpick a bridge design, or ask to tack on a new wing to a skyscraper, but it's common for people to change pageflow late in a website project.
- Ultimately it's your responsibility to balance the cost and benefits. Defend it. Say stuff like, "We could do that, but I think the cost outweighs the benefit." Make it clear as possible, as often as possible, that you're working in his interest there.
- People respond to authority. Get him to read some of the accessible classics in the field: Mythical Man-Month, Code Complete, Peopleware, Software Requirements. Nonfiction memoirs of software projects go down easy, and usually have pro-project-management subtexts. The Soul of a New Machine, for example, is a classic.
- Visualizations always help. Do a lot of diagrams, to convince him visually that a) you know what you're doing and b) this stuff is complicated.
- Set up processes. Get him to agree that past a certain milestone, the larger requirements will not change. This is a two-way street, though. You have to adhere to process as much as he does. You have to promise you will report on schedule, you will do your damnest to hit your dates, and you will show documented proof of progress.
But, above all, always respect his need to be involved. It's his baby. And his right as CEO. Just make sure he understands the costs of twiddling too much.
posted by maschnitz at 1:51 PM on September 9, 2006
'Course, those of us who've done this for years know better. But it's easy to lose track of how it looks to outsiders.
First, I think you need to sympathize with him a bit more. It's his company. This is his major product. He wants to give a lot of input. He's responsible to the shareholders. He has to make sure this thing is just right. It's only natural that he twiddle with things.
The thing you really need to attack is the gap in your understanding of software. He needs to be convinced that requirements, schedules, specifications, and designs are all necessary to the process. They should be respected. As should your technical contributions.
Here are some ways to approach that.
- Make it clear what parts are his and what parts are yours. Draw that line thick and black. Say stuff like, "OK, I've understood your opinion, and I'll do my best to implement it, but I'm reserving the right to change this if the engineering dictates it." Draw up a proposal for his and your authorities and responsibilities if you have to.
- One of the difficulties with software engineering is that it's invisible. The months of work result in indecipherable code. People don't realize that yes, building a large project can require as much painstaking intellectual work as designing a car, a bridge, or a factory. Get him to understand that.
- People respond well to analogy. You wouldn't nitpick a bridge design, or ask to tack on a new wing to a skyscraper, but it's common for people to change pageflow late in a website project.
- Ultimately it's your responsibility to balance the cost and benefits. Defend it. Say stuff like, "We could do that, but I think the cost outweighs the benefit." Make it clear as possible, as often as possible, that you're working in his interest there.
- People respond to authority. Get him to read some of the accessible classics in the field: Mythical Man-Month, Code Complete, Peopleware, Software Requirements. Nonfiction memoirs of software projects go down easy, and usually have pro-project-management subtexts. The Soul of a New Machine, for example, is a classic.
- Visualizations always help. Do a lot of diagrams, to convince him visually that a) you know what you're doing and b) this stuff is complicated.
- Set up processes. Get him to agree that past a certain milestone, the larger requirements will not change. This is a two-way street, though. You have to adhere to process as much as he does. You have to promise you will report on schedule, you will do your damnest to hit your dates, and you will show documented proof of progress.
But, above all, always respect his need to be involved. It's his baby. And his right as CEO. Just make sure he understands the costs of twiddling too much.
posted by maschnitz at 1:51 PM on September 9, 2006
Do you have an actual product plan/roadmap for this software? Something with planned releases several iterations out? Based on your initial post, I'm not so sure. You seem to be stuck developing your product feature-by-feature, rather than on a true release cycle.
If you haven't done so, put all of your features into a release calendar, projecting fixes/tweaks into point releases and major features into major releases. They key here is to be releasing a group of features at once. That way, when your boss comes to you with his Latest Great Idea, it goes on the calendar. If he wants to argue for it getting done right away, it's a powerful tool to show him the cascading effect of delays it causes. Of course, for minor tweaks, you have the option to "squeeze it in" to the upcoming release, which lets you throw him a bone.
posted by mkultra at 3:11 PM on September 9, 2006
If you haven't done so, put all of your features into a release calendar, projecting fixes/tweaks into point releases and major features into major releases. They key here is to be releasing a group of features at once. That way, when your boss comes to you with his Latest Great Idea, it goes on the calendar. If he wants to argue for it getting done right away, it's a powerful tool to show him the cascading effect of delays it causes. Of course, for minor tweaks, you have the option to "squeeze it in" to the upcoming release, which lets you throw him a bone.
posted by mkultra at 3:11 PM on September 9, 2006
I feel that sentances like "We could do that, but I think the cost outweighs the benefit" and "OK, I've understood your opinion, and I'll do my best to implement it, but I'm reserving the right to change this if the engineering dictates it" might not actually solve your problem. It is really saying "Let's just not talk about it right now, ok?"
posted by idledebonair at 3:31 PM on September 9, 2006
posted by idledebonair at 3:31 PM on September 9, 2006
The CEO didn't train for years to do what pallen123 does. He can't pretend to follow everything. Just as pallen123 can't pretend to follow everything the CEO does. It's specialization. And specialization is critical to growing an organization.
There has to be a line, somewhere, in every organization, where the conversation ends, and the trust begins. These sentences are for those occasions.
posted by maschnitz at 3:36 PM on September 9, 2006
There has to be a line, somewhere, in every organization, where the conversation ends, and the trust begins. These sentences are for those occasions.
posted by maschnitz at 3:36 PM on September 9, 2006
Design creep is an unfortunate element of the business. The only way to stop it dead in its tracks is to have a formal requirements document written up. Take however many meetings, pow-wows, lunches and summer retreats to get that finalized. But once it's final, that's it. No more. And if any idea is broached, no matter how trivial or "easy to implement," just shrug your shoulders, shake your head sadly, and point to the requirements.
posted by Civil_Disobedient at 5:17 PM on September 9, 2006
posted by Civil_Disobedient at 5:17 PM on September 9, 2006
The only way to stop it dead in its tracks is to have a formal requirements document written up
That never works, because you can never truly finalize requirements or design. Someone high enough up can ALWAYS change things at the last second.
posted by flaterik at 6:17 PM on September 9, 2006
That never works, because you can never truly finalize requirements or design. Someone high enough up can ALWAYS change things at the last second.
posted by flaterik at 6:17 PM on September 9, 2006
Sure they can, but if they're a good boss they won't. I just finished writing a banking application from the ground up—our entire team was essentially 5 people. The requirements phase lasted about three months, but it was agreed, and everyone understood, that when the ink dries, there are no more changes. That's it. Because everyone understood this and agreed to it, we were able to release in eight months. Sure, there were plenty of people ("higher-ups") that tried to get features added as we neared completion, and we even placated some of them because we could, but it was always understood that the deadline for release was the most important thing, anything else was just gravy. That's the kind of mentality you need if you ever want your application to see 1.0.
posted by Civil_Disobedient at 9:18 PM on September 9, 2006
posted by Civil_Disobedient at 9:18 PM on September 9, 2006
The formality Product Development can impose varies from business to business. In banking, they're happy for schedules to run 6 to 12 months. It's no big deal to lock requirements 3 months in advance. Other things run much slower. In some Web 2.0 companies, however, it's not clear that requirements ever get locked. Things can change the day of release.
It just depends on how much the business values time to market, and how much it values product stability.
It's the executives' call. But it's Product Development's responsibility to tease that out of them.
posted by maschnitz at 10:57 PM on September 9, 2006
It just depends on how much the business values time to market, and how much it values product stability.
It's the executives' call. But it's Product Development's responsibility to tease that out of them.
posted by maschnitz at 10:57 PM on September 9, 2006
That's one reasonable way to run a project, but it's certainly not the only way. For something that is a banking application, yeah, I can see having a heavy requirements-gathering phase and then just implementing those. But for something that is a project where there's one guy who's the main visionary, and he's changing his mind all the time? That's a classic time to go with Agile development, and it's likely to make both of you less nuts (and the short version of it is exactly what adamrice said above).
posted by inkyz at 11:01 PM on September 9, 2006
posted by inkyz at 11:01 PM on September 9, 2006
Response by poster: Thanks for all the great suggestions. They're all very helpful to consider. At the risk of asking another question, which I don't think I'm allowed to do on this board, can anyone point me to templates, formulas, or scales that they've found helpful in elucidating and prioritizing (for myself, but mainly others) in a more empirical way, the following concepts:
1. relative value of a proposed feature:
value = ease-of-use/importance
2. likelihood of feature use = benefit of use/cost
3. importance of feature = among end users, ranking of importance relative to other needs (addressed by other products or not) -- rank of need according to end users, weighted by end-user priority (1-10)
I'm especially interested in some process tools and also diagrams I can use, and use to show/justify decisions we're making. Ideally the tools/diagrams would also give us a way to map features/strengths of our competitors, and help us explore/plan our own products/features based on whether our products/features address 'open space' being unaddressed or weakly addressed by competition, versus 'direct overlap' in products/features.
To a large extent I rely on experience to pretty consistently make sound decisions which take into account design, usability, market research, overall product vision, and development requirements. Although I document these things at points in time, they are not part of our granular feature by feature evaluation process. So when the CEO sparks up a new 'high priority idea', he doesn't have any such process through which to run the idea.
posted by pallen123 at 5:54 AM on September 10, 2006
1. relative value of a proposed feature:
value = ease-of-use/importance
2. likelihood of feature use = benefit of use/cost
3. importance of feature = among end users, ranking of importance relative to other needs (addressed by other products or not) -- rank of need according to end users, weighted by end-user priority (1-10)
I'm especially interested in some process tools and also diagrams I can use, and use to show/justify decisions we're making. Ideally the tools/diagrams would also give us a way to map features/strengths of our competitors, and help us explore/plan our own products/features based on whether our products/features address 'open space' being unaddressed or weakly addressed by competition, versus 'direct overlap' in products/features.
To a large extent I rely on experience to pretty consistently make sound decisions which take into account design, usability, market research, overall product vision, and development requirements. Although I document these things at points in time, they are not part of our granular feature by feature evaluation process. So when the CEO sparks up a new 'high priority idea', he doesn't have any such process through which to run the idea.
posted by pallen123 at 5:54 AM on September 10, 2006
I think you want to make this stuff transparent. Or as transparent as you can make it.
Non-technical decision makers like to feel in the midst of the technical stuff, even if it is overwhelming to them. If the documentation as detailed as it needs to be, its bulk should give an easy gestalt of the complication involved. Your familiarity with the complexity in front of the client should demonstrate your mastery of the issues.
So, long story short: a simple Excel spreadsheet, or Wiki page, should cut it. Use ordered, numbered lists, a simple 1 to 5 scale for costs and benefits, and maybe a cost-benefit graph. If, for some reason, that's not complicated enough, go one level down in feature granularity. Start talking feature specifics' cost/benefit.
Just having long, accurate tracking lists will be enough. When the CEO breaks out his new high priority idea, just break out your lists with him, and ask him where it drops relative to everything else. It'll show him, simply, that feature selection is a rational process.
Also, it might help to have your own, personal tracking items peeking out from under this high-level tracking summary. If the client starts drilling down, drill down into the nitty gritty documentation with him. This personal tracking is whatever works best for you: detailed requirements lists, screenies, wireframes, use cases, outline-form-requirements, whatever. Just make it clear from the formatting that it's your personal stuff, not a group-editable doc. Flashing this will show there's more work here than is worth a CEO's time.
posted by maschnitz at 2:00 PM on September 10, 2006
Non-technical decision makers like to feel in the midst of the technical stuff, even if it is overwhelming to them. If the documentation as detailed as it needs to be, its bulk should give an easy gestalt of the complication involved. Your familiarity with the complexity in front of the client should demonstrate your mastery of the issues.
So, long story short: a simple Excel spreadsheet, or Wiki page, should cut it. Use ordered, numbered lists, a simple 1 to 5 scale for costs and benefits, and maybe a cost-benefit graph. If, for some reason, that's not complicated enough, go one level down in feature granularity. Start talking feature specifics' cost/benefit.
Just having long, accurate tracking lists will be enough. When the CEO breaks out his new high priority idea, just break out your lists with him, and ask him where it drops relative to everything else. It'll show him, simply, that feature selection is a rational process.
Also, it might help to have your own, personal tracking items peeking out from under this high-level tracking summary. If the client starts drilling down, drill down into the nitty gritty documentation with him. This personal tracking is whatever works best for you: detailed requirements lists, screenies, wireframes, use cases, outline-form-requirements, whatever. Just make it clear from the formatting that it's your personal stuff, not a group-editable doc. Flashing this will show there's more work here than is worth a CEO's time.
posted by maschnitz at 2:00 PM on September 10, 2006
wildeepdotorg, the Pragmatic Marketing course is great. It's certainly the most widely respect training in the field - a number of new PM training companies have popped up over the last few years, but Pragmatic has been around for a long time. Everyone I know who has taken it felt it was quite valueable. If you've worked in the field for five years, it may not all be new to you, but I imagine you'll get something out if it. If nothing else, Steve is a very funny, engaging speaker.
posted by GuyZero at 5:35 AM on September 11, 2006
posted by GuyZero at 5:35 AM on September 11, 2006
inkyz, I would argue that Agile is not a requirements methodology but, rather, a development methodology. I see that you list your profession as "code wrangler" and I see a lot of value in Agile from your side of the table, but there's still no substitute for clearly defined requirements -- whether in use cases or another format -- before beginning of development.
Stories are not requirements. They are "job orders" or larger tasks and product companies ultimately cannot build a body of requirements from stories.
posted by wildeepdotorg at 7:46 AM on September 11, 2006
Stories are not requirements. They are "job orders" or larger tasks and product companies ultimately cannot build a body of requirements from stories.
posted by wildeepdotorg at 7:46 AM on September 11, 2006
This thread is closed to new comments.
Since it would be impolitic (if nothing else) to totally blow him off, maybe you could work out a new-feature proposal system. Every time he gets an idea for a new feature, he writes it down on a card, assigns a priority score to it, assigns a "how well this fits with what we're already doing" score, and leaves blank a spot where you will estimate a "how much of a PITA will this be to implement" score. Tell him he's on a budget of (say) 100 priority-score points per month. At the end of each month, you schedule a meeting, he pulls out all his cards, and then you can hash out his ideas in a more structured format.
Benefit to this is that A) he can't constantly pester you, B) he'll have more time to stew over each idea, and will have to think of those ideas more from your perspective, C) will have to think more about how each flash of inspiration meshes with the others, and D) this process might mean that by the time he gets around to the end-of-month meeting, he's had a chance to refine some of these ideas into ones that are actually helpful.
posted by adamrice at 12:30 PM on September 9, 2006