Start where the work happens
A league can tell you it needs a schedule. Understanding what makes that schedule workable takes more listening.
Which venue windows are genuinely available? Which requests are preferences, and which cannot be broken? Who approves a change? What happens when the person doing the work is standing beside a rink with a phone?
Those details shape the product. Our team has a lot to learn from the people who live them every week.
That is why the idea of forward-deployed engineering resonates with me. It brings engineering close to the customer’s actual work, connecting an understanding of the problem to how software is configured, built and used.
We want to bring that way of working into our relationship with leagues. Spend time understanding their decisions, their scheduling rules and their internal workflows. Make the software fit those realities where it can. Learn where it needs to improve.
One platform, different ways to run a league
There is an important distinction between understanding a league and building a separate product for every league.
Across sports, many of the building blocks are familiar: teams, people, competitions, games, venues, availability and responsibilities. How a league puts them together can be very different.
Our approach should start by separating three questions:
- Is this a decision? The league may need to choose a policy or settle a tradeoff before software can help.
- Is this configuration? An existing capability may do the job once its rules, permissions or workflow are set appropriately.
- Is something genuinely missing? We may need to build a capability that belongs in the shared product.
That distinction matters. A scheduling preference should not automatically become a new feature. A missing capability should not be disguised as another setting. When we do build, we want to understand the reusable need beneath the request rather than create a one-off fork we have to maintain forever.
This approach needs boundaries. It is not a promise to build every request or provide unlimited custom development. It is a commitment to understanding the request well enough to make a sensible product decision.
Keep the operator in the loop
Scheduling makes this especially clear. Start with requirements the league has accepted. Build alternatives. Check them against those requirements. Let the operator review the tradeoffs and refine what matters.
The same thinking applies to improving a workflow. Understand the need, configure or build a response, check it, then put it back in the hands of the people doing the work.
We call this loop engineering: deliberately connecting the work to the evidence and feedback that should guide the next attempt.
A technically valid schedule can still reveal a preference nobody captured. A tested feature can still be awkward at the rink. Operators retain judgment about what works for their league. Our job is to make that judgment easier to express and useful to the next iteration.
A small example we’re testing
We’ve been testing short, optional follow-up questions with OARHL staff inside LeagueNav’s feedback flow.
A staff member writes a problem or suggestion. The flow can ask a few specific questions before sending. Staff can answer what they know or send without questions, with the questions and answers kept together on the report.
Imagine a report saying, “The game schedule is hard to read on my phone.” A useful follow-up might reveal that the rink name wraps onto three lines. That gives a builder a concrete problem to investigate rather than a vague instruction to redesign the schedule.
Early OARHL use has also shown us questions that repeated information staff had already provided or asked about things the product should know. That is feedback on our own workflow: use the context we have, then ask only for what is missing.
Better questions are one part of the loop. A change still needs to be implemented, checked and tried by an operator before we can say it helped.
The SaaS relationship we believe in
I believe the next era of SaaS will bring the product team closer to the customer’s work. AI can help make that practical, but the relationship still depends on listening, clear decisions and follow-through.
For LeagueNav, the direction is a shared platform that can support different leagues without asking them all to operate identically. Learn from each league. Configure what already fits. Build carefully where something is missing. Return to the operator and learn again.