Getting Sales + Product In Sync


What does an effective sales team look like at a product-led organization?


“Sales already promised it.”

I once joined a B2B company as a Product Manager in the the middle of the year, so their entire product roadmap was set and in motion.  My team was responsible for building a feature that I quickly realized did not align with our strategic initiative for the product. I questioned the purpose of this feature, and was met with the worst possible answer: “Oh, well the sales team promised it to one of our big customers, and they’ve already included it in their signed contract.” So we had to build it, and we had to build it fast, as the deadline was looming.  

With no other option but to get to work, we began interviewing, prototype testing, and gathering feedback to understand the client’s hopes for this added feature.  The results? They essentially wanted it to predict the future, which even the best of our developers assured me they could not do.  Needless to say, we didn’t have high hopes for satisfying expectations.  But instead of scrapping the feature like we should have, management instructed us to continue building “what we could.”  We couldn’t meet our customer’s end needs, but hey, at least we would meet our contractual obligations. We spent time, money and effort on a useless, disappointing feature that should never have been promised to our customer in the first place.  

So what happened here? Well without all of the above context, it might appear that this failure of a feature could be attributed to bad judgement or incompetency from Product Management.  In fact, whenever I hear a company complain that their Product Managers “lack vision,” I am not surprised to learn later that the real problem stems from a similar process to the above example.  A Product Manager is not given room to explore and identify what to build next when they are constantly behind schedule, chained to roadmaps that are full of untested features for customers who have already signed their contracts.  So who promises all of these shiny features that hijack the next 6 months of builds and hinder Product Management’s processes? The sales team.

Put simply, sales processes can be the downfall of an otherwise good Product Management process.  

How did we get here?

In traditional B2B companies, sales was the driving force behind strong businesses.  Without a great sales team on the ground bringing in contracts and solidifying clients, there would have been no company to run.  Salespeople were motivated to reel in the big fish because their salaries reflected each closed deal- client signatures were directly correlated to success.  So it’s easy to understand why it became the norm for salespeople today to promise the world in features just to snag that name on the dotted line.  

But when sales returns to the office with a new client to answer to and a list of contractual features to implement, they become the ones leading product development- not the Product Managers.  This results in a backlog so congested and long that teams struggle to keep up and satisfy requirements quarter after quarter.  There is never any time for Product Management to think strategically and proactively about the product, so a complex hodgepodge of one-off, usually broken features is delivered instead.

I’m not saying that the whole system of sales is inherently destructive.  Especially when a company is just starting off, signed contracts are its lifeblood, and product teams can really benefit from these early clients and adopters that sales works so hard to bring in.  Catering to these early clients’ needs and iterating around their feedback is necessary, and it ends up benefiting both sides of the relationship.

But as a company starts to grow, this kind of symbiotic relationship is no longer the most sustainable or beneficial model for an organization or its clients.  With more customers on the roster, the goal evolves into building a product that will scale and appeal to many, not one that satisfies the exact needs of a select few.   It’s hard, however, for the sales team and the overall company to break these habits of including the customer in the development process. When everyone is used to co-creating instead of thinking strategically, companies miss the big picture.  And this is where a reactive process becomes dangerous to the overall organization.  These product teams have not learned to look forward in order to plan their strategy, and get stuck building from a list of requests that reach short term profits and meet invalidated goals.

How do you become a product-led company?

For your sales and product teams to work in blissful harmony together, two things need to change.  First, sales needs to rethink their process from a product-led company point of view.  Second, your organization needs to shift their sales team’s source of motivation so that compensation does not directly correlate to signed contracts.

How do you teach product to sales?

Sales should continue to be the first line of contact between the organization and the client- a focus on building strong relationships and a desire to help those potential clients get what they need is still key.  But the method at which they approach this relationship must change.  Sales teams could benefit from the same user experience or user interview techniques that product teams rely on.

Clients typically talk in solutions- they’ll say things like, “we need a button for this” or “we need to build an app to give our customers this.”  But it is your internal product team’s job to hear these solution ideas and work backwards to identify their actual problem. Only then can they figure out what the best feature solutions may be.  Sales teams, then, should be talking to clients from this same product point of view.  They need to be able to empathize and understand their clients’ problems, so instead of, “I promise our company will build that feature you want,” it’s, “I promise our company can help solve your problem.”  Then, after gathering an understanding of the problem from multiple clients and seeing how it applies globally, sales can return to product with valuable information that lets the product team figure out how best to move forward.  This halts the dangerous cycle of promising unvalidated or planned features, and instead puts sales and product on the same page. Sales essentially becomes the first line of contact between product and client, rather than acting as an indirect conflict of interest with the product team.

How do you motivate your sales teams?

Stop relying solely on closed contracts to measure the success of your sales team.  It’s certainly the easiest way to measure success, but it also hurts your entire organization when used as the sole metric.

Often times, sales teams will bring in clients who ultimately are not the best fit for your business or your product.  This leads to a revolving door of unsatisfied clients, who loved what sales had to say but not what the product could realistically deliver.  Instead, motivate your team to not just close any contracts, but the right contracts.   Balance the number of signed clients with the strength and commitment level of that client. Then, teach your sales team to work closely with your product team by providing information that they are in a unique position to gather- feedback on problems, competitors, market trends, customer satisfaction, and value propositions.  

How can the product team Help?

By keeping communication open! The product team’s process, including their roadmap, should be easily accessible and clear to your sales team.  Imagine how much it will help sales to be able to walk into pitches with a strong understanding of what features are in build mode, what kinds of bugs are being fixed, etc.  They will be able to sell based on the reality of where the product is today and where it is likely headed in the future.  Just make sure to clarify to the sales team that there is a process in place, and just because something is in a roadmap as a considered feature does not mean it is absolutely getting built.

Every part of an organization affects Product Management.  Sales needs to be better equipped with the tools and processes of a strong product team, so that their client/company communication is in line with the realities of the product itself.  So encourage the following language the next time your sales team meets with potential clients:  “I completely understand your problem. Let me talk to my development team to see how we might be able to solve it for you.”

Learn more about this and other Product Management best practices by enrolling in Product Institute, our online PM school.

Our next class starts in May 8th! Sign up for our mailing list on the top right of this page to receive notifications regarding the class.



Effective Product Roadmaps

Product Roadmaps, in general, are confusing. The truth? Even the most experienced Product Managers still don’t have them fully figured out.

Three years ago I wrote a blog post about Rethinking the Product Roadmap, in which I advocated for a focus on solving customer problems instead of listing out features with deadlines. I received lots of feedback on the post, much of it praise, but also some criticism. The biggest takeaway comment for me was, “This is great for new products in the Discovery Phase, but what about accounting for products that we have already validated and need to build?”

In the time since, I’ve been working with clients to find what works best in real life situations. I want to share with you the framework that I have found, which allows for a balance of discovery and delivery and takes us out of that laundry list of features. But first, let’s talk about Roadmaps in general, and how they got us on the wrong track to begin with.

Think back, before Google Maps, to what a real roadmap was- those things with tiny, tiny city names and thousands of squiggly lines.  The ones that made it so you could never drive alone because you needed a copilot, someone to wrangle the giant map and dictate to you how to navigate from point A to point B. Yeah THOSE things.


Well that’s where the term Roadmap actually comes from.  When using a roadmap, you always knew where you were and where you wanted to go, and you had all these different routes to choose from. Some routes were shorter, some were longer but more scenic. It was ultimately up to you to choose your optimal path. Product Roadmaps should work just like their namesake, but their intended purpose was lost somewhere along the way. Now, Roadmaps function more like Gantt Charts.

Gantt Charts are a project management tool used to keep track of timelines and due dates. While Gantt Charts are fine for large manufacturing projects, they do not work well for most software situations because of the uncertainty around development.

When we’re first deciding what software product we should be exploring, we don’t know what our users want, and thus we are not exactly sure what the finished product will look like. This makes it nearly impossible to estimate how long the product will take to build. Yet, we still use this Gantt Chart model to plan our work, which locks us into delivering solutions by certain dates. Teams get frustrated that there is no perceived flexibility in these plans, and management gets mad when teams don’t deliver on time. The result is a bunch of feature releases that don’t make a difference for our users.

Instead, we need a model that helps us take into account uncertainty and allows us the flexibility for both discovery and delivery. To do this, we focus on Product Roadmaps that are made up of outcomes, a theme, and hypotheses, and we leave out any unvalidated solutions or features.

Let’s look at an example I created of a completed Product Roadmap for one team. I’m using the New York Health Exchange’s website as an example of a product as I can easily pin down things that need to be fixed- like, lots of things. I’ve never worked with them, and I don’t claim to have knowledge about how they function internally, but I am a customer of the website. This is how I would approach improving the product if I were working with them.



The top section of our Roadmap outlines our Vision, Challenge, and Target Condition, which reflect the goals outlined in my post on Product Strategy.  A Product Roadmap should be aligned around these same goals and help communicate the tactics to reach them.

According to this Roadmap, Team X is working towards the overarching goal (or Challenge) of getting 99% of people who create an account on NYS of Health to sign up for insurance.

Now that we have our Challenge set, the team analyzes the customer problems standing in the way of them reaching that goal. This is the same process we outlined in the original Roadmap post. Let’s say that after user research, we find that the biggest problem for NYS of Health’s website users is that it takes a very long time to search for and find an ideal health insurance plan. It’s a confusing process and incredibly frustrating. It causes people to give up instead of sign up.

So Team X decides to tackle this problem, and sets a Target Condition that will tell them when they have reached a successful outcome. “Decrease the average time to find and purchase health insurance from 3 weeks to 2 days in Q2.” While users can only sign up once a year for health insurance, there are plenty of changes that could be implemented to make it easier once that enrollment period opens.

From there, Team X would figure out the top areas they want to explore or deliver on in Q2 to reach that Target Condition. We call these Themes. For example, the “Search Enhancements” Theme will include all the UX work needed to simplify the search for health insurance options.

In order to answer the question, “Why are we exploring this theme?” we write a Hypothesis or Problem Statement. When products are still in the Discovery Phase, we are still validating the problem and solution, so we want to state what we know and what we don’t know. Our Hypothesis should support that we believe our solution will solve the biggest problem.

So with our Search Enhancements Theme we are in Delivery Phase, and our Hypothesis is “We believe that by enhancing the filter options to reflect the top deciding factors that shoppers make when choosing a health insurance, we will make it easier for them to narrow down their choices and find the right health insurance.” We have already validated that people have problems narrowing down their choices to find the right health insurance, and we think that offering some enhancements to the filter options can solve that problem.

Our last theme, Subsidy Communication, is an example of a problem that is still very early in Discovery Phase. We have identified that there is a very low conversion rate for people who qualify for Subsidies, and we want to investigate why that is. We have a few ideas but we have not yet validated them. So we need to clearly communicate our Hypothesis, highlighting what we know (“the people who would get Health Insurance for almost free are converting at a very low rate”) and what we don’t know (“we are not sure if people leave before they know if they whether or not they qualify for subsidies, or if they just don’t understand our explanation of subsidies”).

After the Hypothesis section comes the “Outcomes” – the most important part of our Roadmap. Here, we state what we hope to achieve by solving this problem or proving this Hypothesis. Each Outcome should relate back to the Target Condition in some way. All of our work is going to help us reach the Target Condition, so it would be a pretty boring Roadmap if every Outcome for each theme is just a repetition of that goal. Instead, think about how each of those changes or improvements signals a move towards your goal.

For example, with the Search Enhancements, we can tell if we are making it easier for people to search by measuring the qualitative components of frustration and the quantitative components of decreasing the time to identify an option. You want to make sure you are focusing on a good combination of both business and user outcomes in these sections, and make them measurable.

The last two sections deal with status and priority. The Status should state where you are in the Discovery versus Delivery phase. If you are in the Discovery Phase, you’re delivering to learn, so your focus is on experimentation over releasing features.  In the Delivery phase, you’ll be delivering valuable features and solutions to users. Sit down with your team and define what this means within your company, and then share these definitions with the rest of the company so there is mutual understanding.

Notice here that our Roadmap does not include any specifics on how we plan on tackling these problems.  This is because we are still experimenting with options- we haven’t laid out a plan to implement a set of features or solution components.

The above example is only one team’s Roadmap. There might be many other teams working towards this same Challenge, but they would all have different Target Conditions. These Roadmaps could then be combined into a Portfolio Roadmap that could be communicated across different levels of the business, like so:

Good Roadmap - FDS portfolio.007

It’s important to remember that a Roadmap is a communication tool first and foremost. It’s meant to align teams across time horizons and goals. Management should be goal and Vision setting with a timeline of  6 months to a few years, while teams should be looking at a smaller timeline, from quarters up to 6 months. There should be an accompanying strategy document that addresses how these goals help the company reach its Vision, but the Roadmap itself does not serve that purpose.

Roadmaps are a living document. If you invalidate a theme, update it. If you’ve changed a goal, update it. There is no reason you should be struggling to work around a Roadmap that does not work for you. When you’re communicating with customers, focus on how you are going to solve their problems, not how you are going to deliver their features. Your customers care first and foremost about the value they are receiving.




We teach Product Roadmaps in our 10 week online course at

Product Institute.

The next class will start in April 2017. Use APRIL17 for $100 off.

Sign up for our mailing list on the top, right hand side of this page to be notified when we launch our next class.



Stop Blaming the User

I’m finally going home from a long business trip and I’m very excited. But my experience with United Airline’s customer service this morning completely killed my good mood.

They keep blaming me for their mistake. It’s a story I know well because I see it so commonly in Product Management too.

When I was booking my return ticket from London to Newark, the cheapest option was for something called “Mixed Cabin”. I could fly Business Class between London to Dublin and then Economy from Dublin to Newark. Since I had to get up at the ungodly hour of 5am to get to the airport, I thought that could be a nice treat on my first leg. So I booked it.

Here’s what my reservation looks like from a few minutes ago:

Imagine how surprised I was when I checked in for the first leg on Aer Lingus and they gave me seat 27B. “There must be a mistake,”,I thought. So I told the flight attendant that I was booked through United in Business. She replied, “We don’t have Business Class on any of our flights.”

What a bait and switch! United is selling me something that doesn’t exist. It’s only a one-hour flight, so I’m not going to hem and haw all day, but I wanted to get to the bottom of it. So, I tweeted… because that’s what you do when you’re angry. What happened next, pissed me off more than the switcheroo.

The customer service agents considered this my fault, and acted like it wasn’t a big deal.


As someone who doesn’t work for an airline, how am I supposed to know that Z class doesn’t exist on Aer Lingus? When you purchase your ticket and it says “Business”, that’s what you expect. I don’t think I am wrong for being upset; yet United is telling me I am. If I went to a restaurant and ordered the duck, the waiter wouldn’t say “I’m sorry, we actually meant steak when we wrote duck. Here’s your steak, deal with it.”

I’m not telling this story to complain about United (well, maybe that’s part of the reason). The moral of my story is this: I see product teams commiting this classic mistake all the time. Product Managers love to blame the user. If the user doesn’t understand something, they are just stupid. If the user won’t tell us what they want, they are difficult. If they are calling to complain, they are ungrateful.

This is a dangerous mindset, yet it’s so prevalent. “Users don’t know what they want,” is the battle cry of Product Managers all over the world. It’s their excuse not to talk to them, because what could a user tell them that they don’t already know?

The problem isn’t with the user. It’s with you.

The Curse of Knowledge Bias makes you forget that as a Product Manager, you have more knowledge than the user when it comes to your product. You can’t understand how they could find something difficult when you can do it so easily. Users become just a thorn in your side, and if they went away and took all their complaints and wishy-washy answers to your questions with them, you could build THE BEST PRODUCT IN THE WORLD! You forget that if users went away, you would be out of business.

Recently, I was training Product Managers at a very large company. I always start off with a major focus on the user and trying to uncover their problems. We did a Product Kata workshop to help demonstrate this. The idea behind Product Kata is to take a step back, figure out what you need to learn, and create a test or step to learn it. In this case, the teams had to create a “paper pizza” for the user. Chris Matts helped out by being our user. They had 45 minutes to sell Chris $10 worth of pizza. Everyone immediately jumped in and started asking him “What do you want?” He answered, “I don’t know what I want. I like these things…”

After a while, everyone hated Chris. Someone even said, “I am going to pivot my pizza business to martial arts because Chris better learn to defend himself.” That was pretty funny, but also a prime example of the problem. This happens all the time in real life. The reason people were getting frustrated is because they were asking Chris, “What do you want?”

It is not the user’s job to know what they want.

It‘s their job to know what problems they have. You need to understand how to question them about their context, problems, and needs. If you cannot do this well, you will end up getting frustrated with the user. When I interrupted the teams from running around like chickens with their heads cut off, I asked them “What do you need to learn?” No one had even thought of that question (even though I just taught them they should!). They just set to work to immediately build a bunch of crap hoping he would buy it.

When they stopped and realized they needed to learn the context in which he was eating the pizza, they were able to solve it within 5 minutes. After 30 minutes of wasting a bunch of paper pizzas.

Sound familiar?

It is easy to blame the user, but it is so dangerous for organizations. It leads to culture of disdain for our customers and whole lot of arrogance on our part.

In large companies this is particularly true. When you have layers of bureaucracy, very long-term employees, and a million different departments separating you from the user, it’s easy to forget about them. Product Managers in these companies say, “We can’t talk to the user, that’s the job of another department.”

There are always ways to learn more about your customers, even if you have different departments. For example:

  1. Go talk to the customer service team. When I was working with a client at the beginning of the year, we had trouble finding users to talk to. We could easily talk to people who already signed up, but we couldn’t get in touch with people who dropped off. Customer service could, though. We talked to them about what we were trying to learn, and gave them questions to ask. Then, we met with them weekly to go over what they learned from the users. This helped a lot. If you can, even go so far as to take customer service calls a few times a month.
  2. We designed ways to learn more from our user in the above case, as well. We implemented things like Qualaroo to get feedback from users when they were dropping off. They were allowed to type whatever they wanted in a box asking, “What’s stopping you from signing up today?” We got thousands of responses and learned the biggest problems.
  3. When I was working for a B2B company, I was told I wasn’t allowed to talk to users because we would disturb them. I was the head of UX there. I fought for that ability, and was allowed to go with a sales team member. In that interview, I was able to prove that what we were building was not what the user expected. I brought that back to the team, and it gave me more buy in to keep doing more interviews. We ended up setting up a little feedback group of some willing customers and gave them access to tools earlier than others, and some extra hands on support. This proved invaluable for our discovery methods.

It’s easy to forget that the reason our businesses exist is because someone is buying our product. Someone. Not a nameless persona full of stats, but actual human beings. Human beings have feelings and needs. When I am paying United for a service and they are telling me, effectively, that I’m wrong, I feel frustrated. I feel wronged. That leads me to start to look for their competitors. I’ve bet you felt that too on just about any airline. How many times have you tweeted that they don’t care about you? Felt that they don’t care about their customers in general?

It’s the same for your users. How do they feel when you do this? Blaming them is not the answer. I never said it was easy to talk to users, but it is the only way you can understand and build empathy for them. This is what makes a good Product Manager. If you don’t want to talk to users, get another job. If you’re willing to give it a shot, remember to take a step back and put yourself in their shoes.

What is Good Product Strategy?

strategy dilbert

“What is your Product Strategy? YOU NEED A STRATEGY.”

When I replay this scene in my head, I can hear the CTO very audibly yelling (slash pleading) with our product team. He was on edge. We had been experimenting towards a very concrete goal for two months, and had made a lot of progress. We had learned so much about what was preventing users from signing up on the site, and it was a lot clearer which direction in which we should be going. BUT we still had to test our ideas.

This didn’t sit well with the CTO because in reality he didn’t want a strategy, he wanted a plan. He wanted a list of what we were going to build, and when we were going to build it. He wanted to feel certain about what we were doing when we all came in tomorrow, so he could measure our progress based on how much we built. It’s not his fault though. This is the way we were taught to think about Product Strategy.

Most companies fall into the trap of thinking about Product Strategy as a plan to build certain features and capabilities. We often say our Product Strategy are things like:

  • “To create a platform that allows music producers to upload and share their music.”
  • “To create a backend system that will allow the sales team to manage their leads.”
  • “To create a front of the funnel website that markets to our target users and converts them.”

This isn’t a strategy, this is a plan. The problem is that when we treat a product strategy like a plan, it will almost always fail. Plans do not account for uncertainty or change. They give us a false sense of security. “If we just follow the plan, we’ll succeed!” Unfortunately, there is no guarantee of success here. (I wish there was, our jobs would be SO much easier!)

These product initiatives aren’t bad, they are just communicated at the wrong time and with the wrong intentions. When we lock ourselves into planning to build a set of features (ehem, Roadmaps), we rarely stop to question if those features are the right things to build to reach our goals. We stop focusing on the outcomes, and judge success of teams by outputs.

We need to have a plan but the plan shouldn’t be “build feature x.” Our plan should be to reach our business goals. We need to switch from thinking about Product Strategy as something that is dictated from top to bottom, and instead something that is uncovered as we learn what will help us achieve our objectives.

Product Strategy is a system of achievable goals and visions that work together to align the team around desirable outcomes for both the business and your customers.

Product Strategy emerges from experimentation towards a goal. Initiatives around features, products, and platforms are proven this way. Those KPIs, OKRs, and other metrics you are setting for your teams are part of the Product Strategy. But, they cannot create a successful strategy on their own.

We need a few core things for our Product Strategy to be successful:

Vision: The vision is your high level, ultimate view of where the company or business line is going. In large corporations, you want to narrow this to the business line or customer journey. In smaller companies, this will be your company and product’s overall vision. Think long term here, and keep it qualitative. This is a good chance to talk about competitors, how customers will see you, and ambitions for expansion.

Challenge: The challenge is the first Business goal you have to achieve on the way to your longer term vision. Which area of your customer journey or funnel needs to be optimized first? It’s communicated as a strategic objective that helps align and focus your team around a certain aspect of product development. This can be qualitative or quantitative. Try to keep these still in broad, high level terms. This one is the hardest for me to personally wrap my head around, but check out the example below for some clarity.

Target Condition: The target condition helps break down the Challenge. Challenges are made up of smaller problems you need to tackle along the way. These are set in terms of achievable, measurable metrics. When you set a target condition, your team shouldn’t know exactly how to reach it tomorrow. They should have a good idea of where to start looking through.

Current State: This is what the current reality is compared to the Target Condition. It should be measured and quantified before the work starts to achieve the first target condition.


Product Strategy Animation

These all contribute to something called “Unified Field Theory”, which is explained very nicely here by Bill Costantino and Mike Rother from Toyota Kata. When we are building products, we have a threshold of knowledge. We cannot start on Day 1 and exactly plan to reach our vision. There are too many unknowns and variables. Instead, we set goals along the way, then remove obstacles through experimentation until we reach our vision.

This is best explained through an example, so we’re going to use Uber. Let’s pretend you’re a Product Manager working on the platform that allows drivers to sign up.

Please note: I have no affiliation with Uber so this is a guess as how they might line up their strategy if they chose to use it. The vision is from a statement their CEO made in an interview. The rest I am improvising for the example.

The CEO has stated that the company’s vision is to make Uber the cheap and efficient alternative to both owning a vehicle and taking public transportation. (He really said this in an interview, but everything after this is hypothetical).

So if we understand the Vision correctly, Uber wants people to use them as their sole source of transportation. They would first want to look at why other people are taking other transportation methods now instead of Uber. They may go out and interview people and find that in certain cities where Uber isn’t as popular, there is a very long wait time to get a car. They would compare this to other problems and determine how big it is in comparison. Let’s say it’s the biggest challenge at the moment.
So the first goals they may want to tackle is decreasing the wait times in cities where it’s exceedingly long. Let’s say anything over 10 minutes on average is too long, and we want to decrease that down to 5 minutes or less because we’ve seen in cities with those wait times, people are 80% more likely to use Uber.

This is now our Challenge: Decrease wait times in cities where it is over 10 minutes to less than 5 minutes by January 30, 2018.

Target Condition
As a Product Manager, you now want to figure out what is causing that long wait time. The problem in this case might be that there are not enough cars to serve that area. So our metric we care about now Acquisition of new drivers.

Our goal for our team should be measurable and achievable, something like: We want to onboard at least one driver for every 50 people in each city by January 30, 2017.

As the Product Manager responsible for the onboarding process for new drivers you would be tasked with contributing to that acquisition. You would first measure how many drivers per people in each city you currently have (Current Condition), then find the obstacles that are preventing new drivers from signing up today. Next, you experiment to remove each obstacle until you successfully hit your goal. The Product Kata explains how to do that.

So let’s step back and take a look at all that:

(You can download a blank copy of the Product Strategy canvas here.)

As a Product Manager, you don’t have control over all these numbers. The vision is set by CEOs, CPOs, Boards, and other C-Level Executives. The challenge is set by the next level of management (VP of Product for Each Journey or Business Line).

Direct Managers help their teams set effective Target Conditions. At the beginning these may need to be handed down from management. As teams get used to this way of working, the managers and team can work together to set them.

Once these four items are set and communicated, the team can start applying the Product Kata method to figure out how to reach the goals. It’s the Product Manager and their team’s responsibility to determine the user problems and other obstacles standing in the way of achieving that Target Condition. Then they experiment to solve them.

This aligns everyone around a strategic goal and vision. Every level of the portfolio has their objectives. Teams are held accountable for their progress towards the goal they are responsible for reaching.

Now you have probably looked at this and said “well this isn’t a product strategy, it’s a business strategy.” Yes, this does come off looking like a bunch of business objectives, but isn’t that why we built a product? To reach our business objectives? Product Management is the art of solving your customer’s problems to reach your business objectives. If you’re not doing both of those things, your product is just a fancy piece of code for show.

The next post will be on how to format your Product Roadmaps around these strategies, and how to communicate with stakeholders to encourage experimentation.


How to Educate Stakeholders

There is one question I always get during every Product Management workshop:

How do I convince/teach/educate stakeholders to work this way?


We need to change this perception.

The class has bought in on validation before building, a focus on problems, and defined metrics. They can see the value, but they are afraid they will return to work and get shot down. Often they do. Unfortunately, there’s really not much you can do about it as a Product Manager. Your job is not to educate and train your entire company on this way of working. It’s to create valuable products for your customers and your business.

The way I approach stakeholders is the same way I approach customers – empathize. Stakeholders aren’t at this company to make your life miserable. They are there to do a job. So start to ask questions and learn about them. How are your stakeholders measured for success? Usually they have concrete goals they have to hit. Learn what those are. What are your stakeholders problems? How can you solve them?

When you start empathizing with stakeholders, you realize that the things they are demanding or requesting relate back to assumptions. These assumptions are based on what they think will help them solve their problems. Become a Product Manager for your stakeholder. Explain how this way of working helps them achieve their goals. This has worked very well for me in the past, even with really difficult stakeholders.

Now, if you stakeholder still doesn’t understand this way of thinking and is not bought in, you need to change your approach. If you are having meetings where you are asking for feature requests, stop. Stop it right now. The meetings you set with Stakeholders and the way you run those meetings set the tone for your relationship. If the purpose of all your meetings are to gather requirements (aka feature requests) and communicate deadlines, this is the way your Stakeholders will view you – as a place to dump their requests and get status updates.

Flip those meetings on their heads. Use them to learn more about their business and the problems they are currently trying to solve. Give status updates on what you are currently learning and the goals you’re working towards, not hard dates on shipments. Changing the conversation allows your team to come up with the best solutions, instead of building just what the stakeholders or customers ask for.

Remember, you’re job is not to teach or educate. You need to explain clearly why you do certain things, but that explanation is enough. Start to draw the line. Work with your manager on approaches and tactics so you have support from above.

Have you tried all this and it’s still not working? I’m sorry. That happens a lot. Honestly, until stakeholders, managers, and team leaders want to change, they won’t. You can encourage them to start coming to the same conferences and workshops you do. That will help build a shared context. Many of my workshop attendees leave and say “I wish my manager was here for that.” If you are a manager, I would take that sentence to heart. You’re never too busy to spend time educating and improving yourself. But, if none of this works, you have to make a tough call.

Last night I was talking to James Royal-Lawson who put it the best way I’ve heard yet. When someone asks how to convince their managers or stakeholders, he replies:

What do you want to do with your career? Do you want to go into training and change management? Or do you want to be awesome at your job? If you don’t want to go into change management, find a job that allows you to be the best you can be. If you want to do change management, then we’ll talk.

If you want to change a company, that’s going to be where you spend all of your time. This is what I do every single day. You have to be ready for it. It’s a long hard role. If you want to be the best Product Manager, then try some of the above, or find a place that will let you grow.