Over the years, I’ve heard developers, product managers, QA folks, and marketers justify features using some standard phrases, which sound good, but actually are really poor thinking. I thought it might be useful to chronicle those here. So here’s the top ten list of characteristic phrases used to justify inclusion of a feature, which are often flimsy, worrisome, and downright dangerous. There’s also some guidance for how to deal with each situation. 10. “Wouldn’t it be cool if…” Unless the team’s sense of what is “cool” is really well developed and attuned to actually delivering real value to users, “cool” is a euphemism for “intriguiging to the engineering team, and probably technologically challenging”. Steer clear. 9. “Someone might want to do that…” Sure. And someone might want to go to Mars. How many someones? How often? Will it move the needle of buying decision or product satisfaction? Get data. If it is version 1.0, and therefore harder to get data, you don’t have time for this. 8. “The competition has it”. So? Are people buying or adopting the product because of that? Are they actually using the features? Focus on what people actually do, and making that delightful. Gmail succeeded against Outlook, without duplicating one tenth of the feature set. The first iPhone didn’t have cut and paste. A level playing field doesn’t beat the competition. Does it significantly reinforce your differentiated value proposition? If your team doesn’t know what that is, start there. 7. “I read about this technique”. Re-factoring needs to happen - when it needs to happen. Toolsmithing needs to happen, when it needs to happen. Users don’t care about internals. Usually an obsession with re-tooling indicates a lack of connection with the customer and the purpose of the product. 6. “Management sent a directive”. This is a nightmare, which requires careful therapy. Doing anything because someone else said so is a recipe for really crappy products. You have to understand why in order to make something right. Using the “management trump card” is a sign that people aren’t thinking, and are basically abdicating their decision making to people who are not in the team. You can’t ignore this. Chances are there is some truth to it, that has to be mined and used. Obedience is not great engineering. 5. “So-and-so will be upset if we don’t do it”. Usually used behind closed doors. There is so much implied in this - that so-and-so being upset is a bad thing, that so-and-so is more invested in ownership than progress, that everyone else is afraid of so-and-so. If it is the right call, then get so-and-so into the room, find out why he/she believes what they do, and make the decision together. 4. “It’s interesting”. A dead giveaway. “Interesting” usually means “not germane”. Since we can’t label it as urgent or important, we come up with “interesting”. Repeat after me “interesting” == “distracting”. 3. “We said we would do it”. A toughie. Team integrity (doing what you say you’ll do) is super important. But, not as important as doing the right thing. Hopefully your team is always getting smarter. As the new information and understanding unfold, your decisions can and should change. The thing to factor in here is dependencies. Those who are dependent on your prior commitments are partners, and may be relying on this feature in ways that you don’t understand. If they are internal stakeholders, find out what they are expecting and why it is important, and give them the rationale for the changes. If you’ve made public commitments…why did you make public commitments? 2. “It was supposed to be in the last release”. OK. And it was supposed to be nice weather on Saturday. A high performance team lives in the present tense, not in the past imperfect. Just because you moved it from the version 1.0 bucket to the version 1.5 bucket does not mean that it needs to remain there. 1. “It’s already done”. I hope there are at least a few readers chuckling. I love it when a developer says that something is almost done (or better yet when the product manager parrots the phrase). “Almost” is a hell of a long way from “done”. But more importantly, just because something is “done” doesn’t mean that it is good, appropriate, or important. I’m all in favor of skunkworks, and of developers putting passion into the product, indeed markets have turned based on such things, but the justification for those features getting into the product is that they are good, and right, and important, and will move the needle of user satisfaction, not a historical artifact of amount of sunk cost engineering.
Comments