


An advanced new form of visual to help you understand complexity.
A system for visualizing software products the way CAD visualizes physical objects
A software product is broken down into functional components. These include pages/screens, UI elements, behaviors, and data types. Those components are represented as boxes.
The components are organized hierarchically, with the highest level objects shown on the left, and their sub-components appearing to the right. This forms a tower, but the product can be broken up into separate towers by major feature groups.
The components are assigned attributes like object type, pipeline status, scheduled sprint, total design hours, total lines of code, number of bugs, and more. They values can be assigned manually or via API.
The boxes are color coded based on user-defined views to track the status of the product, simultaneously at a high level and in detail.
Areas of interest can be quickly identified and explored by jumping to the corresponding pages in Jira or Slack or Github or Figma.
XenBuild has its origins in my work with Boeing, which involved tracking R&D projects. Through my research, I discovered an unmet need to understand a complex situation at both the strategic, managerial level, but also at the detailed technical level. Attempting to separate out those views led to tunnel vision and poor decision making.
A few years later, I was redesigning a company's entire user experience and the resources for actually managing the project were minimal. We had no product or project manager, so controlling scope fell to me. I devised an ad hoc solution that resembles XenBuild is now using just Figma. This solution provided a level of clarity into the product scope and the project status, and we were able to deliver a winning product in a short time.
I subsequently applied this solution to several more projects, refining the approach, but also discovering the limitations of attempting to do it in Figma. That's when I built the app.
XenBuild can be used wherever there is complex information that must be modeled. It is applicable to every part of the organization.
Product managers can understand their product as a truly complex system rather than a set of features and timelines.
Project managers can escape the trap of thinking of the product in terms of dependencies, deadlines, and tasks.
Designers and developers can understand how their work relates to the whole, and readily identify areas for improvement.
Executives can keep themselves familiar with the product without getting mired in the weeds.
PUT LINK HERE