What's Your Product?

That’s an interesting question. Though not exactly what folks want to hear from us when they ask us how they should organize their products. But if we are going to be useful, we need to answer their question with a question. We need to know what their product means to them and what their customers buy before providing any guidance.

We can only recommend how folks should think about managing their products and product teams for success after we understand more about how they define and sell their products.

Having clarity around your products and how they are managed drives accountability and responsibility. However, lots of teams move forward without such transparency. They often suffer and do not even know it.

But the moment you start using an application like Aha! you are forced to think more seriously about your product strategy and how your products should be aligned with your customers. Getting properly aligned seemed obvious to me, and I never thought of addressing this most fundamental of product questions until a customer recently asked me:

“Would you recommend that I set up and manage each area of our technology as a separate product? They all are part of what we deliver to our customers, but typically these components are built by different development teams and sometimes they have different release cycles.”

In a world of physical goods, defining your product is fairly straightforward. In most cases — a product is something that can be wrapped and sold on a shelf. A solid definition of a physical product is something akin to: an article or substance that is manufactured or refined for sale. Even if there are many components that go into the final offering — the item that customers are looking for and the final deliverable is generally clear because it can be seen and wrapped.

However, when we start thinking about digital goods it is easier to emphasize the components over the complete solution. That is because customers interact with the sub systems and often the parts are easier to experience and see than the blurred notion of the whole. For where does a sophisticated web or software offering really begin and end? The confusion around what truly is a product and how should it be managed is often further complicated because product managers spend a lot of their time working with engineers. And engineers are often assigned to certain functional area of the technology stack.

When we talk about virtual offerings like software — especially cloud-based services — teams often confuse their internal technical orientation with what customers care about.

Just because your engineering team is oriented around the technology stack does not mean product management should be as well. Don’t mistake internal, technical-specificity with how you should organize your product teams or how you go to market.

So, when customers ask us how they should organize their products in Aha! we provide the following guidance and use the following lightweight guide to help them decide what’s a product and what’s not. We suggest that this guide is useful for any team that is building a digital product and debating how to organize their product management efforts.

Organize around what customers buy This is the first principle and everything else is meaningless if you get this wrong. It is critical to organize the team and what’s considered to be a product around the value the company sells or wants to sell in market. Product teams should be organized around customer experiences and the collection of technology that improves those experiences. This market orientation is fundamental and differs from a technology bent. It encourages product managers to empathize with their customers and think about the value of what they are building and selling.

Once you rationalize your offerings by the value delivered, you still may have questions about where one product ends and another begins. And sometimes it’s complicated to draw a line. For example, some products are sold as a suite where the customer can select which components to purchase from an a la carte menu. In this case, we recommend splitting products up if they have one or more of the following characteristics. The following are signals to look for and consider when deciding.

The product has unique strategic initiatives Generally, if the product has different strategic purposes or initiatives associated with it, it can be split out. For example, one of our customers delivers supplier tracking and procurement optimization to the same set of customers. Most of the time the capabilities are sold together. However, both have specific customer requirements, unique market dynamics, and serve different strategic purposes. In this case, we recommended that the company separate the management of the products. One PM manages each product respectively.

The product is on a different release cycle Just because this is the case does not mean that the products should be separated. Yet, if you have already organized in a market-centric way and you are releasing functionality at different times — this is a good reason to separate the product. It is not a guarantee, but if you are releasing at different times and the product has different strategic initiatives or different owners, it’s a good sign that you might want to manage it separately.

The product has a product owner Clear ownership drives accountability. There is a reason the product manager is often considered to be the CEO of her product. So, this is an important signal to look for. Does the product already have a specified owner? But once again, just because the product already has a product owner does not ensure that it should remain separate from the other products and be managed independently. For example, I have argued in the past that just because a product might include a mobile app — it’s not always clear that the mobile app should be considered its own product. This is especially true if it serves the same customers as the Web version and is not sold separately.

This guide will help you answer the question, “What’s our product?” The key is to start from the perspective of your customers, orient around the benefits that you deliver to them, and then consider the key questions above. If you do, you will likely set up your product portfolio for market and team success.

If you are not already an Aha! customer, you may want to sign up for a free 30 day trial of Aha! now to see why the best known software and Web companies are using Aha! to set brilliant product strategy, create visual roadmaps, and manage their releases and sprints.