Product Development, Management, and Ownership

​

The list of products I've designed, developed, and managed is at the bottom of this page. Click here to jump to it.

​​

For product management training and coaching I've provided, click here.

​​

Introduction

I was thrust into the world of product management at the age of 16 when my mom's favorite jeweler asked me to develop a software solution for him to manage his company's payroll and to print pay stubs and related reports.  Although this solution simple compared to many modern solutions, there were several things I learned right from the start:

​

• Software automates the tasks that humans would perform manually.
   

• In order to automate these tasks, the person designing the solution must understand these tasks completely, to the point of being able to perform these tasks manually to the satisfaction of the customer.
   

• Software developers have unique insights into ways that such tasks and processes can be streamlined and improved because they understand what can potentially be accomplished by the software.  It's like an artist working with clay who understands the properties of the clay and the potential outcomes they can achieve with these properties and the techniques that they've mastered.
   

• Early and frequent feedback is essential, not only to validate that you're on the right track but also to involve your customer in this process because they get a sense of progress by directly seeing it and they can provide feedback and insights into the progress and direction of the product that the product manager and the software developer do not have, especially when it comes to changes that the customer has to deal with, e.g. timing, cost, regulations, changes to the tasks and processes that are being automated, etc.
  ​

Although I couldn't describe these lessons after that first product as clearly as I've described them above, I understood them instinctively because of what I experienced designing and developing that solution, and I continued to build on that throughout my career.

​

Additional things I learned over the years are:

​

• Unlike physical products, software is dynamic and, not only can it be updated to stay current with the customer's expectations, it must be kept current or it will eventually have no value to the customer.
   

• Someone has to be responsible for understanding how the software currently works and for understanding any changes to the customer's needs and expectations, and, with this comprehensive understanding, drive the required evolution of the software.  This someone is called the product manager.  Documenting how the software works now is called product knowledge management, and you can read more about my expertise with that here.  Product management and product ownership without this knowledge are set up for failure.
   

• The role that Scrum and SAFe calls the Product Owner is nothing more than a backlog management role because true product ownership lies with the person who has both financial and operational responsibility for the product.  Ultimately, this is the owner of the organization that owns the software but this responsibility is usually delegated to others within that organization, e.g. the heads of the departments that rely on the product.  Rarely, however, does such ownership lie with the software developer or a person within the software developer's team.  In the case of licensed products, e.g. software subscriptions, this ownership lies with the company that owns the software, e.g. Microsoft in the case of Microsoft Windows.  In other words, true product ownership requires absolute decision-making authority on the product.​​