In a recently published article, A Product Owner's Syllabus, I shared how we educate product owners in our company. A product owner's job requires competence in a number of domains, as it turned out. There's one more consideration that I want to highlight. It's rather related to the environment where this product owner works, not to personal skills or knowledge. Sometimes, though, it's quite hard to draw the distinction between personal skills and how those skills are influenced by the environment.
3 Levels of Product Ownership
Product owners can act on the following levels:
Mix of innovative and market-driven
Why is it important to single out these levels prior to doing drills in narrow disciplines included to the PO syllabus? This helps the trainees realize the high-octave "why" of this work. They say that philosophy is the mother of all sciences. In the same fashion, knowing the very reasons of why a product exists at all is the necessary first step. This knowledge and reasons are very product-specific. That's why I'm skeptical about all kinds of "certified" courses, because attending a course and taking part in abstract drills (such as the ones brilliantly mocked at in here) will not turn anyone into a mature product owner overnight. To me, the best credentials for a product owner would be the history of the product that this person owned or managed, at least for some time, and the thinking that stood behind their decisions. There's no better learning than by doing.
Just as in my recent post, where I anchored our evolving as a company with the way we do visual process management, I will look back at the history of our product yet again. We're cool big guys, because we can look back as far as 10 (!) years ago. Targetprocess 1.0 was launched in 2004. Targetprocess 2.0 was released in 2006. Targetprocess 3 came on the scene around 2012-2013. The 1.0 version was the minimal viable and marketable software for agile project management. Targetprocess 1 had 7 releases, from 1.0 to 1.7. Targetprocess 2 had 24 sub-releases, from 2.0 to 2.24. With Targetprocess 3, we released the version 3.0.11 last week, and the next release will be 3.1.
The Market-Driven Suite and Innovation
Looking at the releases from 1.0 — 1.7, and 2.0 — 2.24 (click the hyperlinked words above), one can draw some interesting conclusions. Targetprocess progressed with the agile movement and with what the market wanted( I wish we had a decision sequence timeline to track this better). The 1.0 version appeared as a result of market-based thinking, because agile was a rising new trend back then, and our product owner and founder (who has the project management background) wanted to do a decent software for agile project management. Then, with time, the 2.0 version was released. This was a re-written software with completely new UI. The product owner sensed that the product needs a robust core and an improved UI, before any new features could be added. That was a strategic market-based decision. Then after about 8 years of following the market, the product owner hits the level of innovation with Targetprocess3. It is indeed an innovative project management software as it brings along a new paradigm in visual project management. I do not intend to go too deep into praises, I just want to show with this story that it takes 8-10 years for a product owner to become mature and operate on the level of innovation. Some product owners never get to this level. They implement the features that make their product more appealing to users, to outperform the competitors, or both. There's nothing good or bad about it, just the way it is. It's quite rare nowadays that a completely new product comes as "innovative". Start-ups are mostly busy discovering smaller niches in the established market and filling them in.
A Basic Drill for Newbie Product Owners
Well, a product owner may or may not reach the innovation level. Let's get down back to earth. I have this list of questions ready for trainee product owners to help them exercise their minds in product-based thinking as they consider implementing new features:
How often will people use this new feature?
How many people will use it?
Will this feature address any particular pain of users?
How it will help users save their time, if at all?
Will it make any difference, or will users be just as fine without this feature in the product?
Will this feature make the product easier-to-use or more complex?
Will it help bring new business, or is it meant for established users, mainly?
Formulating such questions can be a good exercise at an internal company training. The road to success starts with one first step, and this simple drill might be a nice first move in a career of a product owner, who might become an Innovator some day.