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?

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 an accountability

to the project. The meeting

helps to externalize information

that's important for everyone

to know and understand. Once
everyone in the meeting has an

understanding, we can use this

time to prioritize, align and agree

to certain priorities .

 

1st  THE BUSINESS GOALS

2nd THE PRODUCT GOALS

5th  THE DEADLINES

4th  THE STAKEHOLDERS

6th  THE RISKS AND MITIGATIONS

3rd  THE USERS AND THEIR GOALS

// THE BUSINESS GOALS:

THE WHY

-

You’ll want to know key performance indicators (KPI’s) that inform business analytics ex: lower # of support calls. You want understand the business goals and how they map to milestones that your design will need to achieve. 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 usually have questions on why we’re doing research. You'll need to inform business folks that by developing customer empathy and experimenting with solutions we will de-risk business unknowns and help to ensure product success. 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 a 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

-

It's important to understand what the business thinks of it’s possible product goals. These are not fine details but overall “what is needed to achieve business goals” within a piece of software. You can’t have a photo taking app if you don’t have a camera. These goals can be changed, depending on the research and solution testing outcomes.

 

 

 

THE PRODUCT PEOPLE

-

These people are usually subject matter experts, 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 - finesse and details should be applied to the coded product as well as the designs you made.

 

 

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 STAKEHOLDERS:

Stakeholder management

Stakeholder anxiety

Stakeholder interviews

 

THE WHO

• People that will lose their jobs if this doesn’t go right.

• Business people that need to make decision on budget and business
  results that meet company strategies and initiatives.

• 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 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” help everyone align and shared ownership of information, decision and ideas. The more you can involve these people into the USER LOGIC EARLY ON IN THE PROCESS and not just throw them into the designs, the less they will tell you how to design and they will build trust with you. The more they trust you, the happier you will be.

 

 

THIS IS YOUR AREA OR A PM WILL TAKE CARE OF THIS

-

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

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 find users?

– What are their schedules and what time is good to have design reviews.

– You may want to interview them on company goals and success of you project,

   this is called a "stakeholder" interview, do this early on 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. 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 will intend to mitigate/solve the most ASSUMED risks.

 

 

 

THE BUSINESS PEOPLE

-

They will love you when you do this. They will always understand the 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 weapons 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?

What’s the 1st thing we can do to start mitigating these unsuccessful events?

 

 

 

// 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 and user profiles:

 

– Targeted Markets

– Target Users

– Targeted Users Goals & Problems

– Internal Users are different than consumers

 

 

You want to ask questions to get the basic user
profile level information, see below:

 

– User name and about them

– Their goals

– Their pains or problem

– How do you get a hold of these people for research and testing

 

 

 

 

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

 

 

 

 

Lets start with Project #1