Making An Ambiguous Opportunity Buildable

Finding our way

For more than twenty years, Covenant Eyes had built deep expertise in helping people find freedom from pornography through relational accountability.

Almost none of that expertise was reflected in the product experience. “Grow” was our attempt change that, starting with a library of recovery courses, but including an ambition to go further.

This was an opportunity to expand into a suite of recovery-focused tools, but nobody had a strong, coherent vision.

My challenge was to help the team understand an ambiguous opportunity well enough to decide what to do with it.

Connecting the dots, together

I worked closely with Recovery Education, Engineering, and Product Management.

I pulled people into workshops and office hours repeatedly, asked them for their ideas, and synthesized their thinking into a coherent whole. It helped us bring our collective insight and creativity to the work, and ultimately set the stage for prototyping what this system could actually look like.

We began with an activity called noun foraging, looking for various conceptual objects

I am used to being handed a pitch without much of the backstory on it’s creation… With this new approach, I was able to give early feedback on some thoughts and ideas I had. I foresee this saving everybody time by reducing redundant questions regarding design choices as well as avoiding any reworks if tech finds any mismatches with our current capabilities.

Andrew, developer

We mapped the objects, relationships, and actions behind the experience. This was incredibly helpful, but we went too broad — surfacing around 50 concepts, without clear agreement on which deserved attention.

Mapping relationships between objects helped us understand exactly how they would fit together, and prompted some important discussions

As a result, modeling them became complicated, and prioritization stalled.

It was then I realized that a more comprehensive model wasn’t necessarily going to help people make decisions about where to invest. They needed something more concrete. More practical. Something they could actually tinker with.

I've learned some better methods for prioritization since then, but this was still an effective way to force the decision: what will we actually work on, when?

Turning the abstract, concrete

I built a prototype with “feature flags” that let us toggle capabilities on and off. Each piece of functionality stood on its own. All of them fit together into a coherent whole.

The point wasn’t just to show what’s possible. It was to make a more practical argument: these parts could all fit together without all having to be built at once.

It didn’t prove that implementation would be dependency-free; getting into the details would inevitably reveal new challenges.

But it gave us a way to discuss smaller investments in the context of the whole, rather than as a grab-bag of disconnected features.

Leaving a foundation

Most of the broader vision has not shipped but it was successful in a different way.

We built a shared understanding of the opportunity and created a conceptual model that has matured and become more useful than I ever anticipated.

Two years later, we’re now building “Groups”, a concept that originated in this work. I still draw on the original modeling to brief new collaborators and inform their decisions.

The work also changed how I think about architecture.

The model is not the end. It exists to help people understand things and make decisions. Often that means zooming out to help them see and connect the pieces. Then we zoom back in and say: here’s a piece small enough to build, considered in light of the whole.