How I Work

Before I look at a single line of code or a single product roadmap, I need to understand what the business is trying to achieve and how it plans to get there. This isn't a formality. It's the frame that every other finding gets evaluated against.

I use a structured strategic alignment approach built around five questions: What is your winning aspiration? Where will you play? How will you win? What capabilities must be in place? What management systems are required? Those questions, aligned with investor expectations, establish the context that makes every downstream assessment meaningful.

Without this step, technology findings float in a vacuum. A high level of technical debt might be acceptable in a company preparing for rapid growth into new markets, and catastrophic in a company optimizing for margin improvement. The business strategy determines which.

Most PE-backed SaaS companies have more than one product, especially those built through acquisition. I classify every product by lifecycle stage (growth, sustain, migrate, or sunset), and that classification drives investment allocation, team structure, roadmap priorities, go-to-market approach, and financial targets.

At this layer I build or validate a per-product P&L. Most companies manage finances at the company level: total revenue, total cost. They can't tell you what each product earns, what it costs to operate, or what its EBITDA contribution is. That per-product visibility is what makes portfolio decisions data-driven rather than political.

Retention and churn are the clearest signals of product health. At the portfolio level, I evaluate retention dynamics by product: where churn is concentrated, what's driving it, and how it connects to the product experience and competitive landscape. A portfolio that looks healthy at the company level can hide a churn problem quietly eroding the growth story.

Each product needs its own strategy aligned to its lifecycle stage and portfolio priorities. At this layer I work on individual product strategy: vision, target market and personas, customer benefits, standout capabilities, monetization, investment priorities, technology requirements, and success metrics.

Each product also needs a cross-functional team empowered to execute that strategy, not just a product manager writing a roadmap in isolation. I design or restructure the product team operating model: the right people from product, engineering, sales, marketing, customer success, and support, organized around each product, with a repeatable cadence of weekly huddles, monthly strategy sessions, and quarterly performance reviews.

Most advisory work stops at strategy documents. I build the operating structure that makes the strategy executable.

A strategy without a clear execution path is a wish list. I evaluate how each product's strategy becomes a prioritized, value-driven roadmap where every item is tied to a business benefit, a measurable goal, a cost estimate, and a set of risks.

From the roadmap, I evaluate how priorities flow into the top of the SDLC. How do roadmap items become requirements? How are they sized, sequenced, and assigned? Is there a clear handoff between product strategy and engineering execution, or does priority get lost between the roadmap and the sprint backlog?

A company can have a sound business strategy, a well-classified portfolio, and strong product strategies, and still underdeliver because the roadmap isn't prioritized against business value or the SDLC intake process doesn't preserve strategic intent.

Now I go deep. Architecture, technical debt, SDLC maturity, DevOps and CloudOps practices, deployment pipeline, security posture, AI readiness, cloud cost structure, team skills and capacity, delivery velocity, quality metrics, reliability, and support operations.

This is the work most technology advisors lead with. I do it thoroughly. The difference is context. By the time I'm evaluating the technology, I already know what the business strategy demands of it, how the portfolio investment model allocates resources, what the product strategy requires, and how the team is organized.

That context transforms every finding. A two-week deployment pipeline isn't just a process problem; it's a constraint on the features the portfolio says this product needs this quarter. Cloud costs climbing 30% year-over-year aren't just a FinOps opportunity; they're an EBITDA drag eating the margin improvement the board expects.

Every layer above depends on visibility. Leadership can't make confident decisions about investment allocation, organizational structure, or strategic direction if they can't see how the product and technology organization is actually performing.

I evaluate against a product success measurement framework covering eight dimensions: Aspirational (a motivating metric connecting work to purpose), Financial Performance (ARR, retention, product margin, EBITDA), Customer Satisfaction (CSAT, NPS, churn trends), Investment Allocation (spend by product, by purpose, as % of ARR), Deliverables (roadmap health, objective alignment), Reliability (uptime, incidents, defect aging), Delivery Productivity (cycle time, deployment frequency), and People & Team Health (hiring, skills, engagement, retention).

Closing the gaps in this framework makes the product and technology organization legible to the business, and keeps it legible long after the engagement ends.

Every finding from every layer gets connected to the business impact it creates: financial performance, competitive positioning, customer retention, investment efficiency, and the strategic decisions that drive the company forward. The loop closes when the people making those decisions have the visibility they need to act with confidence.

This isn't a one-time report. The frameworks, the measurement systems, and the operating models are designed to sustain that visibility long after the engagement ends.