Hearing Your Users Through the Data

We have a plethora of tools at the ready for understanding what happens when (and for how long) on any pixel we wish to study—giving product teams an incredible amount of power (and leverage).

As with all sources of power comes a trade-off; by over-indexing on quantitative data you forsake a crucial source of information: your end users’ wishes.

Losing the voice of your customer begins to fragment the bias associated with what’s most important on your team or within your org—it starts a little fire under the bridge connecting the customer experience and the product, and unless it’s tended to, it can get out of hand.

I’ve seen first-hand where teams have fallen into the trap of almost exclusively leaning on quant. Focusing on a metric in a funnel that screams “improve me” is only part of the story. The bigger, unanswered questions within the datapoint always harken back to “why?”, and to answer that we need grounding in qualitative feedback.

The question becomes: How might we design an experience that heightens our overall knowledge (and perception) of product health through a qualitative lens?

View fullsize

One thing product managers are especially good at is “Monday Morning News”: interpreting data, analyzing competitor goings-on, and other events from the past week. It’s all voluntary, but highly necessary to keep up-to-date with what’s occurring inside and outside of the product.

The answer to the above question is the establishment of a “River of Feedback”, and idea that I had originally learned from Reforge. Aggregating qualitative input sources into one channel allows the team to dip in, reading at-will like Monday Morning News. It allows everyone the same level of access to information derived directly from customers.

A River of Feedback instruments and funnels the voice of the customer directly back to Product. When consumed, it begins to remove recency bias as readers start to readily recall what customers needs are when speculating on metrics.

View fullsize

The ingredients in the recipe are the inputs your team deems most valuable, and they are funneled into a team channel (ie Slack). We funneled everything we knew we could: NPS feedback, market research, cancellation messages—and did so with a custom filter on each to reduce overall channel noise (posting a monthly NPS report rather than every submission, for example).

Balancing quant and qual is paramount to a product’s success, and it allows the larger team to be so much more knowledgeable about customer desires and pain points than simply looking at and making product assumptions from metrics dashboards.

Double Diamond for Product Teams

The double diamond isn’t new; it originated within the design world to represent the exploration of a problem to be solved through divergent and convergent thinking. Working in product triads with full representation of technology, design, and business (product) allows teams to make informed decisions faster through proper collaboration.

The reality of working in a triad feels like you have all the right people in the room; each of our disciplines has a seat at the table including the invaluable support functions like customer support, data, UX research, content strategy and more.

What lacked is a common, consistent language to represent our individual and collective purviews.

Our product team realized that each function held different definitions of terms used within each discipline. For example, “discovery” might mean a tech plan to an engineer, but to a designer or researcher, discovery lives much earlier in the project lifecycle, typically grounded in user research to validate hunches or to uncover additional patterns.

As we workshopped, the double diamond felt best to us as a group, unifying each function and our respective definitions.

Disambiguating semantics within the lifecycle allowed our triad and respective team to know when rituals will occur and what stage we’re in—and allowed us move faster through common language.

Process is a product unto itself; discussing and improving it helps the team feel safe, productive and happy.

Mapping Users to a Larger Product Strategy

Until recently, anyone who was aware of Squarespace (probably via a podcast ad) would refer to it as a web builder. Internally, the product strategy needed to represent our customers in a way that better reflected recent growth (organic and through acquisition.

Execs broke out the user base into three primary areas: Halo, Nurturing and Core (“Enterprising Dreamers”). This was highly tied to how they viewed our Website user base, but it didn’t immediately resonate with the Scheduling product team at the time—we didn’t consider our users as Enterprising Dreamers.

As the org moved to focus on seller transactions and scheduling’s nascent role in the platform as a legitimate revenue driver, we needed to see our users reflected in the corporate strategy. So the question became:

How does a Scheduling user map to the larger product strategy of Halo, Nurturing and Core users?

We knew from our own data where the market segments lived, regarding who came in the fastest, who left the most, and who seemed to stick around. At the time, we still maintained a Freemium model, and looking at the segments within that bucket gave us a pretty clear view of what our Halo looked like—orgs who needed appointments but not the premium features like transactions.

View fullsize

Establishing the Core group enabled us to extrapolate multiple things layered on top of corporate strategy, including selling progression, tooling support (and cost), and what their primary concerns were—mapped alongside a business’s maturity.

This gave the Scheduling team a source-of-truth for who we build for and what their journey may look like as it maps to the larger corporate strategy of Squarespace.