Have you heard? My new book Continuous Discovery Habits is now available. Get the product trio's guide to a structured and sustainable approach to continuous discovery. 
“I wish my leadership team would pick one strategy.”
“I wish my engineering team would contribute ideas to our project.”
“I wish our user experience team would ask for my input earlier.”
“I wish our sales team would stop saying yes to feature requests.”
Instead of wishing other people would change, maybe we should start by changing ourselves.
Your Leadership Doesn’t Define a Clear Strategy
If you want your leadership team to define a clear product strategy, start by defining a product strategy for your scope of work.
Run it by your peers, your boss, and other members of your leadership team.
Responding to a concrete strategy (even if it’s for a small scope of work) is much easier than creating a strategy from scratch.
Make it easy for your leadership team to respond rather than giving them a blank canvas. – Tweet This
Your Engineering Team Doesn’t Engage
If you want your engineering team to contribute ideas to your project, you need to ask yourself have you given them the necessary context to contribute.
Have you told them why what you are doing matters to the business. If you haven’t, how can you expect them to be motivated to contribute?
Have you told them the constraints under which you are working? If you haven’t, you are going to have to say no to most of their ideas which will demotivate them from suggesting ideas in the future.
Have you reassured them that they are just as likely to have a good idea as you are? If you haven’t, they are likely to think it’s their job to write code and your job to generate the ideas.
Give your engineering team the context they need to be able to contribute ideas. – Tweet This
Your User Experience Team Doesn’t Ask for Input
If you want your user experience team to ask for input earlier, you need to make sure that you are available when they need it. If you don’t, you’ll block their work and they’ll move on without you.
If they ask for your input and you criticize it without first being curious, they’ll assume you don’t respect their expertise and they’ll stop asking for your input.
Assume your user experience team had good reason to make the decisions that they did.
Be curious. Ask why before you criticize. – Tweet This
Your Sales Team Says Yes to Feature Requests
If you want your sales team to stop saying yes to feature requests, you need to share with them a compelling story of what is coming so that they can share a compelling story with their prospects.
If you don’t, they’ll do anything they can to close the sale, including saying yes to feature requests.
That’s their job.
Your job is to create a product that satisfies the market, your sales team’s job is to close the next prospect. – Tweet This
There will always be tension. But you play an equal role in managing that tension.
Start By Changing Your Behavior
We underestimate how much our behavior influences other people’s behavior. – Tweet This
It’s easy to sit back and blame somebody else. But that doesn’t get us to where we need to be.
Stop wishing other people will change and focus on what you can do differently. You’ll be surprised by how often people respond in kind.
Are you interested in developing your product skills? Subscribe to the Product Talk mailing list. You’ll get:
- A new article every Wednesday,
- Book recommendations and worthy reads from around the web every other Sunday,
- And you’ll be the first to hear about the upcoming Product Talk Academy where you’ll get a variety of opportunities to invest in your product skills.
Love this week’s topic! Another great post Teresa.
Thanks, Lorena!
The tip for redirecting sales is spot on.
The extent to which a product manager can “just do it” really depends on the environment.
In my first product management role, I transitioned from having been a software engineer for over a decade. My company at the time paid for me to take the “Practical Product Management” course from Pragmatic Marketing. When I came back, I immediately began scheduling prospect interviews, something no one else at the company had been doing. It stirred up a little bit of concern, but no one stopped me.
At a different company, I didn’t agree with the common practice of dictating design details in my requirements specifications, so I instead documented use cases with acceptance criteria. Management reacted negatively, recommending that I revert to dictating design details. But I soon realized it wasn’t a “recommendation” – it was an order. This sort of reaction to my initiatives was common at this company, even when I used consensus-building approaches to facilitating change.
Fortunately, most of my companies have welcomed my “just do it” approach. But some environments truly are disempowering. I wrote a blog entry about this issue back in 2011.
Contrary to romantic conceptions of leadership, great leaders require empowerment. Sometimes they recognize opportunities for such empowerment and take advantage of them. In other cases, they simply extricate themselves from genuinely- and hopelessly-disempowering environments.
Roger, I agree. There will always be aspects to any environment that are immutable for whatever reason and each product manager has to decide whether or not they can accept those aspects.
However, more often than not, we assume some aspects are immutable that are not. It’s always worth trying before concluding they are immutable.