The 3 most important questions to ask your product stakeholders.

Asking your stakeholders the right questions early on in product development is critical to focusing discussions, encouraging product innovation, and ensuring product success. 

With the new year here, I thought it would be a good time to discuss ways to get projects off to a good start.

When initiating any project, it's good practice to get an understanding of your stakeholders challenges and project expectations.  Asking your stakeholders the right questions early on in product development is critical to focusing these discussions, encouraging product innovation, and ensuring product success. 

Product managers and analysts often start out by identifying a product's current state and eliciting high-level requirements from the product's stakeholders. Stakeholders include product owners, subject matter experts (SMEs), customers, clients, product users, partners, etc.

Some of the more common questions I hear asked are:

• What is the problem with your existing process/system?
• What do you want it to do?
• When do you need it by?
• What is your budget?

While these are all completely appropriate and necessary questions that should be asked, using these alone to drive your solution can often limit the potential value delivered to your stakeholders and can waste time and resources delivering something different from what the stakeholders expected.

Of course you want to understand the existing system and processes, but by focusing too much on an existing system's problems, you often end up with a myopic view of the stakeholder's real goals and the product itself when developing your product vision.

For projects which are designed to replace a legacy product, teams tend to assume that the objective of the project is to build the new system on time and within budget.  The result being epic, features, and user stories written to mimic the legacy system but with newer technology and platforms and perhaps a few new features.

But just getting a system built on time and within budget should not be considered the real objective. While this is definitely important, the real objective should be to accomplish something beyond the product itself.

 This leads to the first question:

1.       What are you trying to accomplish?

Because creating or amending any kind of product requires significant collaboration between development teams and stakeholders, it's critical for everyone involved to understand the context for those interactions. This requires some basic questions that need be asked at the onset.

I'm guessing a lot of those reading this have experienced this situation: Your friends and acquaintances find out you work with computers, and now is their opportunity to ask you all of those tech questions they've been meaning to resolve (this usually happens at a party).  I often get questions like, “I just upgraded my OS and can’t seem to do X in this application anymore, how do i fix it?” My initial instinct is to start out by trying to help them resolve their specific problem, but eventually, I almost always end up asking, what is it, that you are you trying to accomplish exactly? You will be surprised by the answers you get from this question.  It’s more common than not, that I find someone trying to accomplish a task either with the wrong tool for the job, an inefficient process, or both. Many times, the simplest solution is using an entirely different application, using the application a completely different way, or using some kind of external service to perform the activity.

Granted there may be some costs for involving new software, hardware, and services, which sometimes results in shock and horror that I'm even suggesting they pay for something; even if it is going to save them hours of time in the future. 

By asking your stakeholders what they are trying to accomplish first, before diving into their problems, allows you to understand your stakeholder’s goals from a business standpoint rather than from a systems standpoint, and tends to keep the conversation strategic rather than tactical.

Examples of strategic goals might be:

• We want our clients to be healthier utilizing our services.
• We want our users to find music all day that makes them happy.
• We want to create furniture for our customers that makes them feel organized and peaceful.

Get the idea?

When an entire team understands the business's strategic goals, it helps align team members during release and sprint planning processes by making it much easier to determine what features you need to focus on first, helps focus story prioritization, and also opens the team up to thinking about new and innovative ways of accomplishing these goals many times leading to disruptive solutions.

2.       Why do you want to accomplish it?

The next question to ask is, why do you want to accomplish this goal or objective?

Asking this question often reveals entirely different understandings of the product amongst stakeholders, leads to better stakeholder alignment, and gives everyone a more holistic view of the product. 

This question also helps guide your solution and architecture choices because it tends to bring out  non-functionalrequirements (NFRs) such as regulatory, system availability, volume, and performance requirements. E.g. the decision to install something locally or in the cloud.

The answers to ‘Why’ also provides support to your user stories.  In the generally accepted format of ‘As a user, I want to <do this thing> so that <I get this benefit>”. Tt’s the ‘So that’ that tends to take on a more meaningful purpose and understanding by your team, and can open up more creative and effective ways of accomplishing a task no one may have thought of before.

For example, a stakeholder may want to sort a report a specific way so that users can reconcile inventory easier.  A better understanding of the goal, may trigger a team member to suggest using a more automated approach with a scanner and/or mobile device instead of printing out a better sorted report.

3.       How do you measure success?

Finally, once the What, Why, and How are identified, you want to be able to measure the results of your new product features, and/or processes, to determine if they are accomplishing what you set out to accomplish.

In my example of helping my friends with their tech problems, I mentioned how some of them balked when asked to pony up some additional cash for a better solution.  When assessing costs, the more clearly we can demonstrate the savings your stakeholders will receive, the more justification you will have (or not have) for the cost of the solution. 

While it’s important to deliver features on time and within budget, this should not be the only method to judge the success of your project (unless of course your project was to introduce a better way to deliver on time).  You’re going to need other ways to quantitatively measure your success.  This may be measured through a variety of things such as throughput (how many customers can be serviced per day, how many widgets created, etc.), time (time to deliver, wait time, response time etc.), dollars (revenue, expenses, profit, etc), customer satisfaction (negative/positive survey comments, Net Promoter Scores) etc.  You and your stakeholder need to agree on these measurements and they are items you should be able to track throughout the project. I suggest keeping your success measurements to just a handful.

Once you have identified your success measures, you should be able to clearly demonstrate feature successes and failures to your stakeholders and to the entire team. Having this information makes it easier to communicate status and should lead to better retrospective conversations of what went right, what went wrong, and what can be done to improve things.

With your team and stakeholders understanding the strategic goals, the purpose of the goals, and how to measure your success, it should make for smoother and more innovative sailing on your new project.

Here's to new beginnings! Happy New Year.