Much of the research we do in UX is focused on making sure that our product is desirable.
We look outwards to determine if there is a market need for the product and how to best design it to meet our users’ goals. However, we can’t just limit ourselves to designing a desirable product and call it a day.
In our 3 Product Success Factors article we mentioned how a product also needs to be viable – i.e. it must make or save money for the business. It must also be feasible – i.e. it must be buildable at a viable price, within budget and within a reasonable timeframe.
To do this we turn inwards and talk to the internal stakeholders of the company.
But who exactly are they?
Who We Should Talk To
There is one person who we always need discuss matters with: the sponsoring executive.
The sponsoring executive is otherwise known as the person who writes the checks and has ultimate sign-off. We must understand their reasons behind the project, what they are hoping to achieve and what success looks like to them.
But what if we work for a larger organization. How do we know who to talk to then?
If this is the case, we consider the following:
- Anybody who has a stake in the project
- Anybody who feeds requirements
- Anybody who provides signoff
This way the Product, Technology, Customer Support, Marketing, Sales and Business analyst teams, who each have their own goals and definitions of success, get to have their say.
What we ultimately want to do is to channel all the information we discover to arrive at a consensus.
Why We Must Build a Consensus
Before a project can begin, we first need to make sure that we understand what’s best for the business, its users and product, making sure everything is in alignment. Without this understanding it’s impossible to have a clear strategy.
It’s fair to say that this is not always the easiest thing to do. Each department usually has their own ideas about which features and functions should be included.
The good news is that this is easy to overcome. And we can do this this by keeping conversations high level. So instead of focusing on features and functions, we talk about the department’s goals and whether or not the product is currently helping them achieve these goals.
What We Need to Find Out
We said in our Cheatsheet to Comducing Great User Interviews article, there is just one thing that either positions us for success or dooms us to failure from the get go – it’s all about asking the right questions.
And stakeholder interviews are no different.
Asking the right questions allows us to really understand the general objectives of the business as well as the specific goals of each department. We can then form a clear strategy on which all decisions will be based.
To get a clear picture of the business and its goals, we focus on understanding three key areas:
- What does the business do?
- How does it make money?
- Who are its users?
Problems with the product:
- What are we hoping to achieve?
- What are we trying to fix?
The competitive landscape:
- Who are the biggest competitors?
- Who are the biggest threats?
- What can we emulate that they are doing well?
- What are they not doing that we can capitalize on?
Department Specific Objectives
To get a better understanding of each department, we tailor questions towards that department. For example, if we’re talking to the Customer Support department, we can ask about their biggest call drivers, or for the Sales department what the biggest purchase drivers are.
While it’s hard get too specific here, as it depends on the department in question, there are some more general questions we can ask.
Just remember that we should still try to tailor our questions to be as relevant to the department as possible.
- What is your role within X department?
- What are the objectives for you and your team?
- How do these objectives support the overall business objectives?
- Does your team deal directly with users, suppliers or other external stakeholders? Please describe the nature of the interaction.
- How does the current product help you to achieve your objectives?
- How does the current product help users achieve their objectives?
- How would you define success for this department? Can you define specific goals or targets?
- What are your competitors doing well that you would like to emulate?
The Brief – aka Our Bible
There comes a time in any project where one of the following is likely to take place:
- There is a lack of clarity and focus
- Stakeholders feel they aren’t being heard
- Doubt sets in
To overcome these issues, we write a 2-3-page summary of what we heard and then once again speak to stakeholders – but this time only a select few according to the following:
- We focus on what everybody agrees on
- We list the contradictions – i.e. where one stakeholder disagreed with the other
- We speak to these stakeholders to get these contradictions resolved and signed-off before the project continues.
This document soon turns into the single most important tool at our disposal for the remainder of the project. We wonder how we ever managed without it. Now there is clarity and focus where before there was none. Everyone is on the same page and the project can be streamlined.
When stakeholders feel as if they aren’t being heard – as tends to happen with so many departments involved – we can point to this document and assure them that they aren’t being forgotten about.
When doubt sets in and decisions start to be questioned, we can refer to our document and state that we are doing what we agreed upon and there are clear reasons behind it.