Comments on: Customer Problem Checklist

By: Robert Brewer

Robert Brewer — Sat, 28 Feb 2009 19:42:52 +0000

That’s also a great checklist for “What makes a good bug ticket”.

By: david

david — Sat, 28 Feb 2009 14:20:50 +0000

Thanks for the comments, Dave.

#2: Sorry for any confusion — I’m talking about the customer’s business need, not mine. Companies don’t buy software, for example, because RSS, Atom, or Semantic Networks are cool; they buy software because they want to do something with it. What they want/need to do — not how they’ll do it — is the business need.

#4: Counting is part of the analysis, but the problem itself has to be quantifiable so that that analysis can later take place. There has to be something there that you and the customer can count, or else it’s all fuzzy, hand-waving stuff.

#5: I think there might be more confusion here — for me, the customer is the one who we expect to fund the project or buy the product. It might be an internal customer (say, the division in your company from whose budget the funding will come), or it might be an external customer. If the customer’s problem isn’t compelling, why would they bother spending money on your project or product?

#6: Yes, I think “summarize” is a good change, and I’ll edit the posting accordingly.

By: Dave Pawson

Dave Pawson — Sat, 28 Feb 2009 09:08:25 +0000

2. I’m suspicious. Customers don’t give a sh.. about business needs? Why should they?
4. Counting is part of the analysis surely? Not the problem definition?
5. Not IMHO. It may be, from the organisational perspective. It may actually
cost the business to solve this one. Still good from the customer perspective?
6. I’d prefer ‘summarize’ to describe. This to retain 1, which is key.

regards DaveP