From Internal Tool
to Scalable Platform
10 - 14
hours to compile a single report manually & concurrently across multiple clients
16
stakeholders interviewed across service lines and leadership levels
5 to 1
value propositions evaluated and narrowed to one focused, phased direction
Contents
My Role
Product Strategist
(embedded design consultant)
Client
Canadian professional services firm
Timeline
Early to mid 2025
Platform
"Nexus" – internal tax workflow tool
Background
The Problem with "Just Adding Features"
A platform built for internal efficiency gets a new mandate: generate revenue. What followed was a strategic ground-up rethink.
Originally built several years prior, Nexus was designed to streamline financial workflow processing – document collection, structured data gathering, and e-filing – for engagement teams at a large professional services firm. Over time, new functionality was layered on reactively, tailored to individual service lines without a coherent product vision. The result: a fragmented experience with uneven adoption across the organization.
In late 2024, executive leadership issued a directive that changed everything: Nexus was now expected to generate revenue. The platform would need to evolve from an internal workflow tool into a client-facing, monetizable product – with an existing team, existing infrastructure, and no clear playbook.
This created two simultaneous challenges. The first was strategic: identifying which opportunities were worth pursuing and what clients would actually pay for. The second was operational: understanding why Nexus wasn't being used consistently in the first place, and whether new features could gain traction if the adoption problem wasn't addressed first.
CPA Lens – Why This Context Mattered to Me Differently
My background as a public accountant meant I understood the operational reality of the firm's clients in a way a typical designer or PM might not. These were companies with complex financial data — trial balances with hundreds of columns, multi-tab workbooks, formula-dependent cells — and internal controls designed to ensure data integrity. I knew from day one that "financial data ingestion" wasn't a simple API call. That awareness shaped how I framed the opportunity and what risks I flagged early.
My role began as a contracted Product Designer embedded in the firm's technology innovation team. As product ownership gaps emerged – the product team experienced significant turnover mid-engagement – I stepped into a product strategy function without the title, driving discovery, defining product direction, and maintaining continuity as the initiative evolved.
Part 1: Defining the Opportunity
Turning a Broad Directive Into a Clear Direction
Five potential paths. Sixteen stakeholders. One fundamental question: what will clients actually pay for?
Research Approach
Before committing to any direction, I led a structured discovery phase alongside the go-to-market team to validate assumptions and pressure-test each opportunity. I designed and facilitated 16 stakeholder sessions with Directors, Partners, Senior Managers, and Managers across audit, advisory, and tax service lines – representing over 40 hours of research, validation and synthesis. Concepts were grounded using a clickable prototype to move conversations from abstract ideas to concrete reactions.
The goal wasn't idea generation – it was rigorous evaluation. I assessed each opportunity against three axes: what clients actually value, where current workflows break down, and what could realistically be monetized.
Five Value Propositions
01
Enhanced Client Portal
Unified "one-stop shop" for engagements and insights
02
Industry Insights & Benchmarking
Digital insight-driven benchmarking replacing a manual process
03
Regulatory Tax Data Integration
Centralized client tax data via regulatory API
04
Document Management
Streamlined workflows with access controls
05
Thought Leadership
Curated tax content; firm as trusted advisor
Key Insights from Discovery
01
The advisor relationship is the product
Clients derive the most value from different interaction with their advisors. Any digital experience would need to enhance – not replace – this relationship.
02
Adoption is the primary constraint
Many practitioners didn't consistently use Nexus due to workflow friction. New features alone wouldn't drive success without addressing adoption first.
03
Monetization must follow value
Stakeholders resisted paying for "standard" capabilities. Openness increased when tied to advisory value – insights, cross-service visibility, real-time data.
04
Internal behavior drives client behavior
Senior practitioners control both internal tool usage and client adoption. Internal workflows were the leverage point for the entire strategy.
CPA Lens – Defining Standard vs. Premium
My audit background gave me a useful mental model for the monetization question. In financial reporting, you distinguish between controls that are required (baseline compliance) and those that provide differentiated assurance. I applied this same framing to the product: capabilities like document access and basic communication are table stakes. Monetizable value lives in the advisory layer – contextual insights, cross-service benchmarking, and proactive risk identification.
Reframing the Opportunity
As research progressed, it became clear that the initial framing — particularly within Industry Insights & Benchmarking — was incomplete. While early discussions focused on enhancing the client-facing experience, findings revealed that many of the core challenges existed within the internal report compilation process itself.
This led to several key realizations:
Improving the visual design of the report alone would not drive adoption of Nexus
The client-facing output wasn't the bottleneck — the process required to produce it was. A more polished report wouldn't change the fact that practitioners were avoiding the workflow entirely.
Internal workflow efficiency would significantly impact report creation and usage
Reports were taking 10 to 14 hours to compile across multiple clients simultaneously — and many engagement teams were skipping them altogether because of the time required. The real opportunity was reducing that burden.
The report was already distributed as part of existing engagements, making monetization less straightforward
Because clients already expected the report as part of their engagement, charging for it separately introduced friction. The path forward wasn't standalone monetization — it was making the report more valuable and consistent so it could support broader platform stickiness.
"The focus shifted from pursuing a revenue-generating concept to defining a foundational product experience that would be integrated into existing workflows."
Based on these insights, the opportunity was reframed to focus on improving internal workflows and enabling a more scalable reporting experience across service lines. This direction was presented to stakeholders and approved — and it set the stage for the Tempo workstream explored in Part 2.
Part 2: Shaping the Product
Translating Direction Into a Real Product Experience
With a focused opportunity defined, the work shifted from discovery to product definition — structuring features, mapping workflows, and navigating a complex set of dependencies and tradeoffs.
Enter "Setting the Tempo"
Building on the findings from Part 1, my focus shifted from exploring multiple product opportunities to defining a more targeted product direction. Early discovery research around Industry Insights & Benchmarking revealed that the primary challenge was not the client-facing experience, but the internal workflows required to generate meaningful insights. The process was highly manual and relied heavily on senior practitioners — much of the relevant client knowledge lived with these individuals, resulting in reports being compiled at the end of engagements under significant time constraints. While there was interest in shifting compilation to more junior team members, they often lacked the foundational context needed to generate meaningful insights, making that transfer — particularly in the first year — not feasible.
The delivery model reinforced these challenges. Reports were typically shared via email and followed by an in-person partner-client meeting — face-to-face touchpoints the firm considered a key differentiator. But by the time these discussions occurred, often months after a client's period-end, much of the financial information being reviewed was already known. Clients were less interested in retrospective reporting and more focused on understanding risks and opportunities going forward. Despite its intended value, the existing process was inconsistent and resource-intensive — with practitioners often spending more time gathering and formatting inputs than generating meaningful insights. This led to a shift in focus: from monetization to enablement.
Existing Report: Dense & Outdated
My Role in This Phase
As the Tempo workstream progressed, ownership was not always clearly defined. A new product lead joined midstream without prior context, and stakeholder involvement shifted across Enterprise, product, and marketing teams. In response, I took on a more active role in maintaining continuity — bringing new contributors up to speed, grounding conversations in prior research, and ensuring alignment as the direction evolved alongside shifting team dynamics.
Reframing the Opportunity
At the outset, Tempo was loosely defined as a digital version of the existing Industry Insights & Benchmarking report. As we explored the problem space, it became clear that simply replicating the report in a digital format would not address the underlying issues. To better understand what the product needed to support, I analyzed existing report templates, training materials, and guidance created by the Enterprise team. This work surfaced the core inputs required to both initiate report creation and confidently sign off on its contents.
This exercise revealed that the report was not just a static output, but the result of a convoluted and often inconsistent process — one that relied heavily on practitioner knowledge. A key question that emerged from this work:
"How might we enable practitioners to contribute to report creation earlier in the engagement lifecycle, rather than treating it as an end-of-process task?"
This reframed how the product needed to be defined. Rather than focusing solely on the final report, Tempo was positioned as a system that supports ongoing input and insight generation throughout the lifecycle of an engagement — reducing the burden at the end of the process while improving the relevance and quality of insights delivered to clients.
Feature & Workflow Design
To translate the product definition into an actionable direction, I mapped the current-state report compilation process end-to-end — documenting how inputs were gathered, how different roles contributed, and where dependencies existed across service lines. This surfaced gaps, clarified open questions, and established a shared understanding of the workflow as a foundation for defining a future-state experience.
Current-State Process Flow
In parallel, I translated research insights into a structured feature database, enabling more concrete discussions with engineering around feasibility, dependencies, and effort. Features were based on patterns identified in discovery and refined through ongoing stakeholder engagement. Early assumptions suggested report creation could be distributed across multiple roles — but further discussions confirmed that senior practitioners would remain critical, at least initially. The product needed to support that dependency while gradually introducing structure to enable broader participation over time.
Setting the Tempo — Capturing Inputs Over Time
To address this, I originated a concept I called "Setting the Tempo" — the idea that report creation shouldn't be a sprint at the end of an engagement, but a continuous process of capturing inputs throughout the engagement lifecycle.
This approach was informed by existing training materials, including screener questions used to guide report preparation. By incorporating these prompts into a structured digital workflow, the product could guide practitioners to capture relevant context earlier and more consistently — reducing reliance on memory while providing a clearer reason for senior practitioners to engage with the Nexus platform over time. Structuring these inputs also introduced opportunities for future capabilities, such as identifying risks and opportunities, surfacing relevant content, and supporting more proactive, insight-driven conversations.
Setting the Tempo - Screener Questions
CPA Lens — Process Risk and "What Could Go Wrong"
In public accounting, internal controls testing involves documenting business processes, identifying risk points — what we called "what could go wrong" — and verifying that controls exist to mitigate those risks. I applied this same thinking to the Tempo workflow. Where was the process most likely to break down? At the handoff between senior and junior practitioners. At the moment of data ingestion. At the review step before sign-off. Designing around these failure points — rather than assuming a happy path — shaped how I structured the feature requirements and which safeguards I recommended building in from day one.
The Data Ingestion Problem — A Risk I Flagged Early
One of the most consequential contributions I made in this phase came directly from my accounting background. A core future-state goal for Tempo was real-time financial data integration. But I knew from years of working with client financial data that trial balances are rarely clean — multi-tab spreadsheets with hundreds of columns, formula-dependent cells, and firm-specific GL account structures that don't map consistently across clients or industries.
I raised this with stakeholders, who confirmed the concern. We made the decision to prioritize clients whose financial data was already mapped to structures we understood — and decided to address clients that would require a more flexible data ingestion option for later releases. This avoided a significant technical and operational risk that could have derailed the Phase 1 roadmap entirely. I also knew that mapping GL accounts and testing outputs would be a time-consuming and detailed process — another reason to be deliberate about sequencing.
Stakeholder Alignment
Given the scope and complexity of Tempo, aligning stakeholders across teams was a critical part of the process. I worked across Enterprise stakeholders, product, design, and engineering — each with differing priorities, levels of context, and expectations. Stakeholder involvement also evolved over time, requiring continuous alignment as new contributors joined and others transitioned off the project.
To support this, I facilitated recurring working sessions grounded in research findings and current- and future-state workflows, helping teams converge on a realistic product definition. I used artifacts such as process flows, structured feature sets, and phased approaches to anchor discussions and maintain a shared understanding of both the problem and proposed solutions. A key part of this role was translating between different perspectives — balancing business expectations, technical constraints, and user needs to guide decision-making toward outcomes that were both valuable and feasible.
Feature Overlap Analysis
Future State Process Flows
Phased Approach
Phase 1 – Foundation
Make It Operational & Drive Adoption
Bring report compilation into Nexus
"Setting the Tempo" – structured inputs throughout engagement
Reduce manual effort and reliance on practitioner memory
Simplified, insight-driven report output
Collect structured data to support future AI capabilities
Phase 2 – Expansion
Layer Intelligence on a Stable Foundation
Real-time financial data integration
AI-assisted insight and risk identification
Personalized, proactive client recommendations
Scenario analysis tools for advisory conversations
Cross-service client visibility
Key Tradeoffs Navigated
Internal workflow over client-facing polish
Research showed the bottleneck was upstream. A beautiful client report wouldn't matter if the process generating it was still broken. We prioritized internal workflow enablement first.
Maintained senior practitioner dependency short-term
Pressure to democratize report creation existed, but removing senior practitioners too quickly risked report quality. The product was designed to support existing workflows first.
Deferred AI and real-time data capabilities
Without structured input data and a stable ingestion layer, advanced features had no foundation. Phase 1 was explicitly about building the data infrastructure they'd require.
Engagement-based reporting over cross-service view
The original vision was a comprehensive multi-service-line view. Platform limitations made this unrealistic in Phase 1. We scoped to individual engagements while preserving the long-term vision.
Outcome
By the end of this phase, Tempo had a clearly defined product direction grounded in both research and practical constraints. The initiative shifted from enhancing a client-facing report to addressing a more fundamental challenge: improving the internal workflow required to generate meaningful insights. Key outcomes included a reframed problem space centered on workflow, scalability, and insight generation; a structured set of features and workflows aligned to practitioner needs and platform constraints; a phased approach balancing immediate usability with long-term product potential; and alignment across stakeholders on scope, priorities, and next steps.
While the product had not yet been built or released, this work established a clear and actionable foundation for development — ensuring future efforts were grounded in a shared understanding of both the opportunity and its constraints. This direction also set the stage for the operational and adoption challenges explored in Part 3.
Tempo Report - Overview
Part 3: Designing for Scale
What Must Change for a Product to Scale
Product definition is necessary but not sufficient. The harder questions are about adoption, measurement, and organizational readiness.
System-Level Observations
As the Tempo workstream matured, a set of structural risks became increasingly visible — risks that had less to do with features than with the organizational context the product was being deployed into.
Adoption depended almost entirely on senior practitioner behavior. Without their engagement, broader adoption of Nexus and Tempo would be difficult to achieve. Workflow expectations were misaligned with reality — although there was interest in shifting report creation to junior practitioners, the process continued to rely on senior-level context and decision-making. Data and infrastructure readiness were inconsistent — dependencies such as financial data ingestion, third-party tools, and internal resource repositories introduced uncertainty around what could be reliably delivered. And perhaps most significantly, success metrics were not clearly defined — there was limited visibility into how success would be measured, making it difficult to evaluate adoption, efficiency, or impact over time.
CPA Lens — Segregation of Duties & Data Trust
One of the most important concepts in financial reporting controls is segregation of duties: ensuring that the person who creates data isn't the same person who reviews or approves it. I applied this lens to the Tempo workflow design — specifically around who should contribute inputs, who should review them, and who should sign off. For any AI-assisted insight generation to be trustworthy in Phase 2, the inputs feeding it needed to be collected, reviewed, and corrected through a structured process from day one.
Defining Success: A KPI Framework
One of the most significant gaps I identified was the absence of clearly defined success metrics. I proposed a three-category KPI structure to address this.
Adoption & Usage
% of engagement teams actively using the platform
Frequency of inputs captured throughout engagement
Participation rate: senior vs. junior practitioners
Workflow Efficiency
Time to compile report (target: reduce from 10–14 hrs)
Reduction in manual data gathering steps
Number of revision cycles per report
Business Impact
% of reports used in client advisory conversations
Practitioner confidence across industry contexts
Downstream risks, opportunities, or upsells identified
What I Would Prioritize Differently
Earlier investment in adoption and change management
Technical readiness and user readiness aren't the same thing. A structured onboarding plan — built alongside the product, not after it — would have reduced the friction that made adoption the primary risk.
Clearer role ownership across the workflow
Ambiguity about who owned which step created recurring alignment friction. Defining RACI-style ownership earlier would have reduced the number of working sessions needed to resolve the same questions.
Success metrics defined at kickoff, not retrospectively
KPIs proposed late can feel like post-hoc rationalization. Establishing shared success criteria at the start of discovery would have aligned stakeholders on what "working" actually meant.
AI-readiness framed as a data strategy, not a future feature
The most sophisticated capabilities stakeholders wanted were dependent on clean, structured, consistently captured data. That dependency should have been articulated as a product principle from the start.
System-Level Takeaway
This work reinforced that product success is not determined solely by feature development, but by the system in which the product operates. Adoption, workflow alignment, data readiness, and measurement all play a critical role in determining whether a product can scale effectively. This experience expanded my perspective from defining product features to thinking more holistically about product systems — considering not just what is built, but how it is adopted, measured, and evolved over time.
Reflection
What This Work Is Really About
This case study is, on the surface, about a benchmarking report and an internal workflow tool. But the deeper arc is about something that matters a lot in the fintech context: the gap between building a product and building the conditions for a product to succeed.
My CPA background gave me an unusual vantage point on this work. Auditors are trained to look for where processes break, where data can't be trusted, and where controls are missing — not to be pessimistic, but to build systems that are actually reliable. That instinct translated directly into how I approached product strategy here: not just "what should we build" but "what has to be true for this to work, and is it true yet?"
The 10-to-14-hour report wasn't a design problem. It was a data capture problem, a workflow ownership problem, and an adoption problem — and solving it required understanding all three before committing to a single feature. That's the kind of thinking I bring to product work, and it comes from a background that was never supposed to lead to product strategy — but turns out to be surprisingly well-suited for it.
The initiative I shaped — including the "Setting the Tempo" concept I originated — moved into development. The strategy held. That's the outcome that matters most to me in a portfolio piece: not that the work was polished, but that it was grounded, and it moved something forward.
Next Case Study
E-Commerce Redesign
UX Design · Bootcamp
Work Sample
Claims Process Redesign
Client Work · Healthcare · Process Design
Work Sample
Future Product Vision
Client Work · Product Strategy · Process Design