Spencer Hardwick
All work

Great Expectations

Delivered

Make the path from evaluation to everyday use easier.

As the first product manager for the developer SDK, I focused on the friction between trying an open-source data quality framework and using it in a real deployment. That work contributed to a 47% reduction in churn and 80% growth in API adoption.

My role

Product Manager · Developer SDK

Current state

Product leadership on the developer SDK and adoption experience at Great Expectations.

Text version
Churn reduction
47%
API adoption growth
80%
A branching pipeline model with one validation checkpoint and its associated stage highlighted in red.
Editorial illustration · locating a failed check in a data pipeline
Great Expectations brings testable expectations to data pipelines. Checks make data problems visible at a specific point, so teams can investigate where an issue occurred.

  1. Define expectations

    Express the properties data should satisfy as checks the team can use repeatedly.

  2. Validate the data

    Run those checks at meaningful points in a pipeline and surface the results.

  3. Locate the issue

    Connect a failed expectation to the affected data and stage so investigation starts with a concrete signal.

In this case study

A developer product has to survive deployment

Great Expectations is an open-source data quality framework. A useful way to understand it is unit testing for data pipelines: define what should be true about your data, validate those expectations, and make a failure visible where it occurs.

As the first product manager for the developer SDK, I focused on adoption beyond the initial evaluation. Getting a developer to try a framework is one milestone. Helping them incorporate it into their actual environment is another.

Find the friction after the first success

The important adoption problems showed up as people moved from getting started to deployment. I worked to identify that friction and translate it into product priorities for the SDK and its developer experience.

This required treating the path through the product as part of the product itself. An API can expose the right capability while still asking too much of someone trying to connect it to a real workflow. The practical question was where people lost momentum and what would help them continue.

Connect developer experience to product outcomes

I led product direction and prioritization in partnership with the team. The goal was to make the transition from evaluation to repeated use more approachable, with deployment friction informing the work we chose to do.

The resulting work contributed to a 47% reduction in churn and 80% growth in API adoption. Those outcomes matter because they connect developer experience to sustained use of the framework.

What I carry forward

Open-source adoption depends on the experience around a technical capability: how people understand it, put it into their environment, and make it part of their work.

I bring that same perspective to AI tooling. A powerful primitive still needs a clear path into the user’s workflow. Finding and improving that path is product work.