ryanwold.net

A civic-minded citizen seeking the singularity

An entry

Assessing a software product portfolio

Series: On Work
Date: 2022-01-16
Status: release
Tags: product management software portfolio measurement
This Entry is part of the Series On Work.

Almost every organization in 2022 runs software of some type. Larger organizations tend to run larger amounts of software, and at a certain point, those software systems require full attention to help ensure those systems are optimal; as measured in several dimensions.

Software becomes an actor in a social-technical system. It now has a role. What is that role?

The lifecycle of software; software grows

As software eats the world, applications are built, data stores are created, data warehouses evolve, machine learning pipelines refine; while creating a second-order cycle of building, creating, growing, and refining again.

As software eats the world, it also leaves remnants.

  • Applications become defunct through non-maintenance or obsolescence.
  • Data warehouses become deserted data silos.
  • Data stops flowing through the machine learning pipeline and looking back, it is difficult to measure what, if anything, was learned about business operations.

Learn the landscape

  • Which products are currently active?
  • Which are in-development, and yet to launch?
  • Does there happen to be a list of projects or efforts that have failed in the last 5-ish years?

What does optimal mean in this context?

  • The software is in use. People actually use. They enter information into it. They search for information in it, and run reports from it.
  • Low cost of change. The software can be modified to meet the evolving needs of the organization.
    • Different parts of an organization change more rapidly than others. Internal approvals and claims processing is less likely to change R&D or Community support.
  • The software is performant. Generally, I prioritize human hours over machine hours. But, given two solutions, higher performance is typically better. This is applicable given the current concern regarding energy and computation.
  • The software costs as little as feasible. But generally, if you can pay less in an agreement, try to. That's all. I'm not saying cheap software is better.

To make sense of all this, I typically turn to Wardley Maps.

Getting a situational awareness of a dynamic ecosystem requires, for me, a visual diagram.


How and where to align aspects?

Alignment is a notion; a visual concept, connoting parallel, congruence, like train tracks. Given many different software applications, of different shapes and sizes, serving different users; how to align?

It requires getting to like attributes across the different products, somehow.

Wardley does this by 1. proximity to the user, 2. evolution in its lifecycle and 3. relationships to other components.

I also look for:

  • Is there commonality around the technical stack? (eg: Rails apps, or Javascript apps)
  • User base?
  • User needs?
  • Actual UI mechanic - eg: Calendaring, or Commenting
  • Backend shared needs (Search service, Workers, Storage, Cloud Services)
  • Legal or legislative requirement
  • Revenue
  • Funding or budget source

Jeff Bezos famous memo on API interoperability is a good way to think about this. Ultimately, this is about understanding the Dependency Tree across software applications, and to do that effectively, the structure and some fuzzier aspects of culture must also be represented on the map.