The kick-off meeting
1-2 All DAY MEETING + BEST TO HAVE A FACILIATOR
Anyone who is involved in your project should meet in a meeting before everyone starts doing work. The kick off meeting is made up of business people, product people and anyone else that has accountability to the project. The goal of the meeting is to externalize information that's important for everyone to understand & while creating a shared alignment on what we are planning on doing and NOT doing. In short, we're using this time to agree on goals, plans, priorities, timelines, and risks.
01
The Business Goals
THE WHY
Business goals are "things a business wants to accomplish" think metrics and how to measure metrics. You want to understand the business goals and how they map to milestones that the software you design will need to achieve. You’ll want to know key performance indicators (KPI’s) that inform business analytics ex: lower # of support calls. This also helps in connect business goals to user needs and their motivations. You want to know how well your design decisions informed the business goals in small and large stages/milestones.
BUSINESS FOLKS / STAKEHOLDERS
They are all about risks & goals. You'll need to inform business folks that developing customer empathy (research) and experimenting with solutions will de-risk business unknowns and help to ensure product success. Knowing this will help you make decisions on different ways you can design software. The more you can align on their goals, understand their initiatives and talk their lingo the more valuable you will be at the business level of any company.
QUESTIONS YOU CAN ASK
• What do you intend to achieve by building software?
• How is the business going to benefit from this software experience? - (metrics)
• What are the KPI's (Key Performance Indicators) we would look to track that could inform us that we are achieving the goals we set out to achieve? (ex: reduction in support request, higher ratings across public channels, increase usage, increase user base, etc)
• Let’s say the project is over, the application is out and it’s wildly successful, what does that success look like?
02
The Product Goals (Features/Epics)
THE WHY
These are features/epics descriptions written out as brief scenarios—what we think the product will do for its users that will achieve or impact the business goals. Example: You can’t have a photo-taking app if you don’t have a camera— this product goal example would be something like "allow users to take photos of their food by utilizing their camera features on their phone within the application" These goals can be changed, depending on the research and solution testing outcomes.
PRODUCT PEOPLE
These people are usually subject matter experts, designers, product managers, and engineers. These people will understand design way more than the business people and they'll have questions around specific user interface components and interaction design details. Remember, your design serves as a communication tool to de-risk usability & solve the engineering need of "how does the product work & what does it look like." End users don’t see your final designs, they see what the engineers built - use your designs to validate usability and align teams on what the product does, how it looks, and how people intend to use it.
QUESTIONS YOU CAN ASK
• What does your product need to do, to achieve business goals?
• If your product was a human what would it spend most of its time doing?
• How confident are we regarding the need for these features from our users pov?
• Out of the list of features/epics is there a priority ranking?
03
Users & Their Goals
THE WHY
User-centered design. You can also use this meeting to prioritize users if the application has many personas. This will give you the focus and starting point.
THIS IS YOUR (DESIGNS) AREA
You need to capture just high-level—user's profile view & not persona-level information about:
• Targeted Market
• Target Users
• Targeted Users Goals & Potential Problems
• What we want to learn about them (Learning goals)
QUESTIONS YOU CAN ASK
• What do we currently know about them?
• What problems are most important for us to solve for them?
• What are these people's most important goals and what's motivating them?
• What do we want to learn about them?
• Are they close by? Where can I find them? Can anyone connect me to them?
04
Stakeholders
Stakeholder Management / Stakeholder Anxiety / Stakeholder Interviews
THE WHO
• People whose job is to make sure this is a success.
• People who need to make decisions on budget and business results that align & meet the company strategies and initiatives. (KPI's)
• They have a “stake in this” but can’t be with you all the time.
THE WHY
You’ll have design reviews to show results from research and solution experiments every 1-2 weeks. These are the people who can pop into your project and disrupt your user-centered design logic with their opinions because they may not trust what’s happening on the project due to a lack of involvement from early on. Involving these people in processes like “Design Sprints” "user interviews" or user-testing" helps everyone align and share ownership of information, decisions, and ideas.
The more you can involve these people in the user logic & allow them to gain user empathy —early on in the process and not just throw them into the designs, the less they will tell you how to design (their opinions) and they will build trust with you. The more they trust you, the happier you will be as a designer.
INFORMATION TO GATHER
• Who decides on product and business? — Design reviews
• Who has technical knowledge we can use (SME) — Subject matter expert
• Who can help us with finding users to interview? — Design support
• What are their schedules and what time is good to have design/progress reviews?
• You may want to interview them on company goals and the success of your project, this is called a "stakeholder" interview, do this early on in the project.
RACI FRAMEWORK
Responsible = the day-to-day team
Accountable = stakeholders - by-weekly reviews with them
Consult = Subject Matter Experts - invite to work closely with/ team
Inform = people who are curious about the project - weekly email update
05
Deadline
CAPTURE
Are there any important deadlines that need to be externalized that could inform the progress & priority of our work? Examples: Conferences, Budgets, Social/public announcements etc…
06
Team
CAPTURE
The team is working on the product. Who are the people responsible for the project? This is usually PMs, Designers, & Engineers.
• Are they all on the same timezone?
• Are there recurring meetings in place that are not part of the day-to-day product operations?
• Any vacations or large amount of time being taken off coming up that the team needs to know about?
07
Risks & Mitigations
THE WHY
A risk is anything that can block, disrupt, or fail a project or software. A risk can be turned into a question, and that can give you work by answering that question. Example: (Users will not want video instructions —to—Will video instructions work best for our users or what type of instruction works for our users)?
You’ll want to know what makes a project successful but just as important, you want to know what will make a project unsuccessful. After you learn about the project context everyone should have time to call out and prioritize risks so that the teams can start focusing on activities that they intend to mitigate/solve—the most important risky assumptions first
BUSINESS SIDE
People on the business side of the company will love you when you do this. They will always understand the project & company problems more than you. You’re way more valuable when you can help them (the business) get answers to their questions by talking to their customers. When the business is software, this is UX, and this is where you are one of the most valuable tools the business can have.
QUESTIONS YOU CAN ASK
• What are the things that can happen that will make this unsuccessful and not achieve our goals?
• Let’s say we failed, what are the things you think caused us to fail? (pre-mortem)
• What’s the 1st thing we can do to start mitigating these unsuccessful events? (activities to start)
Capture all this information, keep it easily within view, revisit it often, map decisions based on it, & use it to onboard new team members.
TEMPLATE & EXAMPLE
Download Template