3

Build successful products by aligning stakeholder and user needs

 3 years ago
source link: https://www.devbridge.com/articles/agile-product-prioritization/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

Build successful products by aligning stakeholder and user needs

Zachary Ehrmann

Learn how to set priorities that get results. 

I've been mesmerized by the game of golf for as long as I can remember. I didn't care much for practicing when I was younger, expecting to improve naturally. My inability to improve via osmosis, combined with my competitive streak, was not a good combination. One day my dad sat me down and said, "How do you expect to improve without practicing?" I fought him at the time, but in retrospect, his sentiment makes perfect sense. The world's best athletes are notorious for the work they put in when the bright lights aren't shining upon them. Tiger Woods practices for 12 hours a day.  

IMG_8386_(1).JPG

As I’ve grown and am now working as a product manager, I see how the lessons golf taught me extend to my career. Both professional and recreational arenas require patience, humility, and an insatiable desire for practice. Just as weekend warriors can’t expect to be scratch golfers without putting in the work on the driving range, product teams can’t expect prioritization efforts to be “fast-tracked." 

You cannot expect good outputs without proper inputs. In this article, I’ll share what I’ve found to appropriate inputs for prioritization, how to collect them, and what to do once you have them. 

Build stakeholder alignment. 

When walking up to the tee box to tackle a challenging hole, I’ve often felt a pit in my stomach. I've had that same uneasy feeling navigating prioritization and dealing with unrealistic expectations (“Why can’t you address everything on this list?”), second-guessing ("Are we doing the right thing?"), or worse, corporate politics ("Did you make sure to run this past [insert anyone's name]?”) Prioritizing work can be uncomfortable. 

The exercise is remarkably subjective, with a long list of vested parties (product managers, engineers, designers, researchers, users, marketing/PR, executives, sales, and customer support) influencing the outcome. The "pit in your stomach" scenarios often occur because of misaligned objectives from those involved in product decisions. Each stakeholder has different motivations, and opinions on what's most important for the product.

Regardless of the prioritization strategy you choose, it’s critical to remember that all of these groups need to be involved. 

There are many methodologies available for prioritization, each with benefits and drawbacks. The prioritization criteria I’ve found to be most ubiquitous in terms of relevance to stakeholders fall into three categories:

  1. Business value 
  2. User value 
  3. Level of effort  

I’ll go over strategies on how to tackle these three factors to build alignment with stakeholders below.  

1. Determining business value 

Without an understanding of the broader business context in which a product operates, you run the risk of inadvertently building something that could damage the organization's bottom line. Enter business value. Understand what a positive return on investment looks like to define success. Work with stakeholders to determine how a new feature or product benefits their business or aligns with organizational goals.

To help define business value, evaluate:

  • The stage in the product life cycle: Determine what is valuable to the business at the present moment to prioritize effectively. Focus on setting short-term goals around getting the MVP to market successfully. The initial goals should work towards the longer-term objective to scale, maximize revenue, and meet customer acquisition goals.
  • Company vision: Most companies have meticulously crafted mission statements. For example, Tesla’s mission is “to accelerate the world's transition to sustainable energy." Use a company’s vision statement as the North Star for every decision you make about a prospective product or feature. Tesla would never produce a gas-guzzling car. The same concept applies to the product your team intends to create. Ensure the product vision complements the mission and values held by your client’s organization. 
  • Stakeholder input: Experienced product professionals know the value of and how to build strong stakeholder relationships. Sit down with vested parties to understand what they feel is essential for the business and why. I often schedule time to talk one on one with the key decision-maker first (to avoid groupthink), and then bring a collective group of stakeholders together to refine and build consensus. 

2. Identifying user needs 

It’s important to take the time to evaluate the user's need and how a new feature or product adds value. The most elegant solutions are meaningless if users derive no value from them. As product professionals, we need to work together with our teams to understand whom to speak with, when to talk with them, and how to engage them in a way that gives us the necessary information.

I recommend the following strategies to tease out user value. 

Gather observational research. The first step in understanding user value is ascertaining user needs. Create a discussion guide and spend time with users in their natural environment to uncover latent needs that have the potential to launch your product into the stratosphere. Airbnb struggled for two years before learning from users via a two-month-long research trip that poor listing picture quality was a deterrent. Founders Brian Chesky, Joe Gebbia, and Nathan Blecharczyk bought a camera, took photos themselves, and the rest is history. 

When face-to-face discussions aren’t an option, there are plenty of alternatives available to conduct meaningful observational research, such as Google Glass, dscout, and Maze

Collaborate with users. No one wants to expend energy to build a fully fleshed out design, only to learn that they missed the mark by not involving a user. Work with users to identify designs that are just right and meet their needs. Designs that don't satisfy user needs should be uncovered as quickly as possible, allowing the team to move on and consider new options. With that said, put thought into how and when to involve users. For example, presenting something akin to a wireframe to a user could be considered unprofessional. I've found that many research participants need to see a more developed concept to provide meaningful feedback. 

Involve the entire production team and the user. Work with engineering and design to develop a concept of what the group hypothesizes the user wants. Then, facilitate the research session by using blank half-sheets for the product team and the research participant to craft an improved experience together. 

Look for alternative context. Flip the script a bit. Instead of focusing on users, focus on how the organization offering the product communicates with customers such as an annual meeting or business conference, not marketing materials. I once attended an annual meeting of a former client, along with about 1000 other customers. Attendees that were promoted to partner in the last year were introduced by a long-time customer and given five minutes to speak. Many of the newly minted partners were brought to tears when discussing how much they cared about their customers. I witnessed firsthand how passionately those working at the organization felt, and the deep connections built with those utilizing their services. As a product manager, seeing this interaction not only made me want to do my best work for them but also helped me better understand how those working at the organization added value and communicated with users.

3. Assessing the level of effort 

Once armed with a sense of business and user value, it's important for the product team (i.e., engineers, designers, and product managers) to estimate the level of effort needed to ship the product to market. Having clarity around the effort helps resources plan and plot timeline. These team discussions generally improve the output and, ultimately, the product. 

Try T-Shirt sizing with the team. In the early stages of feature development, acceptance criteria and user stories have yet to be written. Design is in its infancy. However, the inputs available such as a rough sketch or conversations loosely defining desired functionality should provide enough context for the team to help clarify understanding of the task(s) and estimate scope. Work as a team to determine if the effort is small, medium, large, or extra-large. 

Allocate time to remedy risks and address unknowns. When developing custom software, there's always a chance of something unexpected occurring. Perhaps there's an API or integration involved or a complex design. Estimate time and budget to manage risk and address unknown issues that pop up. A large task with little risk is much more desirable than a smaller task with many unknowns.

Evaluate and rank feature priorities for the build. 

Once the inputs have been captured, the product team should have enough context to objectively assess priorities for the product or features. Start by recording the feature requests and evaluating them with the product team. Together, score the features according to a formula originally published in Product Roadmaps: Relaunched by C. Todd Lombardo, Bruce McCarthy, Evan Ryan, and Michael Connors.  

(Business Value + User Value) / (Effort) x Confidence = Priority 

Below is a sample scoring table for an application. 

good_output_(1).jpg

In this example, Feature A, despite its complexity, ranks first because of its high marks in business value, user value, and confidence. Although it's easy to implement, Feature C ranks lowest because of its low business value and user value assessment, and a high degree of unknowns (as indicated by confidence). 

While a formula cannot capture all of the nuances associated with prioritization, this method is best used as a tool to facilitate informed discussions. The table enables teams to look at all features relative to one another, using the same criteria. 

Take ownership of prioritization to get results. 

Be collaborative and consultative to ensure all parties on the same page. Partner with all stakeholders, empowering the whole team to take ownership of the solution, making for a better product. As a group, you’ll be able to address: 

  • Unrealistic expectations: With a firm understanding of context, you’ll have a much clearer understanding of what you can accomplish. 
  • Second-guessing: With a firm grasp of business values, user values, and technical effort required, you’ll feel much more confident in your approach. 
  • Politics: Having stakeholders involved with the product team, and owning outcomes together, eliminates the need for unnecessary red tape and approvals   

With a clear sense of purpose, you’ll be prepared to handle issues blocking production that would otherwise elicit the pit in the stomach sensation. Whether at the driving range or in the office, commitment to gathering inputs (and changing course based on what we learn) will sharpen thinking and ultimately drive results. 

Time to tee it up! 


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK