Product Ownership For a Service Company

by Vincent Hendrickx

The term ‘Product Owner’ (PO) comes from the agile methodology of software development. It represents the person in charge of taking the vision of a product and translating that into scope, features and priorities. In essence, the PO drives the direction of the product while staying true to the original goals, maximizing value and delivering in a timely manner.

For a company like Codelitt, which serves its partners by helping them build their products, we don’t just rely on our clients for their industry expertise and user insight. We also rely on them to fill the role of the PO or decision maker to help steer us in the right direction. However, we do not see ourselves as merely ‘executors’. We consider ourselves co-owners of the products we help build.

Extreme ownership is one of our core values and is adopted at every stage of product development. We want to do everything in our power to ensure the success of a product; to look back and be proud of what we built; to have it forge a stronger bond with our partners.

This puts extra responsibility on our teams. Rather than just take instructions, we want to be more of a guiding force. As our clients are experts in their industry, we at Codelitt are experts in product design, development and management. We want our partners to be able to tap into that expertise and experience.

Below are some principles we follow when practicing co-ownership.

Reiterate product vision and goals to the client and the team.

A constant reminder of the vision and goals means the cross functional teams will remain aligned, especially as the product evolves. Everyone rowing in the same direction also results in better decision making by everyone involved.

Know the product like the back of your hand.

In depth knowledge of a product’s current state and an understanding of the context of new features will help with building a more consistent experience. It will also result in creating less redundancies and less rework.

Think in user flows, not pages.

Every action a user is allowed to take needs context. Defining how a user gets to a flow and where they go when done will ultimately improve their experience.

Define the hierarchy of content and actions.

Prioritizing the content, actions, and data that is most important to a user will make a product more accessible and usable. If everything is a priority, nothing is.

Push to keep things simple.

Additional complexity results in almost exponential risk, whether due to higher chance of misalignment, bugs or bad UX. If a feature or flow is hard to explain, it will be hard to build and use.

Implement in iterations.

Differentiating between desired state and a first iteration will allow the team to focus on solving for the core goal, then iterate to add incremental value. This avoids having the nice-to-haves block the must-haves and leads to quicker value to market.

Understand the root problem when receiving feedback.

A product team is more effective in assigning tasks and problem solving when we can boil feedback down to the root problem rather than taking instructions.

Use examples to express recommendations or push back.

A picture speaks a thousand words and examples are often the best way to show why something works or doesn't work. Examples also add validity when making recommendations or pushing back.

If you liked this article and want to learn more about how we think, check out: