Ayende @ Rahien

It's a girl

Being a product owner

A while ago I have come to the realization that it is impossible for me to everything alone, so I got other people to help me build my projects. In some cases, that was done using OSS, by soliciting contribution from the community. In others, it is a simple commercial transaction, where I give someone money for code.

I think that I have gotten too used to the OSS model, because I got the following reply for this:

image

That was somewhat of a rude shock, I was using the same loose language that I always hated when I got specs to implement.

Those are all really good questions.

Comments

Richard Slater
09/07/2010 11:09 AM by
Richard Slater

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/

Alex Simkin
09/07/2010 12:13 PM by
Alex Simkin

Welcome to our life :)

The World as I know it
09/07/2010 01:49 PM by
The World as I know it

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

Scott Rudy
09/07/2010 03:22 PM by
Scott Rudy

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.

Steve Py
09/07/2010 10:17 PM by
Steve Py

@ 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.

Nick
09/08/2010 09:16 AM by
Nick

@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

Paul Hatcher
09/08/2010 10:40 PM by
Paul Hatcher

@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.

Steve Py
09/09/2010 04:55 AM by
Steve Py

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. ;)

Nick
09/09/2010 03:53 PM by
Nick

@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!

Michael Brown
09/15/2010 08:52 PM by
Michael Brown

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.

Thomas Andersson
09/16/2010 12:18 PM by
Thomas Andersson

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.

Comments have been closed on this topic.