You’ve seen it 100 times in movies and TV shows. Something horrible is about to happen—an asteroid is hurtling toward earth, a pandemic is coming, zombies, whatever. Government officials in a secret bunker are arguing about what to do, and the conversation turns to how to alert the public. That’s when one character always says… “We can’t tell the public! It’ll cause a panic!” In your day-to-day as a product manager, do you ever withhold information out of fear of how product panic will spread or to subdue the difficulties of damage control? Does the cost outweigh the benefit with it comes to transparent product management?
Product Management Transparency Can be a Smart Business Strategy, But…
You already know this intuitively and from your own life. Think of just a few of the everyday circumstances in which being transparent could be totally counterproductive.
- It could ruin a surprise party.
- It could needlessly upset your young child’s worldview when you tell her that it was you who put that dollar under her pillow when she lost her baby tooth.
- It could hurt your friend’s feelings and ruin her night if you see her at a party and tell her you to think her outfit is all wrong.
We believe creating a culture of transparency in your business can be an effective strategy. That’s why our team here at ProductPlan takes an approach that leans toward transparency both internally (we share information openly and often across the company) and externally (we’re quite open as a company with our customers and the market).
Pssst… We’ve even built a tool into our product roadmap software that helps users facilitate transparency in their own companies: a Sharing Custom Views feature that lets teams share visions, strategies, and tactical-level plans with various internal and external audiences.
But the question “Is transparency a good idea?” can’t be answered intelligently without context. There are contexts in which being transparent can create value for everyone, and others when all you’ll do is unnecessarily upset people. Let’s look at a few examples of each.
Examples of Bad Product Management Transparency
Over-communicating
This is a common misinterpretation of organizational transparency. Many companies think that being transparent means telling their customers and the public everything. As such, they share every detail of their plans, their progress, their setbacks—every step their organization takes.
However, most people who are getting those frequent communications, don’t find those details interesting or worth their time. So in the organizations misguided attempt at transparency, over-communicators become a nuisance.
Emphasizing the negative
Companies sometimes also mistakenly believe a culture of transparency means going out of their way to let everyone know all of the bad things happening internally at their organization. Perhaps, the more candid they are with their market about their internal struggles, the more trust they’ll build.
Problem is, when these companies begin broadcasting all of their negative news, they might chase away would-be customers who mistakenly view the company as perpetually troubled.
Sharing Problems Without Solutions
Here’s yet another way businesses get transparency wrong. They alert their customers to some piece of bad news. “Here’s a bug in our software.” We lost some customer data.” “Sorry customer support is offline.” But then they fail to offer any solutions to those problems.
From the customer’s point of view, the company that they’ve given their business and their trust just wanted to let them know something bad has happened and… well, that’s about it.
Tweet This:
“Transparency can be a smart business strategy, but avoid over-communicating, emphasizing the negative, or sharing problems without solutions.”
So now customers are upset and the relationship between those customers and the company and the trust in them is strained.
Will this company get many benefits from being transparent? Our guess: Not likely.
Examples of Good Product Management Transparency
Sharing Both What You’re Doing and Why You’re Doing It
Transparency only strengthens your relationship with customers and your market to the extent that the information has value for those audiences.
So simply broadcasting a list of things your team is working isn’t the best use of transparency. Unless your customers know how those items on the list will affect them, sharing it won’t have much value.
Instead, share your plans for your product and explain why you’re confident it will benefit your users.
Sharing Problems With Solutions
Let’s say a user of your software product contacts your Customer Success team to let them know they’ve discovered an action in your software that causes the whole app to crash.
If you blast out a communication to your entire user base alerting them to the issue, technically you’re being transparent. But you aren’t being helpful.
If you immediately went to work figuring out both a short-term solution and a long-term solution and send out a communication explaining both the bug and your solutions for it, then you’d be using transparency effectively.
Always Being Honest (Positive, But Honest) With Your Team
Before you should even begin to worry about how much information to share with external audiences first focus on striking the right transparency balance with your own team. Your cross-functional team, after all, will be the ones responsible for helping you deliver a successful product to the market in the first place.
It can be extremely difficult to be an effective team leader—a key part of a product manager’s job—if you’re keeping information from the team. When you’re transparent with your team about the challenges the project is facing, you also empower your team to make better-informed decisions for the project.
But if you can find that balance—always sharing as much information as you believe your team needs, but not deluging them with details—you’ll be using transparency intelligently.
Transparency also applies internally within your prioritization process. So what are some ways you can democratize a transparent feature prioritization process to reduce friction and achieve organizational alignment?
4 Ways to Adopt Product Management Transparency When You Prioritize
1. Hear your teams, customers, and prospects out
Customers, prospects, and internal teams all have a unique insight into the product. Sales know what prospects need and want from the product. Support is keenly aware of pain points within the product that frequently causes friction. Engineering knows all about the inner workings of your product and where technical debt may be lurking.
Facilitating an ongoing dialogue with these groups of people plays a significant role in democratizing the product management process within your organization. Set aside time to sit down with different groups of people and listen to their feedback on the product. Remember not to take everything at face value. Try and dig into their requests to determine the root problem behind them.
2. Help internal teams
Tell your internal team how they can supplement their qualitative feedback with quantitative data. Data that can help you quantify the value of acting on requests are:
- Support claims that customer satisfaction is plummeting because you haven’t acted on a popular feature request in your product feedback forum. Does NPS data of the accounts request the feature support this claim?
- Sales swear they can triple their close rate if you simply build feature Y, can they make a real business case for it using data from closed-lost deals?
If you get internal teams into the habit of thinking more like a product manager when they bring your requests, they may even begin pulling the data before you ask for it.
Even if a request seems silly to you, do your best not to be dismissive of it. This does not mean you have to agree to build it, it simply means keeping an open mind as you investigate feedback and dig into the why behind a request. If you don’t understand at first, take the time to ask questions until you do. If it’s still something you simply won’t build, demonstrate that you’ve recorded the input somewhere, but be honest about why you don’t think it will happen. Never set false expectations.
3. Explain your process.
You need to make it clear that you do more than just take inputs. You are the strategic brain behind the product. It’s your job to drive your product toward its vision while making choices that support broader organization-wide objectives. If you are making prioritization decisions without your product vision in mind, consider rethinking your strategy.
Product decisions are made with several factors in mind such as; product vision, customer needs, business objectives, and technical requirements. There is no one-size-fits-all formula for prioritizing initiatives on a product roadmap, so it’s wise to have discussions with your team regarding your decision-making process.
How exactly you approach this is up to you, but one effective way is to group initiatives on your roadmap by strategic themes. For example:
- “This quarter we’re really focused on getting more users to move from our free to premium accounts, so we’re looking for initiatives that support that”
- “Right now we want to catch up on some technical debt clean up, so we’re focused on improving product speed and efficiency while also tackling some commonly reported issues”
- “We want to increase retention this quarter, so we’re focused on initiatives that help us achieve that”
Be transparent about what features are already in the hopper and what other teams have requested already. Plus, this gives your team a subtle reminder of the (always growing) volume of requests you’re working with at any given time.
4. Unveil your plans.
Don’t take feedback and run! Share your product roadmap with all relevant teams within your organization. Directly reach out to everyone who provided feedback and explains how they had an impact. Then, take the time to present your roadmap to the rest of your team.
In general, you’ll want to be prepared to explain the why behind every initiative on your product roadmap. Why is it there in the first place? Why was it prioritized above other features?
And don’t forget to explain the whats as well. What results are you expecting from each initiative? What key business metrics can you tie to each initiative? In what way does this initiative support our product vision?
Finally, don’t forget to thank everyone for their input! If you have a formalized procedure for gathering feedback from internal teams, now is a good time to review it. Reinforce the fact that all feedback plays a significant role in the development of your product roadmap. Moreover, if something simply won’t get built ever, don’t pretend that it will. Instead, tap into the power of product management transparency and explain why not. Your team will appreciate the honesty.
Product Management Transparency Takeaways: 5 Things to Ask Yourself
As we stated earlier, the team here at ProductPlan tends to favor product management transparency (both internally and for our external audiences) whenever possible. But we still take a strategic look at the information we’re considering sharing and weigh the pros and cons before we hit send.
Here’s a simplified version of that strategic approach we take. Ask yourself about any piece of information you’re considering sharing with your audience.
- Will it benefit our customers?
- Will it benefit our company?
- Will it benefit our product?
- Do our customers really want to know about it?
- Will it strengthen our relationship with our customers?
