Everyone is human, I am coming to this realisation owning an OSS project; we can't do everything and sometimes the things we have to do push out the things we enjoy doing.

Also - s/for me to everything/for me to do everything/

Welcome to our life :)

It comes with age ... :) Its shocking how often you find yourself realizing how two faced you were or high and mighty you can be until you are actually wearing those shoes and are like holy cow this is not as easy as I thought it was... I can't even imagine the level that this occurs for world leaders, its got to be exponentially bad...

I guess this depends on your role though. Some comments would be valid to send back to the writer of the business requirements, but others would be more of a implementation decision. Obviously, you are wearing a lot of hats on this project and you need to decide how involved you want to be for these role based decisions.

@ The World:

G. Bush Sr. issued up the requirements: "Invade a country that has oil." It was up to the CIA to flesh out and fabricate the business case. :)

Giving other people vague and incomplete requirements like that is frustrating. I find it frustrating enough just trying to get requirements out of myself. The trouble is that it's easy to lose perspective and see any kind of forward momentum without at least a checklist of features you want to get completed. I think the typical product-owner mentality is they have a picture of what they want in their minds (along with a lot of other pictures) and it takes too long to express in words so you get a subject-line. They'll know it when they see it and if it isn't what they're looking for they'll elaborate on the differences.

@Steve

That's a wonderful description of my product owner - I struggle with trying to explain to him why some effort by him to expand on the image in his head will save time with re-writes later.

His response to my requests for clarity on the requirements is always "But I don't know yet", however when I show him a prototype it always becomes clear that he had a very definite image in his head from the outset.

sigh

@Nick

No he probably didn't have a picture in his head, but once he saw your implementation he knew what he didn't want :-)

I've come across this a lot, most people apart from developers can't envision a system and what it can do until it's there in front of them.

They will happily sign off a specification that once they see it it practice they don't want to use - which is why it's important to get useable prototypes in front of the business as soon as possible.

I think they know, and we need a petition to make it legal to beat it, extort it, or threaten it out of them. :)

"Tell me how the search criteria should work or the iPhone goes to the bottom of the water jug!" We'd definitely get to do mean things to customers because you'd have to figure their first answers would be lies. ;)

@Paul

Yes I know you are right really.

I am trying to move to getting simpler stuff out quickly and in front of the customer in a more iterative agile way.

It takes a big change to push back and say "NO" to too many complex features at the outset though for both the developer and the customer!

I've come to two realizations:

1. The discrepancy between estimate and actuals is inversely proportionate to the number of questions asked for clarification of a spec.

2. It is sometimes easier for one to execute his own vision than it is to fully explain the vision for another to execute.

As you mentioned though, you only have so much time in a day to execute and you can better leverage your time by designing and specifying for another to execute.

I take the XP approach here and just write down, about the same amount of information that Ayende did here, on a user story card. Sometimes a little more to explain the business value. That card represents a promise to the developers who implement it that I'll have a ongoing meaningful conversation to provide them with what information they need to implement it. Since I currently kind of wear both the hat of product owner and technical lead I most of the time can help them with both the what and the how.

This kind of doesn't work that well though when you use a slow/low bandwidth medium for example email and the like. In-real-life conversations is always best.

And yes sometimes it's not clear from the beginning at all what we want and exploration of what can be done is needed. Starting somewhere and seeing what is accomplished for feedback is ok.