The Aha! Data Model
We are often asked how data is organized in Aha! and how teams should think about structuring their product strategy and roadmap in general. We figured the easiest way to answer these questions would be to publish the core data model for Aha! We think you will find it useful if you are building software, whether you use our application or not. Some may consider publishing this type of sensitive information foolhardy — but we figure any smart person with an Aha! trial could figure it out. At the end of the day it highlights our philosophy on what it takes to build great software.
The Aha! data model does two things — it highlights the key building blocks in Aha! and it explains the relationships between the entities. The model is below as well as the definitions for the various components and an explanation of how they are related.
Product hierarchy
Product lines and products Products can be organized into product lines to create groupings. You can create as many levels as you need. For example, you might have a top-level company name, a product line under it, and then products under it. Creating hierarchy is important if you want to ease navigation, set up more sophisticated user permissions, and create rollup views on the dashboard of your strategic initiatives.
You can add hierarchy by creating a product line and then selecting which products belong to it or by selecting a product and choosing which product line it belongs to.
Product strategy
Product lines and products can both have strategy. The key construct here is that strategic initiatives for a product line or product can roll up to a higher level product line initiative. This allows you to visualize your roadmap by the initiatives that you are working against and the business value that you are delivering. Strategy is comprised of the following three components and you can choose to use all or none of them.
Vision Great products have a soul. The soul is your vision for the product and it should explain how the customer will be thrilled and the world a better place when you realize your dreams. The vision is the place to define your outlook for the product and where it is headed. A good vision is supported by details of customer personas, what customers need, the market landscape, and your go-to-market plan. It captures the essence of what you want to achieve – the critical information your team must understand to develop and maintain a winning product.
- EXAMPLE: global leader in market x
Goals Your product goals must have a measurable end result that can be achieved within a fixed timeframe. Your objectives should represent the critical accomplishments that are required to make your vision a reality. They highlight what you hope to accomplish and are often stepping stones to accelerating business growth and laying out bolder goals. They should also be reasonably easy to track, so you know how you and the team are doing against them. Because if you cannot measure it, you cannot improve it.
- EXAMPLE: grow sales in Europe by 2x
Initiatives Initiatives allow you to specify key work that needs to be completed to achieve your goals. Think of the efforts as projects that should be accomplished within a specified period of time — even if that is over months. Initiatives tend to cross multiple releases or sprints and include many stories or requirements.
- EXAMPLE: translate product into French
Note that initiatives can be tagged to releases and can roll up to higher level product initiatives. They also serve a dual purpose in that features can also be linked to initiatives (across the product portfolio).
Releases
Releases typically represent a target timeframe when a pre-determined amount of software is going to be developed. We generically use the term releases, but because Aha! is dev methodology agnostic the concept also support sprints and even continuous forms of development like Kanban. Releases are children of products.
Features
Features are children of releases and define a set of software capabilities that are specified through descriptive text, images, and additional meta information. Features also can be further defined through requirements. Requirements are children of features and can also contain their own set of limited meta information that helps define them.
The main purpose of Aha! is for product management and engineering to capture and curate ideas that will deliver the greatest business value — and be happy doing it. Our data model has been built to make this as easy as possible — starting with product strategy and ensuring that your product vision is a red thread through the entire roadmapping and feature definition process.