Decisive Product Owner

Dear Junior

In the list of characteristics of a good product owner, we have this far discussing those in informal situations - being engaged and involved. However, product ownership is also a lot about making decisions, and then I like the product owner to be decisive.

Engaged Involved

Decisive Empowered

System development is a lot about making decisions. Even when we write code (and perhaps especially then) we make hundreds and thousands of micro-decisions. Some of them have mainly technical implications (make this design one class or two), but some of them form enterprise logic (what fields should I use when computing this if-conditional).

Sometimes these decisions grow a little bit larger, and we want to ask someone about what we should do. For example we might be writing a batch-file reader and wonder how we should handle if someone sends in the same file twice. Perhaps we consider saving some kind of file ID and a content hash to detect that situation. This might take a day or so to implement so most probably we will bring that up during the daily standup. 

That standup is when the product owner can step in and make a huge difference. Of course the PO needs to be there (involved) and needs to care (engaged), but if she is she might make a huge difference by saying: 

"Hold that thought. To me that seems like a separate story (Avoid duplicate file read). It is good enough if you implement this without that feature. if same file is sent twice, and we read it twice - then so be it. I make it new story and bring it up with the stakeholders."

Viola, within one minute the product owner have saved the team one day of coding, just by being decisive. 

Product owner need also be able to take decisions at point blanc, even when there might not be enough information. 

Team member: "I wonder, what shall we do about social security numbers for people with protected identity"

Product owner: "I do not know whether we have a case for supporting protected SSNs - need to check that up. Ignore that feature for now, if necessary I will add that as a new feature later."

This is just a few minute conversation, yet it saves the team hours of work by not loosing tempo.

Being decisive rules out product owners that "just want to investigate a little bit further before saying anything definitive" - such behaviour leaves the team floundering on what to do, whether they can proceed on the assumption or if they should wait.

Being decisive is a characteristic in a personal context, as is engaged. However it is more about making decisions rather than informal situations - so in that respect it is more related to being empowered.

Engaged Involved

Decisive Empowered

Nevertheless, having a decisive product owner makes things so much easier to keep things rolling.

Yours

   Dan

Involved Product Owner

Dear Junior

Let us continue the discussion about four characteristics of a good product owner. Having an engaged product owner is very well, but it does not really help much if she is not involved.

Engaged   Involved

Decisive   Empowered

Being involved is basically spending time with the team. I want the product owner to show up at daily stand-ups, and to be available for questions and discussions. Without being involved, the engagement does not lead anywhere - like "that is a really interesting and important point; we really need to discuss this, but unfortunately I am extremely short of time  - can we set up a meeting next week?". Few things stops up development more that not being able to put forward those important questions and have those discussions.

Being an involved product owner is much about discussions and other informal situations - much like being engaged also is. However, where "engaged" is an attribute of the person, I would say that "involved" is an attribute of the organisation: does the (rest of the) organisation let the product owner to be involved or does it expect her to be elsewhere?

Having the product owner being involved rules out product owners that have lots of other important stuff to do, and being product owner will have to take whatever time that "is left" (obviously seldom more that extremely little). Product ownership is nothing that can be handled "on the side, with left hand".

One striking example is the Head of Marketing, who was the product owner of a web sales system. However, that person had so much to do with campaigns and strategy planning he did not even have time to come to the bi-weekly demos. 

It is not uncommon to hear this kind of situation "solved" by a Proxy Product Owner.  The proxy will fulfill the "involved" part while the Real Product Owner is elsewhere doing more important stuff. I do not think this is a good solution.

The Proxy Product Owner does give the team someone to talk to and discuss with on a daily basis, the problem is that that person seldom hold authority to take decisions - and if they do those decisions often need to be ratified by the Real Product Owner. In the two-times-two-matrix, it is rather a problem about being empowered - so let me return to the Proxy Product Owner in a later letter.

Engaged   Involved

Decisive   Empowered

Being involved is an attribute that applies to informal situations, like being engaged. In contrast to "engaged" it is however not so much about the person per se, but rather about the surrounding organisation. In that respect "invloved" is more akin to "empowered", with the distinction that the latter is more about formal decisions.

Still, having the product owner involved in the daily work is crucial for success.

Yours

   Dan

Engaged Product Owner

Dear Junior

One of the things I appreciate with people I work with are that they are engaged, and a good product owner is no exception to this. Thus, in the list of four characteristics of a good product owner, I would like to start with that one.

Engaged   Involved

Decisive   Empowered

With "engaged" I basically mean that the product owner should care about the product that we are working on together. This manifests itself as the product owner wanting to participate. 

For example, there might be a problem with some story that is under development - border cases might be unclear or we have unveiled an alternative flows that we did not foresee. In that case, the product owner should consider it important to discuss those to help the development move forward without stopping. Or, if there is a business concept a developer do not understand, the product owner should want to explain it.

Further than that, the product owner is not just reactive. The engagement is also proactive. As an example, there might be a story on the backlog that the development team has deemed too big or unclear to start developing. The product owner should then consider that important enough to work with stakeholders and developers to re-phrase that story in a way that makes it more feasible for development, e g by delimiting it or splitting it.

Being engaged rules out product owners that became product owner "because someone had to be" or - even worse - where ordered to take that position, perhaps against their wish. Such a person will have no particular interest in the system, how it is used, or how it should evolve.

So being engaged is mostly about informal situations - like being involved - not about formal decisions. And it is also an attribute in a personal context - like being decisive - not about what the surrounding organisation lets you.

Having an engaged product owner is crucial for sustained success in development.  

Yours

   Dan

Four Characteristics of a Good Product Owner

Dear Junior


A good product owner is hard to find — but it is well worth the effort. Once a development team start becoming agile it does not take long before the quality of the product-ownership becomes one of the most significant factors for the  productivity of the team. A good product owner works with the rest of the team to gain and uphold a high velocity. A bad product owner can slow the team down to close to a grinding halt.

I have seen several organisations that have attempted to establish a product owner role, where some attempts have succeeded and others have failed miserably. I have tried to find some way to characterise the product owners of these organisations where I have seen success. Finally I have boiled it down to four characteristics that are to some degree linked to each other.

The product owner I have come to appreciate can be summed up by being engaged, involved, decisive, and empowered.

Engaged   Involved

Decisive    Empowered

Of course, each word here have a multitude of interpretations so some explanation is needed to clarify what  I mean. I will elaborate each of them in subsequent letters, but right now I just want to try to convey the larger picture to you.

Context - Person and Organisation


One thing I find interesting with this list of four characteristics is that it contains attributes of the person being product owner as well as the organisation surrounding that person. On one hand side, being engaged and decisive are personal attributes — they come from the "inside".

Engaged   Involved

Decisive    Empowered

On the other hand being involved and empowered are attributes given by the surrounding organisation, it can let you be involved or being empowered, or it can stop you from doing so — they come from the organisation environment.

Engaged   Involved

Decisive    Empowered

So, the verticals in the matrix is about the context — personal or organisational.

Situation - Informal or Formal


In a similar manner the attributes describe how the product owner acts in different kinds of situations.  Being engaged and involved are about informal situations — day to day discussions, coming to daily stand-ups , etc. 

Engaged   Involved

Decisive    Empowered

On the other hand we have decisive and empowered. These are attributes that talk about formal situations — when there is a decision to make. The decisions are small as well as large. A small decision can be to scope a story during sprint, a large decision to say: "let's release". Disregarding small or large, those decisions are important.

Engaged   Involved

Decisive    Empowered

So, the horizontals in the matrix is about situation — informal or formal.

I definitely want to dive into each of these characteristics, but that will wait for another day.

To sum up this observation: I think this cross-section of personal-vs-organisational context and informal-vs-formal situations neatly catches most of the really important parts of what a good product owner is like, and what behaviour it leads to.

Yours

  Dan

Multicore, Power, and Performance

Dear Junior

Next time your data centre upgrade, you will of course get better performance out of your deployed systems. However, as there are several kinds of performance it can be interesting to think about what will happen to response time and capacity. Chances are capacity will improve, but response time might decline. The reason is spelled multicore.


In ancient days of yore, long gone, processors improved by running on higher clock frequency. Higher frequency made them able to process more stuff per unit of time. New processor meant higher frequency and thus better response time. If high capacity was needed, it was achieved by the processor thread-switching between several requests serving them all within reasonable response time.


Those days are gone. Nowadays high-speed processors are no longer in demand. The reason for this is power consumption. The power-consumption of a processor is roughly proportional to the frequency, squared. So for thrice the speed, you pay nine times the power. 


Slower Saves Power


There are of course several problems with high power consumption such as electricity bills and environmental issues. However, the driving force is cooling. Every single Joule that is fed into a processor in a data hall is transformed to heat. That heat needs to be transported out of the hall by the cooling system - and that is the limiting factor.


In other words — if you populate your data centre with high-speed processors you will hit cooling capacity at one point. However, if you use low-speed processors (frequency third of the high-speed), you can stuff in nine times more in the same data centre. So, nine times more, each giving a third of the MIPS compared to high-speed processor. Still you get three times more MIPS out of the same hall - good economy. 


Of course, the modern way of doing it is not to build several processors, but to stuff multiple cores onto the same chip — i e multicore. Still, the driver is the same - you get more MIPS out of you data centre by lots of low-frequency cores that out of substantially fewer high-frequency cores. 


This is not just theory. Several of the large web-sites of the world use new keys like MIPS/W or MIPS/m3 when benchmarking their data centres.


Actually, the same goes for laptops where heat must be limited to prevent user burns. There two slower cores on the same chip can give higher computational power and still radiate a lot less heat.


Better Capacity and Worse Response Time


Getting back to response time and capacity — how are these affected? Well, the data centre upgrade might consists of pulling out old single-core processors and replace them with quad-core processors with 20% lower frequency. Power consumption goes down, making it possible to stuff more processor into the same space. 


Looking at the data centre from the perspective of all clients we serve, or all transactions we process — we get a dramatic increase in capacity. However, from the perspective of a single request or transaction we experience a slower processor — so response time or latency will get worse.


Where processors and data centres earlier where sports cars getting faster and faster, they now rather resembles school busses that do not run nearly as fast but can carry a lot of people at the same time.


Of course this will affect the non-functional attributes of our systems running on these data centres. Unfortunately, the effect is not that straight-forward, but I am pretty sure we are slowly running into trouble and need to do something about it.


Yours


   Dan


ps This is one of the reasons it is important to keep apart response time and capacity, instead of stuffing them both under "performance".