3 Tips for Product Ownership Success as a Project Manager

By Mike Mannis
Program Manager
projekt202

As a software consulting company, projekt202 works with clients and client teams of all sizes and configurations, from small startup technology companies to global product giants. For smaller teams, the project manager often fills multiple roles, including product owner and business analyst. Larger companies tend to have dedicated product owners, but even when a product owner exists, project managers can make their software development projects more successful by understanding and executing principles of good product ownership. 

Here are three tips to help you push your project management boundaries.

Know How Your Product Works

Obviously, all product owners understand at a high level what their products do and how they serve their customers. They may have even put together a business case justifying each feature, based on market analysis, cost estimates and expected ROI. However, going a level -- or even two or three -- deeper will help you as both a product owner and project manager.

Understanding the basic architecture of your solution is often necessary to plot development story dependencies, which is important when prioritizing the backlog and planning sprint commitments. 

In an ideal world, each story is an independent piece of functionality that can be released on its own; however, in the real world, this can lead to large stories that break the "small" requirement, or smaller stories that need to be released as a group to provide real value. 

In either case, understanding the technology can provide insight into how to assign team members: can multiple developers work on separate tasks (for larger stories) or stories in parallel? 

There might be a technical dependency; alternately, a perceived business dependency might not exist for the technical implementation. (Does a "create entity" story absolutely have to be done before a "delete/move/manipulate entity" story?)

Similarly, knowing the data schema will help you understand any limitations or pain points that could affect new features. For example, "We never stored data x in relation to data y, so we have no way to allow customers to split those on invoices." 

Additionally, I find that many times I can answer questions from the business stakeholders about product behavior (especially unexpected behavior) by examining the data. If your product uses a relational database and you don't already know SQL, consider learning basic SQL so you can run queries yourself; it's not too difficult.

Be the Voice of the Customer

Hopefully, your project began with experience strategy and insight work, including research with actual users, such as persona creation and contextual inquiries. If so, be sure to refer back to that work frequently, especially if you're in a longer "maintenance" cycle once the initial launch is done. 

Unfortunately, many projects skip that phase, and the only sources of requirements are business stakeholders and perhaps internal subject matter experts. In that case, you need to act as the voice of the customer. Business stakeholders and SMEs naturally tend to have business-centric and product-centric viewpoints. Ironically, product owners -- and thus project managers -- achieve more success with a user-centric viewpoint instead. 

One of the best ways to ensure that business features meet user needs is, of course, to validate those features with actual users. The best time to do that is before the features are actually built. 

As a project manager, insist on testing prototypes before development of the full solution. You can do it inexpensively with mockups ranging in fidelity from paper printouts to clickable design comps using a tool like Invision, or even a "smoke and mirrors" UI-only prototype. 

Whatever the method, finding surprises and course-correcting at the design stage is always cheaper than building the wrong solution and needing to redesign and rebuild it later. Prototype validation can also give you the ammunition you need to push back on business stakeholders when requirements don't serve the users' needs.

Measure Success Quantitatively

From a project management standpoint, a project is generally considered a success if it launches on time, and on or under budget. However, those criteria do not consider the success of the product itself.

So, how do you know if the software you've delivered can be considered successful? 

The key is to determine a set of metrics before launch that can be objectively measured after launch. These will vary from project to project, of course, but some examples could be increase registrations by 20%, increase revenue by 5%, or achieve 75% adoption within one month. 

Whatever metrics you choose should be measurable. During development, be sure that the software includes instrumentation that allows you to track the metrics. Then, after launch, regularly check whatever metrics you've defined. Every subsequent software update is a chance to make corrections and re-measure.

No matter how your team is structured, thinking like a product owner will benefit your project.


projekt202 is the leader in experience-driven software design and development. We are passionate about improving the experiences that people have with enterprise and consumer digital touchpoints.

Contact us today to discuss how we can deliver results for you.  

Follow us on LinkedIn and Twitter for the latest projekt202 news.