The problems I work on

The visible problem is rarely the whole problem.

Leadership may see rising costs. Managers see missed targets. Employees see repetitive work, broken handoffs, and systems that require a surprising amount of human glue.

I bring those perspectives together, map how the work actually happens, and find the constraint beneath the request.

That may lead to a product, an operating change, an integration, a rule, or a better query. The point is to solve the problem, not defend the solution someone named before we understood it.

Most organizations do not need another list of AI use cases. They need a way to decide which problems are worth solving.

I look at the value, evidence, feasibility, cost, risk, ownership, and readiness behind an opportunity. I make the assumptions visible and identify what we would need to learn before committing more time and money.

At Honeycomb, 36 discovery sessions surfaced more than 100 workflows and 400 tasks. That work became 23 experiments, with four prioritized into live pilots first. The evidence changed the question from “Where can we use AI?” to “What is preventing this work from improving?”

That is a much more useful question.

A convincing demonstration proves that something can work under the conditions of the demonstration. It does not tell us whether the data will hold up, whether people will use it, whether the mistakes are acceptable, or whether the value justifies the cost.

I test the assumptions that could change the decision.

That means defining success before seeing the results, using representative data, looking at the distribution and consequences of errors, and testing what happens when the system meets an actual workflow.

The answer may be proceed, refine, or stop. All three are useful if we learn them before building the expensive version.

The CRM, support platform, warehouse, knowledge base, and reporting tools may each work reasonably well. The trouble is often everything between them.

People search for information, copy it from one place to another, reconcile conflicting answers, remember undocumented exceptions, and repair the same gaps every week.

I follow that work task by task. What information is needed? Where does it live? What is a rule? What requires interpretation? What can move automatically? What happens when the normal path fails? Who owns the exception?

Then I design the simplest useful combination of people, software, automation, and AI.

Accuracy alone rarely settles the question.

A system that is right 95% of the time may be perfectly useful for one job and unacceptable for another. The consequences of the remaining 5% matter. So do the people affected, the available safeguards, and the cost of a wrong decision.

At SoundCloud, vendor benchmarks for AI-generated music detection did not hold up on the actual catalog. We evaluated four vendors on representative audio, calibrated the thresholds, and optimized for precision because false positives could harm legitimate artists. The resulting system operated across roughly 700,000 tracks a day at 99.36% accuracy and 99.75% precision. Borderline cases went to human review, and a model prediction never became an enforcement decision by default.

Trust came from the design of the whole decision system, not the model score alone.

“Keep a human in the loop” sounds responsible until someone has to build the loop.

Which person? Reviewing what? With what evidence? At what point? What happens if they disagree? Who can approve the action? What stays human even if the system becomes more accurate?

I turn those questions into working controls: authority levels, permissions, thresholds, review states, escalation paths, decision records, and failure handling.

The goal is not to add approval steps everywhere. It is to put judgment where the consequences require it and let exact, repeatable work stay exact and repeatable.

A collection of AI tools is not an operating model.

Organizations need shared priorities, ownership, context, infrastructure, evaluation, cost controls, governance, and a way to carry learning from one workflow into the next.

I look across the individual use cases for repeated needs. Which context should be shared? Which integrations keep appearing? What evaluation methods can be reused? Where do teams need different controls because the work carries different consequences?

The shared capability should come from demonstrated demand. Building a large abstract platform before understanding the work is a very efficient way to create expensive infrastructure nobody quite knows what to do with.

Customer interest is useful. It is not the same as willingness to pay.

I investigate the buyer, budget, champion, blocker, implementation path, adoption behavior, renewal conditions, and commercial model alongside the user need.

At Apptegy, Rooms stayed with two design-partner districts for two quarters while we tested those assumptions. Districts did not want another disconnected tool, so the product was rebuilt around shared access with the rest of the platform. It later reached 436 districts, approximately $5 million in ARR, and reduced the sales cycle from three to six months to one to two months.

The early constraint was not demand. It was whether the product fit the way districts bought and worked.

Practices that work for one product and a small team do not always survive growth.

As Apptegy expanded from approximately 1,400 to 4,000 customer districts during my tenure, I redesigned the product operating model three times. The work included portfolio strategy, investment choices, customer segmentation, shared discovery and launch practices, and clearer decision rights across six product teams.

Scaling a portfolio does not mean centralizing every decision. It means giving teams enough shared structure to make good decisions without waiting for one person to make all of them.

Most organizations do not have an information shortage. They have evidence spread across systems, teams, documents, conversations, and people’s heads.

I build ways to connect qualitative and quantitative evidence without stripping away its source or pretending disagreements do not exist.

That may include customer conversations, support data, product behavior, research, CRM records, financial information, internal knowledge, and market evidence. The goal is not to create one giant pile of context. It is to help people investigate recurring business questions, trace conclusions back to evidence, and see where the evidence conflicts.

Access is only one part of adoption.

People may not understand where a tool fits, trust the output, have permission to use the necessary information, or know what to do when the example they were shown does not match the problem in front of them.

I work from the actual roles, workflows, and decisions. What are people trying to do? Where are they getting stuck? What capability would help? What support, access, controls, and practice would make that capability durable?

Training can be part of the answer. Sometimes the answer is fixing the workflow that made the tool feel useless in the first place.

Complex technology decisions bring together people with different expertise and different responsibilities. Product sees the customer. Engineering sees the technical constraints. Finance sees the economics. Legal, Privacy, Security, Risk, and Operations see consequences the rest of the team may not.

I make those differences visible and turn them into an executable decision.

That means separating evidence from assumption, defining the tradeoffs, naming what remains unknown, clarifying who owns the decision, and documenting the conditions under which the answer should change.

Agreement is useful. Clarity is required.

I tend to be most useful in the gap between a strategy and the work required to carry it out.

I can move between the executive decision, the operating model, the product experience, the data, the technical architecture, and the exception someone still has to handle on a Tuesday afternoon.

I also build far enough into the recommendation to find out whether it works. That has included SQL, Python, JavaScript, APIs, model platforms, orchestration, evaluation systems, workflow tools, interfaces, and production infrastructure.

The technology matters. So do the business rules, the people using it, the evidence behind it, and who remains responsible when the normal path breaks.

Sometimes the answer is AI. Sometimes it is a query, a rule, a clearer owner, better documentation, an integration, or ordinary automation.

I care about solving the problem and leaving the organization able to own what comes next.