Looks Great

Every project, in any industry, has stakeholders. They may be a client, or a leader or customer internal to your organization, but there’s always someone who has a vested interest in the positive outcome of your work.

As a project progresses, you present plans, ideas, designs, and in our case, software, to your stakeholders for feedback. Often, your stakeholders will challenge you by critiquing the work you present. This can be frustrating, but it’s an important part of the creative process. Stakeholders naturally have a different vantage point on the work than the team does, so as long as the feedback is constructive it should be encouraged. Product Managers can ensure this happens by managing expectations and building great relationships.

Sometimes, though, you will run into a situation where everything you present to your stakeholder is met with positive reviews, little or no adjustments, and a blessing to continue. Superficially, this might not seem like a problem. In fact, it feels rather good: Your meetings are easy, you have leeway to be creative, and you get a lot of validation. But in reality, situations like this should set off your alarm bells.

Investigating the source

There are many reasons why a stakeholder would only have positive things to say about work they are seeing for the first time. Many of those reasons are good, but we are going to focus in on the ones that aren’t. Understanding the why’s will allow you to react and prepare for any downstream implications they might bring. Let’s look at a few.

At the top of the list is a rather rare occurrence, where you have a stakeholder who is no longer invested in the project’s success. This is usually a larger problem, but it has very real implications for your teams. Because the stakeholder isn’t bought in, they are more prone to provide positive feedback that validates whatever idea you already had. After all, it’s easier to just say “yes” when you don’t care. This almost never happens with clients, but it does rarely happen internally if someone is on the cusp of leaving your department, or even your organization, and doesn’t mind burning bridges along the way.

On a less odious note, sometimes you have a stakeholder who is too busy with their own tasks to be able to truly consider your project work. This is actually a sign of trust in you and the work you put out, which is a positive. But, without that critical eye, your work might not be the best it can be. This happens internally with executives and leaders who have very busy days, and it can also happen with clients who trust you–perhaps too much. In fact, it’s more common to see this from clients, because they hired you to shore up their gaps. In other words, it’s easy for them to throw the ball over the net.

A more common occurrence is that your stakeholders might not have a background that allows them to provide constructive feedback.  This can happen internally (which is a training issue), but is more common with clients who might not have exposure to software development, design and user experience. In many cases, you will get positive feedback from these stakeholders because whatever you are showing them is probably significantly better than what they are used to, so it all seems wonderful.  

Finally, let’s not discount the notion that your stakeholders genuinely love the work you’re doing! If there is true enthusiasm and excitement around the work, then you really have hit your stride, and you should feel great about it. However, even when things are going well, you have be careful, stay vigilant, and don’t fall into the complacency trap.

Seeking challenges

Now that we’ve thought through some reasons why your stakeholders might not have critical reviews of your work, we can start to consider how to respond. Broadly, the actions you can take will fall into two main categories. You might end up employing both, or only one, depending on the context of your situation.

The first is to add more structure to your feedback sessions.  The goal here is to find ways to prompt feedback through specific questions. You can pinpoint the areas where you are unsure, and you can explain the decisions you made to get to where you are now. Doing so will help set the stage for future sessions, and ideally you and your stakeholders can fall into a rhythm. This is effective for stakeholders who are very busy, and it also works well for those who don’t have a good basis for how to judge the work. Eventually, you and your stakeholders can fall into a comfortable routine, and your feedback sessions will be more productive.

The other strategy involves finding ways to get feedback from sources beyond your stakeholders. This could be from peers inside your organization, from other leaders, or even trusted friends. In a similar way, you can prompt their feedback by explaining where you have made decisions, and get some guidance on how others feel about what you’re doing. While the feedback you get might not be the same as it would be from a specific stakeholder, you are likely to get some dissenting ideas, questions, and comments that will help to make a better product.

Of course, in addition to the above strategies, you should be employing user research as a means to help you and your team gain perspective. That’s something that ideally should happen alongside stakeholder feedback, and is definitely a best practice when making any new product.

Driving forward

Challenges to your work are a critical part of creating something great. Ultimately, the success of the project rests on your shoulders, and if you aren’t getting challenged in the right way, you run the risk of working inside an echo chamber or succumbing to groupthink. Even when the feedback is all legitimately positive, it’s of the utmost importance to remain vigilant about seeking out constructive challenges to your work to avoid these pitfalls.

There’s also one stakeholder who we haven’t yet mentioned, and they are the best equipped to ensure the project is a success: You.

If no one else is going to offer you challenges, then you have to take up that standard and run with it on your own, seeking out the challenges you’re missing. You’ll learn a lot, and your project work will be better off for the effort.

Phil Johnson is a Director of Product Management at Postlight. Drop him a note: philip.johnson@postlight.com.