Reflections on Turning a Project into a Product

Even after attending 2-day trainings for both Certified Scrum Master^® and Certified Scrum Product Owner^® certifications, the real significant difference between ‘project’ and ‘product’ didn’t emerge, for me, until becoming a Product Owner of a Weekly Care Package. That’s when the deep learning began. I hope by sharing some learning here, other new (or old) Product Owners might consider the shift in thinking around working with products rather than working on projects. 

When first agreeing to formally launch and support a social action initiative to provide fresh food weekly to a neighbour who is experiencing financial hardship, I could easily see how food could be collected, packaged and delivered in weekly increments. As a Product Owner, I would oversee what items came into the package and ensure everything was delivered on time. Reaching out to a few friends, neighbours, and colleagues resulted in dozens of people contributing to the package consistently over a period of a month. Surprisingly, approximately $400 was also donated. Without a doubt, the first iterations proved there are interested contributors and also a grateful recipient.

Interestingly, an experienced Agile trainer & coach, took notice of my efforts. He offered some advice, as a ScrumMaster might share with a new and fledgling Product Owner. In a half-hour conversation, he counselled me on some features of Agile product development. He shared a few meaningful links with me, and after reminding me that Product Owners work with products, not projects, he invited me to return to an article I had written on the initiative.

I followed his guidance and when returning to my piece I found the word “project” used about half a dozen times, speckled through the article. Clearly, even though I was consciously creating a product called ” a weekly food package,” still I was unconsciously thinking of the initiative as a project. When I modified the article to insert “product,” then the way I saw the work also changed.

As a project, each time I deliver the package, the work is done. Project complete! As a product, which is a part of a delivery model called Scrum, it means each time a package is delivered it is then time to reflect in a retrospective. It’s time to learn and plan for next week’s delivery.

A project, in my mind, requires a lot of advanced planning, designated role assignments, accountability reports, and status updates. It requires a start date and a date of completion.

***

My new understanding of product development, which emerged from watching this Myths of Scrum video [below] and reading this  is that action can begin even with minimal planning. Interested people volunteer as they wish to support the development. No one reports to anyone or assigns tasks to anyone. When a successful iteration is complete, it’s useful to come together to talk about how it went and apply learning to the next week’s product.

With this learning, I later said to the ScrumMaster who was coaching me, that “I don’t see any reason for “projects” because when the focus is around a “product” then the quality is just so much better.”

In his wisdom he replied, “Imagine how it feels to Project Managers to hear something like that and you will then understand why this is such a hot topic in the industry.”

“Yes,” I replied. “I get it.”

—

This article was originally written by Rachel Perry, a former employee at BERTEIG.

[This article was originally published on Agile Advice on 16-Nov-2016]

If you find this useful, please consider contributing with our
“Value for Value” model.