Here's the context

You've been in contact with a start-up working in a specific market space and they have hired you to do research and developed a solution that solves the needs and goals of the business and the people they are targeting.

You have scheduled a meeting with them on Monday to get the information you need to start working.

Here's what you need to know

PROJECT

THE
KICK-OFF

MEETING

// WHAT IS THIS MEETING?

1-2 All DAY MEETING

// BEST TO HAVE A FACILITATOR

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

the meeting is to externalize

information that's important
for everyone to understand &
create a shared alignment on

what we are doing and NOT doing.

Essentially,We can use this time

to agree goals, plans, priorities, risks.

 

 

1st  THE BUSINESS GOALS

2nd THE PRODUCT GOALS

5th  THE DEADLINES

6th  THE TEAM

4th  THE STAKEHOLDERS

7th  THE RISKS AND MITIGATIONS

3rd  THE USERS AND THEIR GOALS

// 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 connecting user needs and goals, to the business needs/goals. You want to know how well your design decisions informed the business goals in small and large stages.

 

 

 

THE BUSINESS PEOPLE

-

They are all about RISKS & GOALS. You'll need to inform business folks that developing customer empathy (research) and experimenting with solutions that we 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)

Let’s say the project is over, the application is out and it’s wildly successful, what does the success look like for the software business?

 

// THE PRODUCT GOALS:

THE WHY

-

These are what we think the product will do for it's users, that will achieve the business goals. You can’t have a photo taking app if you don’t have a camera. SO a product goal is to "allow users to take photos of their food" These goals can be changed, depending on the research and solution testing outcomes.

 

 

 

THE PRODUCT PEOPLE

-

These people are usually subject matter experts, designers, product managers and engineers. These people will understand design way more then the business people and they will have questions around specific user interface components and interaction design details. PM’s ARE HERE TO HELP YOU. Remember, your design serves as a communication tool….that's it. End users don’t see your final designs, they see what the engineers built - use your designs to validate usability and align people to the "why" we are doing certain features.

 

Questions

What does your product need to do, to achieve
business goals?

If your product was a human what would it spend
most it’s time doing?

 

 

 

// THE USERS AND 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 AREA

-

Usually you’ll be called on to handle this part in of the meeting.

You need to capture just high level information about:

 

• Targeted Market

• Target Users

• Targeted Users Goals & Potential Problems

• What we want to learn about them (Learning goals)

Capture these points above

 

 

Questions

Who are the people that we are targeting to
achieve the product goals?

What do you 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?

Are they close by? Where can I find them?
Can anyone connect me to them?

What do we want to learn about them????

 

 

 

 

 

// THE STAKEHOLDERS:

Stakeholder management

Stakeholder anxiety

Stakeholder interviews

 

R.A.C.I Framework

Responsible = the day-to-day team

Accountable = stakeholders - by-weekly reviews with them

Consult = Subject Matter Experts - invite to work closely w/ team

Inform = people that are curious about the project - weekly email update

 

THE WHO

• People who's job is to make sure this is a success.

• People that 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 that 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 the process like “Design Sprints” or "user interviews" or user-testing" help everyone align and shared ownership of information, decision and ideas. The more you can involve these people into 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.

 

 

You’ll want to know the following:

– Who makes decision 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?

– 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.

 

 

 

 

 

// THE RISKS AND 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 work 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 learned 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 will intend to mitigate/solve—the most important RISKY ASSUMPTIONS 1ST.

 

 

 

THE BUSINESS PEOPLE

-

They 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!!!!!

Remember that, and make sure you get paid very well here. THIS IS NOT CHEAP WORK :)

 

 

Questions

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)