How to Think About (And Structure) Your Products

How do you think about your product portfolio? What products do you have? What capabilities do these products provide? How should I be thinking about these things? What products should I invest in, divest in, or stop? What is the ROI for a product? A feature? What features are showing quality problems?

How we think about our products and their structure is a vital pre-requisite to help answer some of the above questions. You lose visibility and clarity if you don’t have a structured or granular product hierarchy.

In this post, we will discuss how you should think about your products and their hierarchy with some real-world examples.

Start With Why

First off, why should you care about this?

At our previous company, we faced a lot of visibility problems due to the inability to tie revenue, cost, and defects back to a granular piece of a product. Sure, we could do this at a very crude level, but as our engineering departments grew where whole teams were working on a feature, the lack of ability to show the distinct ROI for that feature became a very limiting feature.

In talking to many of our other founders and established companies alike, they all faced similar challenges. Of course, they could do things at a macro level, but when you have 500 engineers (or any number for that matter) working on a product, how do you decide what features you scale-up, scale-down, or stop? Time, money and opportunity cost are all things that must be optimized. At what level are you doing this?

Return on investment (ROI) has always been a core focus for departments like sales. For example, you have a rep that has an OTE aka cost (base salary + comissions + T&E), and you can see how much pipeline and revenue that rep brings in. Simply put, you can characterize the ROI for that rep. The fact that people only do this subjectively or at a macro level for products dumbfounded us.

One of the core tenants we sought to achieve with the DevRev platform was that everything MUST relate back to a product or piece of a product (we call these ‘parts’). Why you may ask? Clarity. By relating everything back to a piece of a product, we can answer the following questions:

• What features bring in the most revenue?
• How much did a feature cost to develop?
• What capabilities have the highest defect rates?
• What features are getting more adoption?
• What was the ROI for a feature?
• …

Structure

At a macro-level we characterize parts (a piece of a product) into two core areas:

• Parts that the customer interacts with AKA ‘Rev Parts’
• Parts that provide functionality the ‘Rev Parts’ express AKA ‘Dev Parts’

The following figure shows each of these areas as well as the sub-types each one includes:

We will break down each of these areas in the following sections. NOTE: we will cover Dev Parts at a future point.

Rev Parts

Rev parts relate to how a product is expressed, integrated, or consumed. These parts may be consumed by external customers (revs) or internal employees (devs). Although they may also be provided/enabled by dev parts running internally, the customer just sees the product, service or feature they are interacting with. Rev parts may also be abstractions on other rev parts exposed by 3rd parties (such as Auth0 or s3).

Product or Service

At the highest level of the part hierarchy is a product or service. An organization may have one or more products or services they deliver to their customers. Products can also be delivered through one or more conduits (such as tangible goods or as-a-service).

Products typically have the following characteristics:

• Are a unit of profit and loss (P&L)
• Are where customers (internal or external) are onboarded
• Provide the basis for identity
• May have a notion of billing/chargeback (which can be done at this level or further down the stack)

Services may have the following additional characteristics:

• Provide an API or interface
• Define code-based or business services
• One example of the difference between a product and a service is Microsoft Office (software product) versus Office 365 (cloud service).

A key to consider is that all must be considered in the perspective of the dev org. A product for them may be a service for another. For example, consider a managed services provider, they may provide a “product” (e.g. Microsoft Exchange) delivered as a managed service.

A service may also be a business service like IT (internal), HR (internal) or Consulting (external.)

Example products delivered as software or tangible goods:

• Hardware products (Lenovo laptops, etc.)
• Software products (MSFT Office, Acrobat, etc.)

Example services:

• Cloud services (Amazon Web Services, Azure, GCP)
• IT services (Helpdesk, Data center, etc.)
• Facilities services (building services, lunch services)

Capability

A capability exists under a product or service and is commonly the main item of interaction for customers.

Capabilities typically have the following characteristics:

• Exist under a product or service
• Provide the ability to do something (verbs) with entities (nouns); for example create object
• Provide an API namespace
• Provide units of licensing and pricing
• Have its own level of authentication and access control or may inherit from the product

One key to highlight here is these things will evolve over time and change. For example, Word used to be it’s own product for Microsoft back in the day. The key here is how should you be thinking about these things and how should things roll up. In other cases, you may see that a capability eventually evolves into it’s own product. There is no one-size fits all here, and if you don’t get it right to start, there’s no problems with that. The key is you want your hierarchy to match your business and roll-up in the correct manner. The more granular you can get the better, but not everything needs to be down to the feature/sub-feature level.

Feature

A feature exists under a capability (or feature for sub-features) and is commonly a unit of configuration or “knobs” in a capability.

Features typically have the following characteristics:

• Exist under a capability (or feature for sub-features)
• Provide a unit of configuration (adjective) for entities managed by the capability
• Enable version history (adjective) on object
• May provide a subset of the API namespace
• Are interacted with only inside the context of the capability or not directly interacted with at all

Examples

In this section we will analyze some well-known companies’ product hierarchies and break them down. NOTE: these are just example hierarchies and are not meant to be exhaustive.

The first company we will look at is Amazon. If we look at their hierarchy, we can see they still only have a handful of products for their size:

• Amazon.com (product)
  • Product Catalog (capability)
    • Search (feature)
  • Recommendations
    • Recommended for you
    • Frequently bought together
    • Similar items
  • Review and Ratings
    • Rating system
    • Written reviews
    • Verified purchase
  • Subscribe & save
    • Recurring deliveries
• Amazon Web Services
  • Compute Services
    • EC2
    • Lambda
    • Elastic Beanstalk
  • Storage Services
    • EBS
    • S3
  • Database Services
    • RDS
  • Networking Services
    • VPC
    • Route 53
    • CloudFront
  • Analytics
    • Redshift
    • Athena
    • Glue
  • Security and Compliance
    • IAM
    • WAF
    • Shield
• Amazon Echo
• Amazon Prime

If we look at Microsoft, one interesting thing is how this product hierarchy has evolved. For example things like Word and Excel used to be their own product lines, however they eventually collapsed under the Office Suite product line.

• Windows OS (product)
  • User Interface (capability)
    • Start menu (feature)
    • Taskbar
    • System Tray
  • File Management
    • File Explorer
    • File History
  • Security
    • Windows Defender
    • Windows Hello
  • Accessibility
    • Ease of access
    • Narrator
  • Cortana
    • Voice commands and NLP
      • Hands-free
      • NLP
    • Personal Assistant
      • Reminders and alerts
      • Calendar management
      • Daily Briefing
    • Device Control
• Office Suite
  • Word Processing (Word)
    • Text formatting and styling
    • Documentation creation and documentation
    • Collaboration
  • Spreadsheets (Excel)
    • Data authoring and analysis
    • Data validation
    • Charting and visualization
  • Presentations (PowerPoint)
    • Slide creation and design
    • Presentation
    • Collaboration and sharing
  • Notes (OneNote)
    • Note organization
    • Media integrations
    • Cross-platform synchronization
  • Email (Outlook)
    • Email management
    • Calendar and scheduling
    • Contacts/Address book
• Azure
  • Compute Services
    • VMs
    • Azure Functions
    • Azure app Service
    • Azure Kubernetes Service (AKS)
  • Storage Services
    • Blob Storage
  • Database Services
    • Cosmos DB
    • SQL Database
• Xbox
  • Hardware
  • Entertainment
    • Blu-ray/DVD
    • Media Streaming
  • Social & community
    • Xbox Live Gold
    • Xbox Live Clubs
  • Accessibility
    • Settings configuration
    • Accessibility features
• Surface

Lastly, if we look at how we’ve structured our product hierarchy at DevRev we can see how it started small and has evolved. When we first got started we had the following product structure:

When we started DevRev we had the following structure:

• DevRev Platform
  • Core
  • Build App
• DevRev Corp
  • People
  • Places

As we have built out the product, we have expanded things quite significantly, the following is a snapshot of this current structure:

• DevRev Platform (external facing) (product)
  • Build App (capability)
    • Issue Management (feature)
    • Now, Next, Later (NNL)
    • Part Discovery
    • Trails
    • Sprint Management
    • Vistas
  • Support App
    • Knowledge base
    • CSAT
    • Routing
    • Email integration
    • Support Portal
  • Operate App
  • Grow App
    • Account Management
    • Contact Management
    • Engagement Tracking
  • Core Services
  • Marketplace
    • Partnerships
    • Integrations
      • Discord
      • Slack
      • DevRev CLI
      • KB Extraction
      • Github Airdrop
      • SFDC Airdrop
      • Jira Airdrop
      • ServiceNow Airdrop
      • ZenDesk Airdrop
  • Snap-in Platform
  • Analytics
  • Mobile
• DevRev Corp (internal facing)
  • Cloud Ops
    • External Infrastructure
      • AWS
      • Confluent
      • GCP
    • Delivery architecture
      • Edge caching
      • Edge logic
    • Accounts and Access
    • Security
    • Observability
  • People Ops
    • Talent acquisition
    • Ops
    • People success
  • Places
    • Austin, TX
    • Palo Alto, CA
    • Ljubljana, Slovenia
    • Bangalore, India
    • Chennai, India

How to Get Started

At this point we should understand the various types of parts in a product hierarchy and some examples. So now, let’s get started defining your own!

If You’re a Startup or Early-Stage

If you’re a startup or defining your products, start small and iterate. This is important as there is no perfect model and getting the initial model right is unnecessary as it will evolve. In fact, it is likely better to start with fewer parts and refine them over time as clarity emerges.

As mentioned in the previous section, when we started DevRev we had the following structure:

• DevRev Platform
  • Core
  • Build App
• DevRev Corp
  • People
  • Places

If you look at the above, we didn’t have a crazy number of parts, nor did we have the detailed features, as they didn’t exist yet. Over time we have built new features leading to new capabilities and even added additional products. The key here is to start small and iterate.

If You Have An Existing Product Portfolio

If you have an existing product portfolio, you may have some idea about your products or a good starting point. Look at your existing product material, how finance breaks out BUs, how marketing structures the content and how your BOMs are structured.

The key here will be aligning different orgs (e.g. product, engineering, sales, marketing) on a consistent product breakdown. For example, you’ll commonly see a divide between how marketing structures the product hierarchy in product material, and how engineering or product structure it. In most cases, orgs will just care about metrics and structure at their level. However, in order to enable a holistic view, things must converge.

For example, if you want to look at engagement for new features, the way marketing and engineering talk about features needs to be consistent. If you want to see the sales revenue or pipeline for a feature, you need to have consistency between opportunities and product features. Finally, if you’re going to get an accurate ROI for a feature, you need to be able to relate sales and marketing costs (S&M), engineering costs, and operational costs to the revenue (or potential) it is bringing in.

These are only possible with a converged view that all stakeholders work off of.

TL;DR

• Start small and iterate
• To determine capabilities, try to bucket or cluster features together into logical groups. Also, think about what are the expressable traits of your product.
• Understand that the role of a part may change over time (e.g., Microsoft Word used to be a product but is now a capability under the Office Suite)
• Converge the organization’s definition of the hierarchy (this is key)
• Relating data back to the product’s components will give you a ton of great visibility (e.g., real ROI for a feature, etc.)