Why I Built Pathfinder Analytics and What Happened After We Implemented It
Pathfinder Analytics wasn’t originally intended to become a product.
The thinking behind it started during my time at HC Media Group, where I was involved in a variety of projects across design, development, project delivery and internal systems. Like many growing agencies, we had no shortage of information available to us, however understanding that information in a meaningful way often required jumping between multiple systems, spreadsheets, project meetings and conversations.
None of those individual systems were necessarily wrong. The issue was that they all answered slightly different questions.
Project managers were reviewing project budgets, finance were reviewing costs, departments were managing workloads and leadership were trying to understand overall business performance. The information existed, however it was often disconnected. Understanding the health of a project wasn’t always a case of opening a dashboard and finding the answer. More often than not, it involved gathering information from multiple sources and forming a picture from there.
Over time, I found myself returning to the same question.
If all of this information already exists, why is it so difficult to see it in one place?
That question became the starting point for Pathfinder Analytics.
Retrospectively, I don’t think the concept behind Pathfinder Analytics was ever centred around time tracking, although that’s often the feature people associate with it first. Time tracking happened to be one of the more obvious operational problems, however the thinking behind the product was much broader. I wanted to create something that brought together project planning, workload management, budgeting, reporting and project health in a way that felt logical to the people using it every day.
My experience with UX (user experience) has always influenced the way I approach product development. Rather than thinking about how somebody will use a feature today, I tend to think about how they’ll interact with it daily over weeks, months and years. Internal software is particularly interesting because the people using it don’t interact with it occasionally. They use it constantly. Small frustrations become major frustrations surprisingly quickly, and features that seem useful during a demonstration often become obstacles once they’re part of somebody’s daily routine.
That thinking influenced almost every decision made during the development of Pathfinder Analytics.
As development progressed and the product started taking shape, we began implementing parts of the platform within HC Media Group. That process turned out to be incredibly valuable because it exposed the difference between what we thought people needed and what they actually needed. Some ideas worked immediately. Others evolved considerably once they were being used in real projects, by real teams, dealing with real deadlines and commercial pressures.
Interestingly, many of the most important features weren’t identified at the beginning of the project.
The original discussions focused heavily on time tracking. After a few months those conversations had naturally expanded into project planning, additional work requests, contractor costs, project risk, budget management and weekly reporting. Every operational discussion seemed to uncover another connected problem, which ultimately reinforced the original thinking behind the platform.
Projects don’t exist in isolation.
Budgets affect planning.
Planning affects delivery.
Delivery affects profitability.
Profitability affects business decisions.
Trying to understand any one of those areas without understanding the others rarely tells the full story.
That became one of the core principles behind Pathfinder Analytics and, in many ways, shaped the direction of the product more than any individual feature ever did.
Why Time Tracking Became The First Module
Although the long-term thinking behind Pathfinder Analytics was always broader, time tracking became the first module for a fairly practical reason.
It sat in the middle of almost every conversation we were having.
Whenever project budgets were discussed, time tracking appeared. Whenever project profitability was reviewed, time tracking appeared. Whenever workload planning became difficult, time tracking appeared again. It wasn’t necessarily the most important problem, however it was connected to almost every other problem we were trying to solve.
At the time, HC Media Group was managing projects across multiple departments, with designers, developers, project managers and external contractors all contributing towards delivery. Understanding how much effort had been invested into a project wasn’t impossible, however it often required piecing information together from several places.
That created an interesting challenge.
Recording time is relatively straightforward. Almost every business has a way of doing that already. The difficult part is ensuring that the information becomes useful afterwards.
I wasn’t particularly interested in creating another timesheet system.
There are already hundreds of those available.
What interested me was what happened after somebody recorded their time.
Could project managers understand project performance more easily?
Could finance review budgets with greater confidence?
Could leadership spot trends earlier?
Could additional work be identified before it became a problem?
Those questions were far more interesting than the process of entering hours into a form.
Once I started looking at the problem through that lens, the structure of the platform started becoming much clearer.
Planning Work Across Departments
Once time tracking started taking shape, the next area that kept appearing in conversations was planning.
At the time, HC Media Group was managing projects across multiple departments, with designers, developers, project managers and external contractors all contributing towards delivery. Although each department had visibility of its own workload, understanding how that workload connected across an entire project wasn’t always straightforward.
A project might look healthy from one perspective whilst quietly creating pressure somewhere else.
A design team might be on schedule, however development could already be absorbing additional work. A project manager might be planning work based on an original estimate, whilst the actual effort being invested into the project was already moving beyond that estimate. None of these situations were unusual, however they often became visible later than anybody would have liked.
Retrospectively, I think this was where Pathfinder Analytics started becoming more than a reporting platform.
The conversations were no longer centred around understanding what had happened. They were becoming focused on understanding what was likely to happen next.
That changed the way I approached planning within the product.
Rather than creating a standalone scheduling tool, I wanted planning to sit alongside project information, budgets, resource allocation and project updates. If somebody was reviewing a project, they shouldn’t need to jump between several systems to understand whether the project was healthy. The information should already be available in the same place.
My experience with UX (user experience) influenced a lot of this thinking. Internal software tends to fail when users are constantly switching context. Every time somebody moves between systems, spreadsheets and reports, there is a greater chance that information gets missed or interpreted differently. Over time those small inefficiencies compound into larger operational problems.
The planning area therefore became less about scheduling tasks and more about creating context around the decisions people were already making.
Additional Work Requests
One topic that appeared repeatedly throughout development was additional work.
Interestingly, it wasn’t initially part of the product roadmap.
The more project managers discussed project delivery, however, the more obvious it became that additional work was influencing almost every area of the business.
Most projects experience some level of additional work. A client requests a small amendment, asks for an additional page, requests support outside the original scope or changes direction midway through delivery. None of these things are particularly unusual and, in many cases, they’re entirely reasonable requests.
The challenge isn’t identifying additional work.
The challenge is understanding the impact.
If additional work isn’t recorded properly, project managers struggle to understand why budgets are changing. Finance struggles to understand profitability. Leadership struggles to understand which services are generating the greatest amount of unplanned effort. Over time, decisions start being made using incomplete information.
I wanted additional work to become part of the operational conversation rather than something hidden inside emails and project notes.
That meant connecting additional work requests directly to projects, departments, budgets and reporting. Once that information became visible, it created a much clearer picture of what was actually happening throughout project delivery.
One interesting observation after implementation was that additional work wasn’t always negative.
In some situations it highlighted scope issues.
In others it highlighted commercial opportunities.
A client requesting additional work can indicate project drift, however it can also indicate trust, growth and future revenue. Without the information being recorded properly, it’s difficult to distinguish between the two.
That became one of the more valuable aspects of the platform because it changed the conversation from assumptions to evidence.
Budget Management
Budget management was another area where the product evolved significantly after implementation.
Initially, the thinking was relatively straightforward. Projects have budgets, projects consume time, therefore the relationship between the two should be visible.
Once the system started being used in a live environment, the conversations became much more nuanced.
Project managers weren’t just interested in total hours. They wanted to understand where those hours were coming from. Finance wanted visibility into contractor costs. Leadership wanted to understand trends across multiple projects rather than reviewing each project individually.
The more information we gathered, the more obvious it became that budgets are rarely static.
Projects evolve.
Requirements change.
Additional work appears.
Departments become involved in ways that weren’t originally anticipated.
Because of this, I wanted budgeting to feel like an ongoing operational process rather than a number reviewed at the end of a project.
Retrospectively, I think this became one of the more important decisions within the platform.
Most businesses can tell you whether a project was profitable after it has finished.
The more difficult challenge is understanding profitability while the project is still active.
That was the area I wanted Pathfinder Analytics to support.
Not because it removes risk, but because it allows people to respond earlier.
Project Risk and Weekly Updates
As the platform matured, project risk became another natural addition.
I deliberately avoided turning Pathfinder Analytics into a CRM system because that wasn’t the purpose of the product. At the same time, project managers were regularly discussing concerns that weren’t visible anywhere else.
Sometimes those concerns related to budgets.
Sometimes they related to project delivery.
Sometimes they related to capacity, client relationships or resource allocation.
The common theme was that important information was being discussed, however it wasn’t always being captured.
Weekly project updates became an effective way of solving part of that problem.
Rather than relying on memory during project meetings, teams could maintain a history of project progress, blockers, concerns and key decisions. Over time, this created valuable context around how projects were evolving.
One unexpected benefit was that project reviews became much more productive.
Instead of spending the first part of a meeting trying to remember what happened last week, conversations could focus on decisions and actions.
That might sound like a small improvement, however when repeated across multiple projects over months and years, the impact becomes surprisingly significant.
Reporting, Finance and Understanding What Was Actually Happening
By the time planning, budgeting and additional work requests had started taking shape, reporting became a much easier conversation.
Interestingly, reporting was never really the starting point for Pathfinder Analytics. The discussions that led to the product were always operational discussions. Project managers wanted to understand project performance, finance wanted confidence in project budgets, leadership wanted a clearer understanding of workload and profitability. Reporting became important because people needed answers, not because they needed dashboards.
One thing I noticed during implementation was that most businesses already have access to a huge amount of information. The challenge is rarely the absence of data. The challenge is that the information is fragmented across different systems, different departments and different conversations.
A project manager might be looking at workload. Finance might be looking at costs. Leadership might be looking at profitability. Individually those perspectives are useful, however they rarely provide a complete picture on their own.
The thinking behind Pathfinder Analytics was always to create a shared understanding of what was happening across the business. If a project was consuming more time than expected, if contractor costs were increasing, if additional work was becoming a recurring issue, everyone should be looking at the same information.
Once that information existed in a single place, reporting became far more useful because it was no longer trying to compensate for missing context.
What Changed After Implementation
Implementing Pathfinder Analytics within HC Media Group was probably the most valuable part of the entire development process.
Building software in isolation is one thing. Watching people use it every day is something completely different.
Some ideas worked exactly as expected. Others evolved considerably once they became part of real project delivery.
One area that became far more important than I originally anticipated was additional work.
During the early stages of development, additional work requests were viewed as a supporting feature. Once the platform was being used day-to-day, it became obvious how frequently additional work influenced project performance, budgets and resource planning. What initially looked like a small operational process turned out to be connected to a significant number of commercial decisions.
Weekly updates evolved in a similar way.
Originally, they were intended to provide a simple history of project progress. Over time they became an important part of project reviews because they reduced the amount of information people needed to remember. Teams could review what had happened, what decisions had been made and what concerns had already been raised without relying on memory or searching through old meeting notes.
Retrospectively, one of the most useful things implementation provided wasn’t validation.
It was context.
Features that looked important during planning sometimes became less important once people started using the system. Equally, relatively small ideas often became surprisingly valuable once they were integrated into everyday workflows.
That process shaped the product far more than any roadmap ever could.
Thinking About UX In Internal Software
A large part of my role sits within development, however UX (user experience) has always influenced the way I approach software projects.
A lot of discussions around UX focus on interfaces, layouts and visual design. Whilst those things are obviously important, I’ve always been more interested in behaviour. How does somebody use the system every day? What information are they looking for? What decisions are they trying to make? Where are they likely to become frustrated?
Internal software is particularly interesting because people don’t use it occasionally.
They use it constantly.
A project manager might open the platform several times per day. Finance teams might review reports every month. Leadership might rely on the same information during quarterly planning sessions. Small usability issues compound surprisingly quickly when people interact with the same system repeatedly.
I think the concept behind the product development was always to create something that felt logical over time. Not just during the first week of use, but after months and years of repeated interaction. That’s one of the reasons why I spent so much time thinking about different user groups and how they would interact with the platform in practice.
The objective wasn’t to create the most feature-rich system possible.
The objective was to create a system that people would continue using because it genuinely helped them understand what was happening around them.
Retrospective Thoughts
Retrospectively, I don’t think Pathfinder Analytics is really a time-tracking platform.
Time tracking is certainly part of it, however the product has always been about something much broader.
The original discussions centred around timesheets because that was one of the most visible operational frustrations at the time. Once those conversations started, however, they naturally expanded into planning, budgeting, additional work requests, project risk, reporting and business performance.
Every problem seemed connected to another problem.
A discussion around time tracking became a discussion around project profitability.
A discussion around project planning became a discussion around capacity.
A discussion around additional work became a discussion around commercial opportunity.
The more we explored those relationships, the more the product evolved.
I think that’s very likely the most interesting thing about Pathfinder Analytics.
The product wasn’t built around a predefined list of features.
It evolved from real operational problems, real project discussions and real implementation inside a working agency environment.
Many of the features that exist today weren’t identified during the first conversations. They appeared because one challenge exposed another challenge, which then exposed another opportunity to improve the way information was being shared throughout the business.
That’s ultimately why Pathfinder Analytics exists.
Not because I wanted to build software.
Because I wanted to understand how information moves through a business, how people make decisions from that information, and how a well-designed internal system can help those decisions happen earlier, with greater confidence and with far less reliance on spreadsheets, disconnected systems and assumptions.
Final Thoughts
When people first hear about Pathfinder Analytics, they often assume it’s a time-tracking platform.
Retrospectively, I think that’s only a small part of the story.
The thinking behind the product was always centred around helping businesses understand what was happening across projects before problems became expensive, difficult or time-consuming to solve. Time tracking happened to be one of the first modules because it sat at the centre of so many operational discussions, however the product evolved into something much broader.
Planning, budgeting, additional work requests, reporting, project updates and project risk all became part of the conversation because they’re all connected. Understanding one area without understanding the others rarely tells the full story.
Implementing Pathfinder Analytics within HC Media Group reinforced that thinking. It provided the opportunity to see how people actually interacted with the platform, how operational challenges emerged in practice and how small improvements in visibility could influence decision-making across the business.
The product continues to evolve, however the underlying principle remains the same.
Help people understand what is happening, provide context around the decisions they need to make and create a system that remains useful not just today, but over weeks, months and years of everyday use.