Turning onboarding friction
into product direction
I designed and led SharePoint Embedded’s first four-day design sprint, bringing together 20 people across the core product team, leadership, and domain experts to understand developer onboarding from multiple perspectives and turn that evidence into product direction.
Turning a fragmented onboarding experience into product direction
The team understood many onboarding problems individually, but not as one end-to-end developer experience. I created a shared model of that journey, helped the group narrow roughly 20 friction points to two priority problems, and translated the result into near- and longer-term product work.
Defining the onboarding problem.
SharePoint Embedded is a developer platform for building applications that store and manage content using Microsoft 365 infrastructure. I joined the team with a broad goal: make it easier for developers to get from first evaluation to a working app, and ultimately improve adoption.
I started by interviewing product managers who worked directly with customers. The team already knew many individual problems developers encountered, but that knowledge was distributed across people and different stages of the experience. There was no shared end-to-end view of how a developer evaluated the platform, proved the concept, built an app, and moved toward deployment — or agreement on where the biggest onboarding problems actually were.
Before choosing solutions, we needed one shared model of the onboarding experience that the team could use to make decisions.
Designing a shared decision-making process.
I proposed SharePoint Embedded’s first design sprint to bring the team’s distributed customer knowledge into one shared model and use it to make product decisions.
I designed a four-day decision-making process for a hybrid, cross-functional group — product managers, developers, leadership, design, content, and research — with some people in the room and others joining remotely. Day 1 brought together 20 people: the core SharePoint Embedded team, leadership, and domain experts from areas such as sales and engineering. I intentionally combined these perspectives to reconstruct the onboarding journey from multiple angles — product knowledge, technical constraints, and friction observed with developers and customers. After that, a smaller working group carried the journey into prioritization and product direction. Because participation changed across the four days, the format had to preserve continuity while letting specialists contribute when their knowledge was most useful.
Building a shared developer journey.
The team did not share one model of the developer journey. Different functions knew different parts of it, stages overlapped, and even the terminology was inconsistent.
We spent the first day reconstructing the experience together — from trying SharePoint Embedded and building a proof of concept through development and deployment. We mapped who was involved, what developers were trying to accomplish, what they expected, where the product team intervened, and what “done” meant at each stage.
I used the whiteboard to capture shared knowledge in real time rather than starting with individual sticky notes. The goal on Day 1 was to reconstruct one end-to-end journey together, so I wanted participants to react to, correct, and build on the same model as it emerged. It helped surface disagreements and missing context immediately instead of creating a collection of disconnected inputs to synthesize later.
Mapping friction to the onboarding journey.
We walked the onboarding flow from Day 1 step by step, collecting developer goals, friction, knowledge gaps, and opportunity questions against the point where each one actually occurred.
We ran polls and had each participant pick the two biggest frictions per step so pain concentration became visible without letting the loudest voice set priority.
We labeled every item with the stage where it was best solved. That separated symptoms from root causes and made later prioritization much more useful.
We had a fully annotated flow — frictions, knowledge gaps, and opportunity questions tied to specific steps rather than floating as general complaints. The exercise also corrected container terminology: “trial” and “standard” were replaced with language that matched the actual product model.
We ended the day with voting so the strongest signals could rise from the shared evidence — not from the loudest voice in the room.
Prioritizing the highest-impact onboarding friction.
I regrouped the highest-voted issues under each phase and had the team challenge where each problem actually belonged. A symptom could appear late in development while its root cause belonged much earlier, during initial evaluation or proof of concept.
Rather than treating every friction point equally, I introduced criteria that separated problems the team could meaningfully address from broader platform constraints. We filtered for problems that were developer-facing, onboarding-specific, specific to SharePoint Embedded, and within our control. Then each participant created an individual ranking, which I synthesized into one master priority list.
Keeping prioritization intact when the plan changed.
By Day 4, the team had a ranked problem set. A key stakeholder then rejoined with an immediate need to improve how developers created the storage containers their SharePoint Embedded apps depend on, using the VS Code developer environment.
I used the ranked problems as the decision criteria rather than restarting around the new request. Once the team confirmed that the VS Code work addressed one of the highest-priority onboarding problems, I adapted the session: we worked through that immediate direction first and kept the remaining priorities visible for longer-term work.
I adapted the plan around an immediate product need without reopening the prioritization: the new direction moved forward because it directly addressed one of the highest-ranked onboarding problems.
Turning priorities into product direction.
With container creation confirmed as a top onboarding problem, we mapped that flow end to end and evaluated where the product could remove setup work for developers.
Visual Studio Code became the immediate direction because developers were already using it while evaluating the platform. Moving more setup into the same environment could reduce manual steps and tool switching, while creating a practical path toward self-guided onboarding. We separated that near-term opportunity from larger structural changes, such as reducing the need for developers to obtain a Microsoft 365 test environment before they could try the platform.
Update get-started guidance and document tenant setup.
Improve the extension UX so developers can progress without high-touch support.
Explore a trial or sandbox that would let developers evaluate the API without first setting up a Microsoft 365 tenant.
I took one of the prioritized directions forward, designing a more self-guided VS Code onboarding experience.
The priorities moved into product planning.
The sprint turned a diffuse set of onboarding complaints into a shared journey, a ranked problem inventory, and an owned sequence of product work. The priorities fed into semester planning; simplified onboarding became the top key result for the team’s Growth objective, and developer onboarding continued as a named workstream. The “Next” direction also became hands-on design work: I designed the self-guided VS Code onboarding experience that followed the sprint.