Project Discovery, Team Alignment, Co-Design & Free Lunch

A framework for cross-functional product teams that build things together

5 min readJul 24, 2019

It goes without saying, proper planning and early team alignment helps to decrease the chances of projects going off the rails.

That said, it still amazes me how little time and investment product teams actually put into having proper project kickoffs. By “proper”, I don’t mean a big groupthink meeting where everyone sits the entire time, agrees on everything and talks about the obvious or a crazy-8’s exercise intended to come up with 25 ways to design a single page or feature.

A proper kickoff happens early in the product development lifecycle and creates a setting that allows for each cross-functional team member to contribute, provide their expertise on the subject matter, determine as a team how it all aligns with business objectives and how it aims to tackle a problem for the user and/or business. This space allows for “stupid questions”, honest debate and dialog and provides clarity on next steps for each member involved.

I found (god knows, through trial and error) that when a discovery planning session is successful, everyone involved feels a natural sense of ownership, alignment with what’s going on and less one-off meetings are necessary throughout the rest of the process.

“There is a direct correlation between the end users experience and the teams that help to shape those experiences. If the teams are not aligned and cannot work in a cohesive fashion, those gaps will reflect across the various touch points throughout the customer experience.”

From Research to Dev Handoff in 4–5 Weeks

Below is process and framework that evolved on a monthly basis over the course of two years. Keep in mind that this worked for the team that I was on at the time. The primary goal was to help align cross functional teams early on and have some output that fed into the upcoming sprint.

As with any process, you simply cannot just “plug and play”. There are many factors that go into leveraging frameworks within an organization such as the team culture, relationships and dynamics which requires that you optimize the framework for your specific needs. Think of it as a product that you also need to iterate on.

The Workshop

The workshop was a modified version of Google’s 5-day design sprint, compressed into a 2-day timeline to accommodate the teams schedule.

Workshop Goal

The goal was to create a space allowing for the team to build a shared understanding early on through a collaborative activity which aimed to help build trust and give a sense of ownership and alignment for every individual involved. Some measurable indicators that we kept a pulse on were:

Were there less unnecessary meetings?
Was there less emphasis on documentation and more on collaboration?
More emphasis on artifacts that spark discussion and are actionable (see IDEO’s concept of “No Prototype, No Meeting”).
A better grasp of technical constraints early on in order to avoid last minute design changes.
Learning the value or viability of a potential offering early on (Build the right thing).

User Research

Prior to the workshop, have a problem in mind that’s not too large and not too small.

Plan to spend time conducting user research (i.e. user interviews or contextual inquiries) prior to the workshop to help inform the design approaches/decisions. Most team members will need to plan to share out information on day one of the workshop. This can be in the form of a presentation or some form of documentation.

Who’s Involved

Day one will likely have the most people involved due to the need of gathering as much data and understanding as you can. That said, be sure that there is purpose and reason for each person who is in the room so as to not waste anyones time. For our situation, we found the “sweet spot” to be 8–10 people, consisting of a representative from:

Product Management
Design
User Research
Engineering
Content Strategy
Support
Product Marketing

The facilitator can be one of the representatives such as the designer or researcher. It’s ideal that the facilitator is experienced or has at least read the book “Sprint” (at a minimum!).

The Workshop Schedule

Day 1: Understand, Diverge & Converge

Frame the design problem. Understand the current landscape. Define what needs to be created or improved and determine how success will be measured.

9:30am — Intros & Overview

Overview & Introductions/Ice breakers (Facilitator)
Business goals & vision (Product Manager)
Competitive landscape (Product Manager)
Problem to be solved (Product Manager)
Jobs to be done (Product Manager)
Success — define KPI’s and what success means (Product Manager w/ team input)
User research findings (Research)
Quantitative data overview (Product Analyst)
Support data overview (Support)
Competitor app demo/review (Designer)

12:00pm — Lunch

1:30pm — Design

Macro — Customer journey — where does this fit within it? (Designer w/ team input)
Micro — Whiteboard User Flow Map (Designer w/ team input)
Diverge on ideas — Crazy 8’s — low-fidelity (All — Individual Activity)

3:00pm — Present & Discuss

Re-iterate customer journey and user flow (Facilitator)
Present Crazy 8 concepts (All)
Critique and Gather Feedback (All)

4:00pm — Voting

Vote on top solution (All)

4:30pm — End of day

Day 2: Planning & Prioritization

A half day in which the team will review the prior day activities, further define a viable solution based on the “winning” approach from the crazy 8’s activity and plan for next steps. Product marketing, product analyst and support are optional for day two.

9:30am — Review

Re-iterate problem (Designer)
Re-iterate customer journey and user flow (Designer)
Iterate & finalize top solution from crazy 8's activity (Designer w/ team input)

11:00am — User stories, Planning & Prioritization (Done individually)

Feature breakdown, user story creation & prioritization — Aha Tasks → backlog (Product Manager/Project Manager)
Prototype planning (Designer)
User test planning (Research)
Architecture/Tech Planning (Engineering)

12:00pm — Conclude

The Outcome

As you can see in the bullet points above, by the end of this 1.5 day workshop, we were able to build a shared understanding and align as a team, vet out and understand the problem (through prior research), give ownership to each team member, discuss constraints and known/unknown issues, define high-level KPI’s, define what “success” for this project meant, pinpoint where the problem fell within the broader customer journey, co-design and debate as a team on various solutions and have clear action items, post workshop.