The Ten-Year Plan I Kept Updating While the Real Work Happened Elsewhere

I spent years maintaining a detailed ten-year career plan for my work at the intersection of faith and technology. The document listed target roles, product categories I would own, and the kinds of organizations I would serve by certain ages. Updating it every six months gave me a sense that I was being intentional about the opportunities God might place in front of me.

The cost showed up slowly. When an unexpected request came to help redesign a simple volunteer curriculum tool for one children’s ministry organization, I turned it down because it sat outside the next three milestones on the plan. Two years later that same small product had reached hundreds of thousands of ministry volunteers while my own roadmap still pointed at a larger platform role that never materialized.

This is the foundational misread that causes product leaders to treat every new request as a distraction instead of raw material. The plan becomes the filter that decides what counts as real work.

John Wesley’s three simple rules offer a different frame. Do no harm. Do good. Stay in love with God. Wesley did not hand his movement a five-year strategy document. He gave people daily and weekly practices that could be applied the moment an opportunity appeared. The rules assume that faithful action happens in response to what is already in front of you, not what you scheduled six quarters out.

The plan that looked faithful but crowded out small experiments

My ten-year document contained a section titled “Scale Impact.” It listed only projects that could reach at least fifty thousand users within eighteen months. That single line quietly eliminated every request that arrived through a volunteer email list or a pastor asking for help with one local children’s ministry workflow.

The curriculum opportunity started exactly that way. A volunteer coordinator needed a print-friendly lesson outline that could be finished in seven minutes. It did not match any line item on the roadmap, so I treated it as noise. The team that eventually built the tool measured success by completion rate on first use rather than registered accounts. That metric turned out to be the real driver of long-term engagement, something no slide in my deck had captured.

The same pattern repeats in larger organizations. A product manager at a Bible resource site once told me she kept a private list of “quick experiments” that never made it to the quarterly review because they lacked a direct line to the five-year vision. One of those experiments later became the feature that lifted monthly active users by double digits. The plan itself had no mechanism for noticing the signal until it already looked big.

How Wesley’s rules expose the hidden cost of rigid roadmaps

Wesley’s first rule, do no harm, asks what existing commitments are being damaged by the plan. A rigid roadmap often crowds out the small experiments that keep a product team connected to actual users. When every week is already allocated to milestones two years away, the team stops hearing the volunteer who needs the lesson printed in two pages instead of six.

The second rule, do good, pushes the question of what concrete good can be done this week with the resources already in hand. In product terms this means running the smallest possible test that could matter to one user segment before the next planning cycle. The curriculum team started with a single PDF template tested by twelve volunteers. No roadmap approval required.

The third rule, stay in love with God, functions as a reminder that the work itself is not the point. When the plan becomes the object of attention, leaders begin defending the document instead of responding to the people the product is meant to serve. The rule forces a weekly check: does the current list of tasks still reflect love for the actual users, or only love for the forecast?

What happens when product leaders stop defending their five-year slide deck

Teams that drop the defense of the long-range deck begin to treat incoming requests as the actual work rather than interruptions. At one ministry tech organization the leadership team stopped requiring every new idea to map to the existing five-year themes. Within six months they had shipped three volunteer-facing features that none of the original roadmaps had anticipated, each built in under ten weeks.

The shift also changes how people are evaluated. Instead of measuring progress against the plan, leaders start measuring how quickly the team can test a new assumption and either keep or discard it. The curriculum team’s print-first design came from one such test. The team measured whether volunteers actually completed the lesson in one sitting. When the data showed they did, the feature stayed. When a later idea failed the same test, it was removed without any need to explain why it no longer matched the original vision.

The pattern is simple. Opportunities compound when they are allowed to arrive on their own schedule. The plan that tries to pre-schedule them ends up filtering most of them out before they can be tested.

Your Turn: Apply This Today

• Delete the current ten-year career document and replace it with a single note titled “This Week’s Three Tests.”
• Each Monday morning list three small experiments you can run with existing resources before Friday.
• Run at least one of those experiments with a real user by Wednesday and record whether the user completed the task without help.
• At the end of the week archive any experiment that showed no value and carry forward only the ones that produced a measurable completion rate.
• Share the three-test list with one peer and ask them to hold you to running them rather than updating the list itself.
• Repeat the cycle for six weeks before allowing yourself to write any new multi-year document.

The same tension between rigid plans and live signal shows up in The Agent That Kept Running the Schedule While No One Was Watching, where a fixed workflow missed the context that mattered most.

I consult with product leaders and ministry technology teams on replacing rigid roadmaps with weekly testing practices and measuring actual user completion instead of forecasted scale. Let’s talk.