There are various roles in an Agile project: developer, tester, business analyst, scrum master, and product owner. Of these, the Product Owner is arguable the most important role. I have worked with a lot of product owners over the years. Some very good ones and some bad ones. Later I'll have some tips on how to become a great one. Before that, I want to talk about what the product owner role is and how it evolves.
Most product owners don't really apply for the job. Some don't even realize they are a product owner. The position evolves over time like the product itself. All products start out small. Sometimes you don't even realize you are working on a product. You are just automating some mundane, boring task. You mash together a little script, macro, or Excel file that helps you in your day-to-day job.
Eventually users besides yourself start to like what you have done. They start making requests for it to do more. Implementing these features starts taking more and more time, and maybe pushes your technical ability. Eventually you must get help so that you can keep your day job. You start to be able to describe coherently the value your little product has. You can start to sell it to others. You can start to get funding for it. It starts to snowball.
That was a very short paragraph that describes the evolution of a product and the product owner role along with it. Although it can be described quite quickly, this evolution can take years. There are distinct phases:
- Hobbyist - where you are building the software primarily for yourself.
- Custom Software - where you are building the software primarily for a single company or a very small set of users.
- Marketable Product - where you are very professionally trying to build your software for many people that work for many different companies.
There are certainly differences in how you manage a product between the Hobbyist and Marketable Product phases.
When you are a Hobbyist, you don't need to worry about making anyone happy other than yourself. There are no committees, no egos, no budgets, little to no plan; it just doing what ever you want. The software is in your full control, and you can make it do whatever will make you happy as an end user.
At the other end of the spectrum is the Marketable Product. This requires a product owner that is very dedicated to the role, and it is probably a full-time job. No longer it is just yourself as the end user driving everything. There are distinct groups that you need to listen to:
- Existing Customers
- New Customers that you are onboarding
- Sales & Marketing
- The Development Team
The product owner is responsible for the vision of the product. Although each of the above groups may be able to nudge product vision a little bit, it is the product owner that has the ultimate say. The days where every end user has full control over the design of the software are over. Of course, you still must be responsive to the demands of your users, but it must be tempered with sound software design that builds a maintainable code base and infrastructure. All must share the vision and be free from anarchy.
The product owner is a domain expert. This is one of the marketing points of the product. Customers are attracted to a product owner that understands their industry equal, if not better, than they do. The product owner’s expertise is visible in the product. The product guides their users toward industry standard best practices. New users to the industry (especially) will gain expertise in the industry just by using the product.
The Customer Software phase is the most dangerous phase as a product owner. It is a time of transition from Hobbyist to Marketable Product and it can be very unstable. As the culture changes it can be difficult to keep everyone on board with the product vision.
When developing Custom Software, you need to satisfy more people that just yourself. However, the number of people is still quite small. In the beginning the goal of making everyone happy, all the time, is almost achievable. Building the community around the product as it grows is as important as the product itself.
With Custom Software you as the product owner are not developing the software yourself. You are outsourcing that to other people. The development team is not providing a product, they are providing their development services. You, the product owner, are building the product. The development team will do whatever you command, within reason. You will not succeed without a happy, well managed development team that wants to work for you. They'll advise on sound software designs and how to manage technical debt, but it up to the product owner to learn to listen.
The transition from the ad-hoc, unmanaged Hobby to a well managed Marketable Product is full of learning opportunities. There are things to learn about managing a product, the domain, legal compliance, budgeting, marketing, software architecture, listening, and the list goes on and on. It is a tough job. There will be things that you need to know before you know you need to know them.
The product management strategies used on successful Marketable Products almost always can be applied to a small hobby project as well. The earlier you can apply those strategies to your hobby or custom software project, the more successful it will be. Even if there are no plans to develop it into a broad marketable product, these strategies can help build a hobby product that you can be proud of.
In my next post, I'll dive into some good questions that product owners should be asking for every feature the consider adding to the product. I think they are good questions to ask if have a marketable product or are just working on a hobby product.