Years ago, my valued colleague Sven Kösters quitted most proposals on our project’s product by saying “Great idea! We do not do, also.”
(German: “Gute Idee! Machen wir auch nicht …”).

People, who identify themselves via those ideas might be upset by the reply.
But, if You are honest, it is a very effective way to shape a product – from outside.

And, despite we were proceeding in waterfall those days, it meets one of the core agile principles, the art of maximizing work undone.

/basics

In the beginning, there are uncountable possibilities. Once, You decided to leave world of imagination and enter physical world, You will face countless limitations.

The challenge is to carve out “what should be” from “what could be”.

/limited resources

You cannot test every variant possible in time and budget.
You have to decide between those which promise to be most beneficial.

In the end, only results count.
Impact, progress, revenue.

You can fire each bullet only once.
So, decide wisely and aim precisely.

/focus on what really counts

Everything is done on purpose. Most impact is achieved by aligning purpose towards a goal, all contributors can and want to target.

In product development, it is “use”.
In revenue driven organizations (“Business”) it is mainly sales figures like xBIT, market share and so on.
“Shareholder value”, You know.
In public sector it might be something like customer’s satisfaction, cycle time, number of closed cases per FTE or whatsoever.

/reality

When participants are honest with themselves, nobody can really determine what counts in advance.
It is all about assumption, measuring, refinement – trial and error while facing uncertainty.

The environments, I work in, are usually based on an indirect sales model, multi-channeled, multi-national, multi-ethnical, multi-language and split up in several other “multis” like brand, model ranges and so on.

In result, You have no direct access to nothing.
No customer contact, no strategic briefings, no visioning with the board of directors, no insights to the development roadmap and so on.

You end up with Your head in a cloud.
Not that “cloud”, nowadays is meant by accessing resources via the internet.

You stand right in the middle of a fog and desperately try to navigate by using “fixed” points like sun, moon, stars and prominent landmarks.

Proxied everything. You need to base decisions upon multi-interpreted data which is aggregated through several discrete layers of “algorithms” that sort out the assumed marginal from the assumed essential.

You can trust this pseudo-reliable “facts” or end up in feelings, individual experiences or just what is random at Your hand and in Your attention in moment of decision.

Nobody can really tell about relevance by that. Because, nobody of these people You interact with, is directly, instantly or sustainably affected of impact experienced in following the decision.
Personal experience and “instinct” is the last thing You can rely on.
Pretty messy situation.

/Product Owner’s Bet

In the end, someone needs to decide to proceed developing a product.
It is the Product Owner who is responsible for that decision.

/the Business Value

To proceed under this massive uncertainty, in agile development using frameworks like Scrum or approaches like Kanban You collect work “to do” into a backlog.

Then this (product) backlog items (PBIs) are prioritized from PO’s perspective using the Business Value parameter.
First things first. The more Business Value can be delivered the better.

As soon a PBI meets the “Definition of Ready” (DoR) it is ready for implementation.

/help is at Your hand

But, the pitiable PO does not need to prepare and decide about estimation of the Business Value all alone.

She or he can ask for help at least at all these proxy-representatives at hand.
By interacting with the stakeholders and (or hopefully in!) the Development Team, the PO can get an idea about what could be of most impact and therefore of most relevance to the product.

But beware of a common anti-pattern: Do not ask them one after the other.
You will end up playing the “telephone game” aka “Chinese whispers“.

You need to ask them at once, so that every expressed aspect can be replied from another perspective, instantly. Complexity!

/estimation meetings

In frameworks based on Scrum, You can formalize this in pre-implementation meetings, called “Backlog Grooming” in former days, “Backlog Refinement” in the Scrum Guide or “Estimation Meetings” in the most prominent client environment I work in.

But be clear on this. In the end, it is nothing more than an “educated guess” ex ante.
Sad, but true.

/conclusion

Being a Product Owner is a very hard job.

You face massive uncertainty on one side and face a development team that expects comprehensive certainty about what to do on the other side.

It is the personal challenge of the Product Owner how to deal with it.
You can make “them” believe in Your assumptions that “they” accept them as facts.
You can play openly and express what You know, what You do not know and on what assumptions to act on.

In the end, only results count. Does it pay off?

/etc

Funny, but it seems that nobody defined “#PO_bet” @twitter, yet.

Search engines will not deliver prominent results for “Product Owner’s Bet”, also.

/famous last words

Life runs in circles. Some are smaller, some are bigger.
In the end, there is no end – only another beginning.

Talk to whom it might concern and share what matters to You.
Sharing is Caring.