Best Product Owner is User Who Know What They Need

In the most ideal case, a best software product is the one who programmer build for himself. Because in this case, the programmer is also the user. Product like this will deliver the best business value because the programmer will not bother to create anything that they do not need.

In the real life environment, I always hear complain from the team about their product owner. The team were expecting a product backlog with enough detail of user story and prioritize properly so they could start the conversation.

A really good product owner (PO) is some which I think should have the following skills

1. Able to decide what not to build

A lousy product owner copy features from their competitors, then a slightly better one interview the user to identify the priority. Good PO will then invent and add in some more features into the product backlog. However, a best PO will know what are essential and what are noise. For product owner to know what is essential, being a user of the product is not good enough. He/She would need to understand the goal of the user, or the real business value of each feature. Many users end up just use some feature because it is available and it's obvious, they never think of why they are doing such action. For example, a save button. What is the purpose of clicking on the save button? Can a system performing all the goals that a save button could do automatically? Such as auto save features.

2. Able to articulate business value to the programmers

It is important to let the programmer feel the same way the PO. So that they understand the business value that such features aim to deliver and then propose possible implementation method. Many PO do not bother to sell the features in the product backlog to the programmers, they are still mostly trapped in the traditional product manager mindset who believe a detail product specification is enough for the programmer to deliver the feature. As I explain above, the best software product is developed by the programmer for themselves, hence it is important to make the programmer think and act like the PO.

3. Able to understand Human Behavior

A good product design is a product that answer all the human desire. I will recommend all PO to read the book Evil by Design. All final users of the product are human and the more human friendly a product design is, the better chance it will become a good selling product. It will be good if the PO could educate their programmers to understand the same design philosophy.

Practical View on Agile vs Water-fall

I have been trying to promote Agile Software development methodology to many software project manager. One common feedback I got from those meeting session is, Agile is just another hype. Some of them become so skeptical that compare Agile Software development with Java. A platform with so many promises where many company invested in Java have realized not all promises are true.

Likewise for Agile Software development methodology, I believe many Agile consultants forgot to emphasis the point that Agile is not a silver bullet. It can not perform miracle, in fact, with the concept of transparency, it always try to demystify a lot of misunderstanding regarding software development. Example of common magic where many non software people believe are: Multitasking improve productivity, The more time Programmer spent in front of their PC means higher productivity, Put more programmer into the project during crunching time could bring the project schedule back on track and etc etc.

Here I am sharing a few slides I used to explain the different between water-fall and Agile to those season project manager.

I will first start with something they all very familiar with, a water-fall project management process. We gather requirement (as if customer know exactly what they want, which is often not the case), insist on a sign off on the requirement specification before we start the next activity. At this stage, we may use a lot of prototyping, diagram, picture and etc to make sure we understand what the customer say. Then we proceed to the design, development and testing phases. Internally we make sure the developer design and develop according to the requirement specification. At the same time, we work with customer to identify the user acceptance test (UAT) criteria. Aiming for a smooth UAT session.

And then it come the big day, where the product is completed and tested internally. We prepare and organize the UAT session. Customer start testing the system using the acceptance criteria list, tick off one by one. However, how many time we have customer telling us something important is missing at this stage? That the customer refuse to sign off the project and proceed to Go Live because of the missing items? We started to explain and sometime argue with customer on whether the missing items were in the original scope or it is a change request. As the deadline for Go Live is already round the corner, tension is high in this discussion. (I would normally get a nod from the project manager at this stage of presentation)

The project budget have already spent, any additional efforts to make changes or add new functions become a tough decision. Most of the time, cost on these additional efforts would be split between the supplier and customer. Supplier may agree to perform some of these changes free of cost, while customer will raise additional fund request for other changes. Cost is an easier problem to solve compare to Time. Unless the Go Live date is postponed, there is very little time left to incorporate those changes. The team is again call to work overtime and naturally, the most intangible constraint is sacrifice. i.e. Quality. Most of the time at this stage, if the project manager has manage the customer expectation well, customer would understand these last min urgent changes would introduce quality issues. It may even cause some of the already built function to fail. It end up the important features are released with least quality.

Now, what if we could run our project this way? With similar cycle that they are familiar with, we run short iteration (I would tell them 2 weeks is just an example). We continue to do this until the customer feel they have enough features and functionality built to launch the project. One common question raise at this point is, would that not means too many change request at every iteration? I would explain that customer will be make aware that every change to already built features or function, some trade off needs to be made. However, if the change is something not built yet, that should not incur any additional cost. I will tell them that this is how Agile project management works, I could not cover all detail in this introduction. (My intention is to get their buy-in, understand Agile in the shortest time possible that it is not something totally new)

I will explain to them, all project would still have to face the 3 project constraints. However, the environment would be a bit different now. Customer could make sure most important features are built first while they still have sufficient project budget. Project manager would still expected to discuss with customer during each quick UAT whether the change request is a bug or new changes. However, because it is still at the early stage of the project, the tension will not be as high as before. Customer could also start to plan for fund request earlier if they realize the initial project budget could not buy them all important features. Since most important features are built first, customer would definitely have something to launch when the fixed Go Live date arrived. With automated regression test in place (continuous integration), the most important features are tested repeatedly with more test cases build for them in each iteration, the overall quality of the project would definitely be much better.