Whether you are delivering software, hardware, IT infrastructure, client services or some combination thereof, you need a way to organize around how your customers or users consume those products, applications or services. The Aha! Product is an object that represents any of the above and a way to organize your offerings.
It's easy to fall into the routine of emphasizing components over the complete solution. After all, customers or users interact with tangible components and you spend a lot of time with engineers who are often assigned certain functional areas. But this is a mistake that will lead to unnecessary overhead and difficulty staying aligned with your strategy.
When configuring your products and product lines in Aha!, use the following lightweight guide. This guide will help you answer the question “What’s our product?” The key is to start from the perspective of your customers or users, orient around the benefits that you deliver to them. Note: For more about the Aha! data model read about Product hierarchy and how to associate strategy at each level. To configure products see Configure products and product lines in Aha!
Organize around what customers buy (or users consume)
It’s critical to organize the product around the value the company sells or provides to its market, whether this is a commercial product or internal IT infrastructure. Product teams should be organized around customer experiences and the collection of technology that improves those experiences. This enables the product team to align the customer facing releases with strategy and easily prioritize the features in one place.
When to split out products
Once you rationalize your offerings by value delivered you still may have questions about where one product ends and another begins. For example, some products are sold as a suite where the customer can select which components to purchase from an à la carte menu. The next area to consider is whether or not your products have unique strategy initiatives.
1. Does the the product have unique strategic initiatives?
Generally, if the product has different strategic initiatives it can be split out. For example, one of our customers delivers both 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.
2. Are the products on different release cycles?
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.
3. The product has a product owner
By itself, having a unique product owner is not reason to split out a product but it strengthens the case for #1 and #2. If, however, the products have different owners but serve the same market, it's not usually enough to consider splitting it out. For example, if a product has a mobile app that serves the same customers as the Web version and is not sold separately, we wouldn't recommend splitting it out.
Signs your product structure needs to be refined
If it feels like you have a lot of overhead when managing releases, chances are you have set up a component of your offering as an Aha! product. For example, let's say your solution provides order fulfillment software for e-commerce companies. You may be tempted to create products to represent each component in this example:
Order Fulfillment (product)
- Order consolidation (component)
- Order profiling (component)
- Packing (component)
- Quality Control (component)
These components should not be products. They should be managed by custom fields at the feature level. When you create your next customer facing release, it will likely include updates to most, if not all, components and those features belong in one release, not four individual product releases.
If you need help reviewing your product structure, don't hesitate to reach out to email@example.com. The Customer Success team is comprised of former product managers and can help.