Mapping your product and technology landscape before you prioritize

A request arrives to "add a discount field to quotes." It sounds like a small change. Then it turns out the quote data flows into the ERP, the commission system, two reports and a customer portal, each owned by a different team. What looked like a week of work becomes a quarter.

This happens when an organization has no shared map of its products and technology. Without one, the true size and impact of a request only becomes clear after it's approved, which is the most expensive time to find out.

What a product and technology map is

An application portfolio map, or product model, is a simple inventory that answers three questions:

1. What products do we run? Long-lived products or capabilities the business depends on, such as "Customer quoting" or "Field inspections."
2. What applications and technologies make them up? The systems, platforms and integrations behind each product.
3. Who owns them? The team accountable for each product and its health.

It isn't an enterprise architecture repository with hundreds of attributes. For portfolio decisions, a short list with owners and a few links between products is enough.

Why it matters for prioritization

Impact becomes visible at intake

When a request names the product it affects, the map shows which other products and teams are connected. Those teams can be consulted before the decision, not after. See Getting estimates from every impacted team.

Investment can be seen by product

With requests tied to products, you can see how investment is distributed. Are you spending 60 percent of capacity on one product while another, equally important, gets nothing? That's a strategic choice that should be made deliberately.

Sustainability has a home

Technical health, support burden and aging technology are properties of products. Without a product map, they have nowhere to be recorded, so they're forgotten until something breaks. See Making technical debt visible.

How to build a map in days

Step 1: List products, not systems

Start with the business view. Ask department leaders what capabilities they depend on. Aim for 15 to 40 products for a mid-size organization. If you have 200, you're listing systems, not products. Group them.

Step 2: Attach applications and technologies

For each product, list the main applications, platforms and integrations. Don't chase completeness. The goal is to catch the connections that matter for impact.

Step 3: Name an owner for each product

Every product needs an owning team, and ideally a named product owner. Products with no owner are a finding in themselves: they usually carry the most risk.

Step 4: Note the key relationships

Record the most important dependencies between products, such as "Quoting feeds Order management and Commissions." A short list of relationships catches most of the surprises.

Step 5: Keep it alive

Update the map as part of normal work. When a request reveals a missing dependency, add it. When a system is retired, remove it. A map maintained through the intake process stays accurate far longer than one maintained by a yearly survey.

A simple example

With this table, the "discount field" request immediately shows three owning teams that need to weigh in before anyone commits.

Common pitfalls

• Starting too detailed. A map that takes six months to build is out of date when it's done.
• Making it an architecture-only artifact. If business leaders don't recognize the products, they won't use the map.
• No owner for the map itself. Assign someone, usually in the portfolio or architecture function, to keep it current.

How Aizu helps

Aizu lets administrators define the organization's products and place each initiative within them, so it's clear which product a request affects and whether that placement has been confirmed. Portfolio views can be filtered by product, which shows how investment is distributed and keeps product health part of the conversation. Related: IT capacity planning.