Ayende @ Rahien

My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:


+972 52-548-6969

, @ Q c

Posts: 6,026 | Comments: 44,842

filter by tags archive

Being a product owner

time to read 1 min | 133 words

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:


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.


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

Welcome to our life :)

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

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

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



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.


Paul Hatcher


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

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



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

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

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.

Comment preview

Comments have been closed on this topic.


No future posts left, oh my!


  1. Technical observations from my wife (3):
    13 Nov 2015 - Production issues
  2. Production postmortem (13):
    13 Nov 2015 - The case of the “it is slow on that machine (only)”
  3. Speaking (5):
    09 Nov 2015 - Community talk in Kiev, Ukraine–What does it take to be a good developer
  4. Find the bug (5):
    11 Sep 2015 - The concurrent memory buster
  5. Buffer allocation strategies (3):
    09 Sep 2015 - Bad usage patterns
View all series


Main feed Feed Stats
Comments feed   Comments Feed Stats