Category: Technical Insights

Walk into any mid-market operations team, and you’ll find something oddly familiar: dashboards nobody fully trusts, reports people won’t act on without looping in an analyst, and process insights that sit idle until someone with a technical background gives the green light.

The tools exist, and the data is there. But things still don’t move at market speed!

The real problem isn’t data quality or integration but user confidence. It’s the UX problem that rarely makes it into boardroom conversations.

The Trap of Aesthetics

Enterprise software has spent a decade competing on visual polish. From gradient cards, micro-animations to flawless colour systems, the pitch has been more or less the same: We made complexity beautiful.

However, here’s the problem. Aesthetics without capability is a distraction. A stunning chart that still needs a data scientist to interpret doesn’t move anything forward. A ‘frictionless onboarding experience’ that routes users into an interface they can’t navigate quietly erodes trust.

Gartner has consistently flagged poor data literacy, and not data quality, as a primary blocker to analytics adoption. McKinsey reports that 77% of companies lack the data talent needed for mission-critical tasks, and no amount of interface polish will close that gap.

Process mining platforms have been especially affected by this. The technology is transformative. But early tools were built for data scientists and consultants, not for the supply chain manager who needs to understand why the order-to-cash cycle is running 11 days over target before they can make a call.

Self-Service as a Design Philosophy

Self-service in enterprise software is mostly seen within a limited scope: run a query without raising a ticket, build a report without emailing IT. While such capabilities are useful, they mostly miss the bigger picture.

True self-service starts with the question: How do we make users feel genuinely capable?

Capability and feeling capable are not the same thing. A power user may objectively be able to run a conformance check. However, if the interface doesn’t clearly communicate what the outcome means, they will hesitate to run the check in the first place. Hesitation leads to deferring and deferring leads to analyst dependency on routine questions.

That’s where enterprise software ROI disappears!

It hits hardest in the mid-market. Businesses at the mid-market scale rarely have dedicated analytics teams alongside every function head. For instance, here, we often find the operations director doubling as an analyst or the CFO acting as a BI user on an ad hoc basis.

These are domain experts with very little patience for tools that make them feel out of their depth.

An Interface That Inspires Confidence

Designing for confidence requires understanding not just what users want to do, but what makes them anxious about being wrong in a professional context.

Here’s an example. When an operations manager opens a process mining tool and sees a spaghetti map with 47 variants, the first instinct isn’t curiosity but a sense of being overwhelmed! It is followed by a decision to wait until someone can walk them through it. That moment of hesitation is when the product fails.

To address this, a confidence-first design works through four principles:

• Progressive disclosure with purpose or showing things in the right sequence. The first view should answer the question: Is this process behaving as designed? Everything else should be available as a drill-down, not as a default.
• Contextual confidence signals that tell users not just what the data shows, but how reliable it is and what a finding typically means in context. Reliability of communication is the most important element of enterprise UX.
• Guided action, not guided navigation. It is the line between a good-to-have toy and a must-have tool. “Your PO approval step is running 3.4 days slower than your industry benchmark. Here’s how to investigate,” is an action guidance. Unlike a tooltip attached to a filter!
• Forgiveness and reversibility. Users who fear making irreversible mistakes avoid exploration. UX aids like the undo functionality, sandbox modes, and clear preview states turn passive consumers into active investigators.

FUTUROOT Control Tower: What Confidence-First UX Looks Like in Practice

Now, let’s see how these principles work together to deliver a great product.

The FUTUROOT Control Tower is an AI-powered live command centre for monitoring SLAs, detecting process risks, and investigating bottlenecks. But the more interesting design story is in how it handles the confidence problem.

The Intelligent KPI Layer lets users create metrics in plain language:

“Invoices pending approval for more than five days” or “Orders delayed beyond SLA.” No configuration screens or technical setup needed! The system automatically converts the question into a live KPI. Users start with their operational question, not with a tool they need to learn first.

The AI Copilot goes a step further. When an SLA is at risk, it doesn’t just surface an alert. It explains why the delay is happening and recommends specific actions based on patterns in your data. The operations lead doesn’t need to loop in a specialist for interpretation. The context to make a call is right there, in language they can act on immediately.

Role-specific dashboards tackle another persistent UX pitfall: the one-size-fits-all interface.

For example, a CFO and a procurement analyst are working from the same data, but they need entirely different views of it. Configurable command centres reduce the cognitive load that causes hesitation. The CFO and the procurement analyst see only what matters to them, without having to dig through everything else.

These aren’t surface-level design choices but reflect a product built for the person doing the operational work, not the consultant who implements it. That distinction changes everything, from how alerts are written to how drill-downs are structured.

You can find out more about the FUTUROOT Control Tower here.

The Mid-Market at a Crossroads

Process mining is at a very exciting moment! The technology has matured, cloud delivery has levelled the playing field for infrastructure, and a new generation of platforms is emerging with a clear goal: making process intelligence accessible to the people doing the work, not just the consultants analysing it.

The global process mining market is projected to reach USD 12 billion by 2028, at a 45% CAGR. That growth is being driven by organisations finding tools they can actually use without massive upfront investment. The platforms that get ahead of the rest do not have the most sophisticated algorithms. Instead, they make a process improvement lead feel like an expert by day three, not after three months of training!  

After all, a user who completes every task yet has to refer every real question to the data experts in the BI team hasn’t really been empowered. On the other hand, a user who independently identifies a rogue approval workflow costing six weeks of working capital per year is the one that FUTUROOT is designing for.

The Conversation Worth Having Now

Design leaders, product managers, and platform buyers need to hold each other to a higher standard than visual quality. The right questions aren’t whether a platform looks professional. They are:

• Can my team use this without asking for help on day one?
• Does this interface make my team feel capable or dependent?
• Does this product actively close the gap between insight and action?

These are the questions that will determine whether process intelligence becomes a genuine competitive advantage or remains a sophisticated tool used by a small technical core, generating reports that operational teams act on only slowly.

The technology is ready, and the demand is clear. What the market needs now is a confidence layer that shows people what’s happening in their business and gives them the nerve to do something about it – Independently, immediately and without waiting for permissions from the ‘experts!’

Because aesthetics is incidental, building end-user confidence is the actual goal.

There is a specific kind of meeting that every technology leader wishes they didn’t have to have. It is one in which a client informs you that the platform cannot do what their business actually needs. It is not a feature request or a wish list item, but a structural limitation that no amount of configuration changes or workaround can resolve!  

At FUTUROOT, we had such a meeting last year. A mid-market manufacturer had uploaded roughly 140 million process events into our platform. The volume is predictable as shift changes, machine state transitions, quality checkpoints, logistics handoffs: modern factories generate event data at a blistering pace, even for mid-sized businesses.

However, what happened next caught us off guard. Query response times measured in seconds were stretching toward minutes. Dashboards that process owners relied on for daily operational decisions began timing out.

It was a clear call to action for improvement, and our decision to tackle it set in motion 21 days of the most concentrated engineering work we have done as a company.

A Common Assumption About DB Architectures

Process mining emerged primarily in academic computing environments. In early enterprise deployments, data volumes were modest, and query patterns were predictable. Therefore, the approach was straightforward — storing event logs in relational tables, indexing on case ID and timestamp, running conformance and performance queries across those indexes. This approach, although elegant in theory, is prone to failure at scale!

The problem is not the relational model itself, but the fact that event data has a structure that conflicts with relational assumptions at scale.

Process events are append-only in practice. They are queried almost always by case journey, not by individual attribute. And critically, the analytical patterns that generate business value, such as cycle time distributions, bottleneck identification, and variant analysis, require repeatedly reconstructing sequences across tens or hundreds of millions of rows.

Standard columnar warehouses handle this better than row-oriented databases. However, even columnar storage encounters friction when the query is for drill-down visibility into a case’s journey rather than an aggregated view.

The industry is not unfamiliar with this limitation. The acknowledgement is that the architecture will scale well in most cases. However, in the mid-market context, where data volumes are large, and budgets are too constrained to absorb the cost of expensive workarounds, things might go sideways.

The global process mining market is growing at a 34% CAGR, with accelerated adoption in the mid-market. The customers arriving now will not be bringing clean, curated datasets, but rather the raw operational exhaust of genuinely complex businesses. The architecture decisions made today will determine whether those customers stay or leave within eighteen months.

How FUTUROOT Made a Breakthrough in Three Weeks

Let me explain what made those three weeks defining for Team FUTUROOT. We had a mandate with a constraint: the client’s data could not move to a different storage system. They had compliance requirements, data residency considerations, and an IT governance framework that made migration off their existing infrastructure a challenge on any reasonable timeline.

However, that constraint, which initially felt like a wall, turned out to be an innovation pathway!

With no option to change the storage, we turned our focus to reimagine the query layer, and we started asking questions about pre-computation we had never asked before — which analytical results should be materialised at ingest time rather than computed at query time? In process mining terms: instead of reconstructing case journeys on every query, what if the journey graph were assembled incrementally as events arrive, and stored in a structure optimised for traversal rather than for tabular retrieval?

What emerged over those three weeks was not a new database but a new layer of intelligence sitting between the event log and the query engine.

The core idea is straightforward: as events are loaded, they are simultaneously used to update a compact, traversable representation of the case graph. Queries for variant analysis, bottleneck detection, and path frequency do not access the raw event log. Instead, they traverse the graph. While the raw log serves as the source of truth for auditability, the graph serves as the source of performance.

The results were measurable and immediate. Queries that had been running for over two minutes returned in sub-seconds, and dashboard load time dropped by more than 80% —outcomes made possible simply with the arithmetic of not recomputing what we already know!

Customer Reality Guiding Innovation

As a technology leader, I believe that the phrase ‘customer-driven innovation’ is highly generalised (and sometimes misused) in the industry today. More often than not, it is used to describe a process where you build what you planned to build, then confirm that customers wanted it.

Genuine customer-driven innovation, on the other hand, is messier, more disruptive, and frankly more valuable.

The distinction is important because it determines the source of inspiration. Internal roadmaps are optimised for plausibility. They reflect what the engineering team believes is achievable within a sprint cycle, what the product team believes customers will respond to positively, and what the commercial team believes can be positioned competitively.

While all of those filters are useful, none of them generates the kind of pressure that forces a rethink of foundational assumptions. It is where client reality plays its part. A business in pain is not asking to reconsider the architecture. They are indicating, through their operational distress, exactly where the assumptions failed to anticipate the real world!

The 2023 State of Data Engineering report found that 67% of enterprise data teams cited ‘query performance at scale’ as their most persistent infrastructure challenge. The problem that our manufacturing client ran into also pivots on performance. In fact, it is the central experience of organisations that have committed to data-driven operations and are now discovering that the infrastructure beneath them was not designed for the volumes they are generating.

Here, the mid-market companies are particularly exposed because they lack the engineering resources to build bespoke solutions and the leverage to demand custom architecture from enterprise vendors. Here, the gap between vendor promises and operational reality is widest. Addressing that gap with genuine architectural responses rather than configuration workarounds is both a commercial opportunity and a responsibility that comes with serving this segment.

The Lessons Learned

The capabilities built during the engagement went into general availability on FUTUROOT six months after the initial sprint. But the real takeaway of those three weeks was a set of principles that have since reshaped how we approach architectural decisions across the platform. I would list them as follows:

• Optimise for the query pattern, not the storage model.

 While this sounds obvious, in practice, it requires resisting the massive gravitational pull of convention! Columnar storage became the default for analytical workloads because it is genuinely excellent for aggregate queries across large datasets. However, it is not the right tool for graph traversal at the case level. Knowing that distinction and being willing to innovate around it is the difference between a platform that performs and one that merely functions.

• Pre-computation is a first-class design decision, not a performance optimisation.

In most development cultures, caching and pre-computation are tools for solving a performance problem. However, in a system where query patterns are known and data arrives in predictable structures, pre-computation should be built in from the beginning, not as an afterthought.

• Client escalations are architecture reviews in disguise.

When a client tells us something is not working, they are not just reporting a bug but telling us about assumptions hard-coded in the system that do not match operational reality. Treating those conversations as architectural input, rather than as support tickets to be resolved and closed, changes what can be learned from them.

The Process Mining Infrastructure That the Mid-market Truly Deserves

Mid-market companies have, for too long, been treated as a segment that needs enterprise capability but must accept enterprise compromise, scaled down. The assumption is that architecture designed for large enterprises will accommodate mid-market volumes by default. However, that is not the case, and that is why the mid-market company often lacks the technical resources to diagnose the failure, the commercial leverage to demand a fix, and the financial runway to absorb the disruption.

Here, process mining platforms like FUTUROOT serving this segment have an obligation to build an architecture from scratch that is honest about where it will break. Mid-market operations generate substantial data volumes and deserve an architecture that accounts for failure modes and strategies to manage them.

The Conversation We Must be Having

The argument here is not that every process mining vendor has hidden architectural debt they are refusing to acknowledge. However, the industry conversation needs to adequately acknowledge the distinction between scale at the enterprise tier, where dedicated engineering teams, significant infrastructure budgets, and bespoke deployments absorb the friction, and scale in the mid-market, where none of those buffers exists.

FUTUROOT’s experience with the mid-market manufacturing client allowed us to meet head-on a standing assumption: that our event log architecture would handle the volume growth of even the most data-intensive clients without architectural intervention. Uncomfortable as it was, it allowed FUTUROOT to rethink and evolve our database architecture at market speed.

A product team that learns from a client’s operational pain and builds it into the architecture is doing something fundamentally different from one that routes that pain through the support queue. While one offers a solution, the other is merely adding to the workaround backlog!

FUTUROOT has and will always choose the former approach to treat customer pain at its root, rather than offering a band-aid.

In the early years of my career, success was easy to define.

Ship the feature.
Ship it on time.
Ship it clean.

Coming from a deep technical background, I was obsessed with execution. Writing good code, closing tickets, meeting sprint commitments—those were the metrics that mattered. If you had asked me five years ago what I was working on, I probably wouldn’t have had a meaningful answer. It didn’t matter. What mattered was that the code worked and went live.

I was talking to my scrum master, my lead engineer, and a small circle of developers. The end user was a distant concept—somewhere beyond the backlog, outside my immediate responsibility.

That mindset helped me become a strong engineer. But it also blinded me to something far more important: products are not judged by what they ship, but by what they enable.

The Advice I Didn’t Fully Understand

As I grew into a Lead Engineer role, my CTO would often repeat a line that felt vague at the time:

“Think from the user’s standpoint.”

I agreed with it in principle, but in practice, I didn’t truly get it. The requirements were already defined. The roadmap was locked. The feature was approved. What exactly was left to think about?

In hindsight, I was confusing delivery with value.

It wasn’t until I started joining customer conversations—beyond demos and sprint reviews—that the gap became impossible to ignore.

When Client Conversations Changed My Perspective

It was only when I started joining client conversations that the shift became real. I noticed that stakeholders rarely talked about features. Instead, they spoke about outcomes — what they needed to achieve, the problems they were solving, and how they were approaching solutions in their own context.

That’s when I began to see the bigger picture: delivering a feature is one thing, but enabling a capability is another. Slowly, almost imperceptibly, my thinking started to shift—from counting features shipped to understanding the capabilities those features unlocked for users.

Features vs Capabilities: A Simple but Powerful Distinction

Once I started seeing how stakeholders approached problems, the difference became clear.

A feature answers the question: “What did we build?”

A capability answers: “What can the user now achieve?”

Features are internal milestones, checkpoints for the team. Capabilities are the external value—the real impact on the user’s work. Users don’t buy dashboards, filters, or connectors—they buy the ability to understand, decide, act, and improve.

This distinction matters because a product can ship hundreds of features each quarter, but adoption will still lag if those features don’t translate into usable capabilities.

The Moments That Changed How We Think About Capabilities

The shift from feature-led thinking to capability-led thinking didn’t happen overnight. It happened through a couple of very specific moments that forced us to look beyond what the product could do and focus on how quickly and effectively customers could use it.

Incident 1: When Insight Was Right—but Too Late

We were once deep into a deal with a client who was already evaluating multiple process intelligence platforms. They liked FUTUROOT’s UI, the depth of features, and the overall approach. On paper, we were at par—if not ahead—especially given the combined ERP and consulting experience behind the product.

Yet, we lost the deal late in the cycle.

The reason had nothing to do with missing functionality.

What we didn’t have at the time were accelerators that could get them insight-ready quickly. The client would have needed an additional two to three weeks of setup before meaningful insights could be generated.

That delay mattered.

It forced an uncomfortable realization:
insights are only valuable if they arrive when decisions are being made.

This was the moment we understood that capability isn’t just about what the product delivers—it’s also about how fast it delivers it. That realization led directly to building scenario-based, pre-built packages designed to make customers insight-ready from day zero, right after data loads.

Incident 2: When Assessment Wasn’t Enough

FUTUROOT, backed by Percipere, brings over 500 years of combined ERP transformation and consulting experience. While using FUTUROOT to assess SAP ECC systems for landscape transformation, we started noticing a recurring pattern.

Customers valued the analysis—but they struggled with what came next.

The assessment clearly showed what needed to change. But execution still demanded significant manual effort, coordination, and time. That gap slowed down transformation programs and exhausted teams.

So we pushed capability thinking a step further.

The goal wasn’t to add another feature.

It was to remove friction at the most painful stage of transformation—turning insight into execution—by reducing preparation effort and accelerating progress.

Why Feature-Led Thinking Can Stall Products

Adding more features doesn’t automatically translate to better outcomes. Adoption often fails not because products lack functionality, but because complexity prevents users from realizing the value.

Some common symptoms of feature-heavy products include:

• Overloaded interfaces
• Endless configuration options with unclear payoff  
• Steep learning curves
• Heavy reliance on specialists or consultants

Without a capability-first approach, products become toolkits for experts rather than enablers for teams. In process intelligence and enterprise workflows, this is especially risky: if understanding the system becomes harder than doing the work, adoption stalls—and value remains locked away.

Capabilities Are Designed Around Outcomes

Capabilities are not just features with a fancier name—they are what the user can do with the product in practice. Strong capabilities share a few consistent traits:

• They Align With Real User Workflows
  • Capabilities reflect how people actually operate, not how the system designers wish they did. In industries like manufacturing, retail, finance, and procurement, this means accounting for exceptions, variations, and real-world constraints..
• They Reduce Effort, Not Just Add Power
  • The best capabilities simplify processes and make results intuitive. Complexity remains under the hood.
• They Scale Across Experience Levels
  • A first-time user should get value quickly. An experienced user should be able to go deeper without requiring a different product.
• They Deliver Impact Even When Used Lightly
  • A well-designed capability should provide measurable benefit even if a user engages with only part of the functionality.
    

These are features carefully curated to enable users with the right capabilities—to improve ROI, give them control over their processes, make insights actionable, and help teams continuously drive better outcomes.

The Shift Every Product Manager Must Make

Moving from a feature-first to a capability-first mindset is about asking the right questions:

• What decision does this help the user make?
• What friction does this remove from their workflow? 
• How does this change the user’s day?
• Are we simplifying—or adding another layer?

This is where product, design, and engineering must work as one. Not to ship more—but to enable better outcomes.

Product management taught me how to listen.

Today, when I review a roadmap, I don’t count features. I look for strengthened capabilities. If a feature doesn’t clearly improve what users can do, it doesn’t belong—no matter how elegant the implementation. That shift in thinking changed the way I build products—and the impact they create.

Capabilities We’re Building at FUTUROOT

If capabilities are about enabling outcomes, here’s how FUTUROOT is putting that philosophy into practice, with tangible examples:

• Marketplace Accelerator Packages: Install and Go
  • Teams can seamlessly connect to their ERP systems and kickstart their Process Intelligence journey using FUTUROOT’s Marketplace Accelerator Packages. These pre-built, S/4-ready packages are designed to minimize setup and configuration effort, allowing users to start realizing value almost immediately.
  • The accelerator packages deliver instant process visibility and system health insights, support audit and compliance readiness across industries, and provide a centralized control view to track adoption and improvement progress over monthly and quarterly intervals. By packaging proven capabilities together, they remove friction from onboarding and help teams move faster from insight to sustained impact—without heavy customization or long lead times.

• Enhanced User Experience
  • Interfaces are designed to minimize friction and surface insights clearly, helping finance, procurement, manufacturing, and retail teams navigate complex processes without heavy training.
• Co-Pilots with Tuned MCP Models
  • Co-pilots are tuned for specific processes, guiding users through workflows, highlighting exceptions, and suggesting next best actions to improve outcomes.
• Predictive Analytics for Enterprise Workflows
  • From identifying bottlenecks in procurement to predicting exceptions in order-to-cash, these capabilities help teams act proactively rather than reactively.

These are features carefully curated to enable users with the right capabilities—to improve ROI, give them control over their processes, make insights actionable, and help teams continuously drive better outcomes.

My Personal Reflection

In process-driven organizations, complexity already exists. Software shouldn’t add to it—it should help manage it. By focusing on capabilities rather than outputs, products become easier to adopt, insights become actionable, and improvement becomes a natural part of the workflow.

Features are important, but they are not the measure of impact. Capabilities are. When we build products that truly strengthen what users can do, the results are meaningful, lasting, and genuinely useful.