Aha! Roadmaps | How to define your product workspace

When you first create an Aha! Roadmaps account, you get a chance to build out your workspace hierarchy — the structure of workspaces and parent lines that define your account. Aha! Roadmaps has many workspace types to choose from, each optimized for a particular function.

If you are a product manager or work with product teams, it can be useful to think about how you want to structure product workspaces in your account. The answer might not be as simple as "one workspace per product."

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.

The key is to start from the perspective of your customers or users, orient around the benefits that you deliver to them.

Click any of the following links to skip ahead:

• Signs your product structure needs to be refined

• Organize around what customers buy (or users consume)

• When to split out products into multiple product workspaces

  • Does the product have unique strategic initiatives?

  • Are the products on different release cycles?

  • Does each product have its own product owner?

Signs your product structure needs to be refined

It can be tempting to equate product components with products themselves. For example, let's say your solution provides order fulfillment software for e-commerce companies. You may be tempted to create separate product workspaces to represent each component in this example:

Order Fulfillment (product)

• Order consolidation (component)

• Order profiling (component)

• Packing (component)

• Quality Control (component)

However, these components should not be separate workspaces — structuring your Aha! Roadmaps account this way will lead to a lot of needless confusion when you try to coordinate work for your products around a single release.

Instead, manage these components with 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. Those features belong in one release, not four individual releases.

Top

Organize around what customers buy (or users consume)

Your workspace hierarchy should revolve around the value your company provides to its market, whether this is a commercial product or internal IT infrastructure. Your team should be organized around customer experiences and the collection of technology that improves those experiences. This structure enables your team to align the customer-facing releases with strategy and easily prioritize your features in one place.

Top

When to split out products into multiple product workspaces

Even when you have modeled your workspace hierarchy around what value you deliver to your customers, you may still have work to do. 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.

Does the product have unique strategic initiatives?

Generally, each product with different strategic initiatives should be split into separate product workspaces. For example, suppose you deliver 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, you should separate the management of the products into separate product workspaces, each with a product manager.

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 your products into multiple workspaces. Generally, if you are releasing at different times and the products have different strategic initiatives or different owners, it’s a good sign that you might want to manage them separately.

Does each product have its own product owner?

If your products have different owners but serve the same market, it's not usually enough to consider splitting them 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.

However, if separate product owners are working on separate offerings, it is worth considering whether they would be best served with separate product workspaces.

Top