SALESFORCE developer USer summit

 

Methods

Screener design & recruitment

Activity design, materials procurement, logistics coordination

Activity facilitation

Journey mapping, co-design, requirements gathering

Qualitative data coding & analysis

Presentation of findings

Stakeholders

Product management

Product marketing management

Engineering

Research operations

Tools

Miro (qualitative data analysis)

Salesforce (participant scheduling)

Time Frame

1 month (in parallel with other projects)

Product Overview

Salesforce developers are a huge part of the Salesforce ecosystem, but their voices are not always heard. My research team proposed piloting a Developer User Summit to allow them to make their voices heard. We planned and executed it in one month, and invited dozens of stakeholders to observe and participate directly with our users.

As a result of my study…

  1. Increased stakeholder empathy: Our PMs got to hear directly from their users in an unvarnished way.

  2. Tactical adjustments: Numerous small product adjustments were planned as a result of this workshop, circumventing the often elaborate process of surfacing research findings.

  3. Propelled demand for research: By making this highly collaborative, we built stakeholder trust and got buy-in for future User Summits.

Selected Challenges & Adaptations

Challenge 1: Short timeline

Adaptation: Recruitment and logistics planning were #1, and planning the specifics of our research activities could wait. I prioritized getting stakeholder buy-in, setting up our note-taking system, and finalizing our goals for the day before fleshing out the details of our activities. In one case, an activity was planned the day of the event. Although not ideal, triage was necessary.

Most of all, collaborating and leaning on my research colleagues was crucial. We could not have accomplished this workshop without nonstop communication and collective support.

Challenge 2: Different participant backgrounds

Our participants came from a plethora of different sized companies and levels of experience. All of their perspectives were important, so we had to ensure that everyone was heard from in group activities.

Adaptation: To the extent possible, we grouped participants into tables of similar experience levels. Within group activities, our facilitators, myself included made sure to call on everyone and include everyone in the discussion. Of paramount importance was making sure the participants knew there were no wrong answers. This can mean employing the teacher-apprentice model, i.e. the researcher establishes themself as learning from those with expertise in what’s important: their own world.

Challenge 3: Out of my (product) element

Developer experience was not technically my product area, so I was not intimately familiar with the product space or our users’ issues. This made facilitation somewhat difficult.

Adaptation: I had to lean on my research training. Asking good follow-up questions is mostly a matter of listening and being attentive to your participants, and making everyone’s voices heard doesn’t require any domain knowledge at all. In fact, coming in with fresh eyes can be very helpful, and indeed in this case I felt unburdened by prior beliefs. This helped me get to the core of what participants were saying — (“so what I’m hearing you say is…”).

More Info

Problem Area

Salesforce developers are a huge part of the Salesforce ecosystem, but their voices are not always heard. My research manager led the charge in getting a Developer User Summit off the ground, to both allow users to make their voices heard and also to showcase the research team’s work. Once approved, we planned and executed it in one month, and invited dozens of stakeholders to observe and participate directly with our users.

Methodology

With the one-day summit, we planned a series of group activities and a Q&A with Salesforce PMs. The activities took up most of the day, and we ran the gamut from wild brainstorming to digging into the nitty-gritty of our participants lives.

Each table had 5-8 participants, one facilitator (like me), and one note-taker. The rest of our stakeholders wandered throughout the room, taking in the various conversations going on.

The activities were classic whiteboards, sticky notes, and sharpies galore. Making it fun and interactive was most of the battle, and the participants were more than happy to discuss their work lives, expectations, and opinions.

Impact

  1. Increased stakeholder empathy: Our PMs got to hear directly from their users in an unvarnished way. This is hard to overstate, as putting real faces on user issues is worlds better than using personas to conjure up “real” people.

  2. Tactical adjustments: Numerous small product adjustments were planned as a result of this workshop, circumventing the often elaborate process of surfacing research findings. Getting senior product leadership in the room was immeasurably helpful.

  3. Propelled demand for research: By making this highly collaborative, we built stakeholder trust and got buy-in for future User Summits.