What a Responsible Cross-Product Pilot Should Measure

Start with a question, not a product bundle

The Onward Suite brings together Ready Set Onward, Onward Families, Onward180, ONWARDology, Onward Nexus, OnwardSync, Onward Signal, and Onward Playbook. A cross-product pilot should not begin with the assumption that every offering belongs in one workflow. Begin with a specific problem for a specific group of participants, then choose only the products relevant to that problem.

For example, a team might ask: “Can staff and participants move from an initial activity to a clearly identified next step without unnecessary handoffs?” That is a testable question. “Can we use the whole suite?” is not. The first question helps the team decide which products to include, what participants will be asked to do, and what evidence would count as improvement.

Write down the pilot’s purpose, participant group, duration, and boundaries before inviting anyone. Use the [Onward ecosystem overview](/ecosystem) to understand the suite’s scope, and the [solutions overview](/solutions) to consider how a pilot might fit a defined need. Do not treat the products as a single technical system: a shared login, shared data, or live integration between offerings should not be assumed.

Measure adoption as participation, not enrollment

A sign-up or invitation shows that someone had an opportunity to participate; it does not show that the product became part of their work. Choose a small number of observable measures, such as how many invited people begin, how many return for a planned follow-up, or whether intended staff complete the pilot’s agreed activity. Define each measure before launch so the team does not change the meaning of “adoption” after seeing the results.

Use a denominator and a time window. For instance, record the number of people invited and the number who complete the first agreed activity within the pilot period. If people stop participating, record that as a signal to investigate rather than labeling it a failure or blaming the participants. A short, voluntary check-in can help identify barriers such as unclear instructions, inconvenient timing, or uncertainty about what to do next.

Keep measures proportionate. A pilot designed to test a simple handoff does not need a lengthy survey after every interaction. Decide in advance who will review participation information, how often, and what decision it will inform. If a measure cannot change a decision, it may not belong in the pilot.

Look for friction at the handoffs

A cross-product pilot should make the work easier to understand, not merely increase the number of products involved. Map the participant’s path from the first activity to the intended next action. At each handoff, ask: Who explains what happens next? What must the participant repeat? Is there a delay, a confusing instruction, or an unclear responsibility?

Record friction in plain language. For example: “Participant was unsure which person to contact after the session” is more useful than “workflow issue.” Note when and where the problem occurred, but collect only enough detail to understand the process. If the team is considering a product such as [Onward Nexus](/products/onward-nexus) or [OnwardSync](/products/onwardsync), verify the intended use and technical arrangements directly before designing a workflow around it. A product name or suite relationship is not evidence of a particular integration or capability.

Compare the planned process with what actually happened. If a handoff requires staff to copy information manually, count the steps and ask whether that burden is acceptable. Do not quietly create a workaround that depends on moving sensitive information between products without an approved process.

Define a meaningful next action

A pilot should test whether participants and staff can identify a reasonable next action—not whether every participant reaches the same outcome. Before launch, specify what “next action” means in this context: scheduling a follow-up, contacting a named person, reviewing an agreed resource, or deciding that no further step is needed. The right example depends on the pilot’s purpose; do not present one as a guaranteed product outcome.

Track whether the action was identified, whether the responsible person was clear, and whether the action was completed or intentionally declined. These are distinct observations. A participant may understand the next step but choose not to take it. That distinction matters when interpreting results and planning changes.

Keep the record focused. For a process pilot, a simple status such as “identified,” “completed,” “deferred,” or “declined” may be enough. Agree who can see that information and how long it will be retained before collecting it. Avoid gathering personal details merely because they might be useful later.

Set boundaries, then decide what happens next

Privacy is a pilot design decision, not an afterthought. Tell participants what information is being collected, why it is needed, who will review it, and how it will be handled. Collect the minimum needed to answer the pilot question. Keep product-specific records separate unless an authorized, verified process supports sharing them. Never assume that Onward Suite membership means data moves between products or that one account grants access across them.

Use this short checklist before launch:

- One defined problem, participant group, and pilot period. - A limited product selection tied to the problem. - Clear definitions for adoption, friction, and next action. - A named owner for each handoff and each measure. - Documented privacy boundaries and a plan for handling information. - A review date and a decision the pilot will inform.

The next action is to hold a short planning session with the people who will run the pilot and those who will participate. Agree on the question, map the intended journey, confirm product use and technical assumptions, and remove any measure that is not necessary. At the review date, decide whether to stop, revise, or test the process again. A responsible pilot earns expansion through evidence and clear boundaries—not through the number of products included.

Common questions

### Should a cross-product pilot include every Onward Suite offering?

No. Select only the products relevant to a clearly defined problem and participant journey. A focused pilot is easier to evaluate and less likely to introduce unnecessary handoffs.

### Can we assume products share accounts or participant data?

No. Do not assume shared login, data interoperability, or live integrations. Verify the technical arrangements and establish appropriate privacy boundaries before designing a process that depends on them.