The best software products come out of legendary client-developer collaborations. When we build a custom software product for your business, we want that product to effortlessly support your operational needs and goals.
That’s why the best products come out of great collaborations with software developers, (that’s us), and product owners — and that might be you!
News flash: to be a product owner, you have to do more than, well, be the owner of a product.
Well, maybe we should clarify a little bit. If you want to be a good product owner, owning your product and calling it a day isn’t enough. In fact, it’s not even about being a customer and purchasing a product. The product ownership we’re talking about looks a little different than just being the head honcho of a project or being a customer who purchases a custom software product; it’s about accountability and involvement in the development and design process.
Who is a product owner?
In the custom software world, the product owner is a single individual on the client side who manages the Product Backlog, the definitive list of features a development team works to build. Product ownership exists in the Scrum framework of software development, characterized largely by agile development, which we’re all about here at Steele Consulting. Here is a list of Scrum.org’s project owner roles:
- A project owner clearly expresses Product Backlog items.
- A project owner orders the items in the Product Backlog to best achieve goals and missions.
- A project owner optimizes the value of the work the Development Team performs.
- A project owner ensures that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next.
- A project owner ensures the Development Team understands items in the Product Backlog to the level needed.
A product owner is accountable for those items in the development process, even if the development team itself accomplishes the tasks—which is most often the case. In short, the product owner is responsible for getting the most value out of the development team’s work.
For a product owner to accomplish this, one of the most critical concepts to understand is the concept of the minimum lovable product (this is commonly referred to as a minimum viable product, or MVP, but we’re flipping the script a little bit here). An MVP is the most basic, minimum version of a product, yet that’s designed to be a sufficient, viable solution for early adopters. The only difference between that and our MLP is that we believe our clients should not just use our products, but love to do so. Any way you slice it, the MLP is important to understand for a product owner because it allows them to more closely understand the way clients use a product, and refine the Product Backlog to reflect what customers actually seek in a product.
At Steele, we take on entire projects by first determining the MLP, and using that knowledge to divide the project into different phases—each with their own level of functionality we aim to achieve. Whenever we complete a phase, we move on to the next. It really is about eating the elephant one bite at a time.
This process requires consistent communication with the development team in the form of daily Scrum calls by the Scrum Master (or Scrum Lord, if they’re royalty). The Scrum Master focuses on three key questions for the development team: 1) What did you do yesterday, 2) what did you do today, and 3) where are you stuck? The product owner is then free to do what they do best: be the visionary for our entire project and develop the backlog two weeks in advance.
In our experience, the key determinant between a good product owner experience and a bad one is the level of excitement the owner has for the product itself; if the product owner is excited about the product, then they’ll likely be more involved in the development process. Working with people who care about the process is when things begin to go really well.
Whatever the communication process is between a product owner and development team, we urge product owners to establish it quickly.
Project Owner vs. Project Manager
If that wasn’t enough information about product ownership, then buckle up, because we’re not done. We’ve established at this point that the product owner is the visionary for the project. They’re responsible for creating and prioritizing the list of functionality the development team must build and are held accountable for its success. But someone needs to be the one to put these plans into action.
Enter the project manager.
When the software development team creates a task for a project, the project manager of the development team delegates resources to finishing the task. A project manager should have excellent time management and negotiation skills, and should be able to focus on key details during the development process.
You can think of the product owner as being the one focused on the big-picture (on the client/third party support side of operations), and the project manager as focused on the finer details (on the software development company side of operations). Both the product owner and project manager require very strong communication, leadership, and organization skills in order to work well together in creating a legendary custom software product.
At Steele Consulting, we’re passionate about our work. Being able to create custom software to meet the specific needs of each of our clients is why we exist. Please don’t hesitate to connect with us if you want to discuss our custom software and how you can be involved in our process of meeting your needs.