What Makes a Great Product Manager?

It’s a question I get asked often by my students, clients, and people in the community. What is it that separates the good Product Managers from the best? What qualities in my potential candidates will let me know this person is the real deal?

To me, there’s one thing that stands between a good Product Manager and an exceptional Product Manager. It’s not wireframing. Not coding. It’s not communicating with developers, or sizing markets.

It’s the ability to kill feature ideas before they are built.

Wait, what? Shouldn’t it be the opposite of that?

Too many people think that a great Product Manager is the idea man. The visionary. The Steve Jobs. The feature god. This is just wrong. 

Ideas are dime a dozen, and anyone in a company has the ability to come up with a great idea. The biggest problem we face at software companies is that we have too many ideas. More often than not, we end up building most of them in hopes that something will stick. We spend countless hours creating feature after feature, and releasing it to customers with our fingers crossed. Then no one uses it.

It’s not hard to build things. It’s hard not to build things. It’s so hard to stop ourselves from getting overly excited about a potential feature.

A great Product Manager is the destroyer of bad ideas. She filters out the good ideas from the bad ideas by testing them early with customers. Then, she needs to be able to look the person who came up with the idea in the eye and say, “I appreciate the feature idea you came up with, but we have tested it and we should not build it. It would be a mistake to build it. Here’s why.”

This is not an easy skill. This idea person could be the CEO, the CMO, or the developer sitting next to you. More often than not, it’s yourself, which is the hardest thing of all. She needs to be ruthless, yet compelling and understanding. She needs to be a focused experimenter, who can test an idea cleanly. Then, she has to communicate the results to a wide array of people who came up with these ideas in a way that is easily digestible.

When a Product Manager builds everything that comes her way, the product ends up feature heavy and complicated. Yet, so many Product Managers do this because they are afraid to challenge their managers. Managers, if you want to hire a game changing Product Manager, you need to be open to the fact that your feature ideas are going to be dissected and questioned. And most likely, destroyed. This should be built into your culture, so that no one feels like they cannot disagree with you. Otherwise, you will end up with a worthless product, and some very unhappy and frustrated people.

Product Managers – if you want to go from being good to great, take a lesson from Grumpy Cat. Get comfortable saying, “No”.




4 Signs Your Kanban Implementation Is Screwed

Kanban is a really effective tool that can help you visualize your work… when implemented correctly. I’ve been working on introducing and coaching Kanban lately, and I’ve found it’s not easy to make a smooth transition. If you are starting to use Kanban on your team, there are a few warning signs you should look out for that can signal that your implementation might not be going so well.

Warning #1: You have 30 minute conversations about the color of the card, the name of the columns, or how to filter out tags.

“What color should we make that task? Blue? No, we have blue already. Let’s do red. No red’s an issue. Can we tag it instead? How do we filter on tags?”

If your team would rather debate what color the card should be than talk about ways to get their tasks done, something is very wrong. There’s a term for this. It’s called bikeshedding. Bikeshedding is where we debate about trivial issues and ignore the things that actually matter. If your team has a habit of bikeshedding, then they are not using the Kanban effectively. All conversations should revolve around how we’re going to get the work done, where are we, and what we can improve. Of course at the beginning of an implementation, you’ll need to get the structure down. But, if it’s been 3 months and these conversations are still dragging on, you have a problem.

Warning #2: You don’t talk about goals or progress during standup.

Every morning we have a kanban standup that looks at the work to be done on the board and what everyone has accomplished the day before. After standup, we talk about where we can improve our workflow, which is usually apparent on the board. One day I noticed that we have been talking about what we’ve done each day, but I still wasn’t sure if we were making progress towards our goal or not. If Kanban’s purpose is to visualize your work, you need to make sure you are also visualizing progress. Otherwise, how can you tell if you are doing the work well? If your teams don’t have concrete evidence that they are making progress, it’s time for management to go back and set some measurable goals and communicate them.

Warning #3: Cards miraculously appear in doing.

The flow of our boards usually goes Backlog > Next > Doing. When a team member needs more work, they can move a card from Next into Doing, as we have already planned and prioritized those items. I’ve seen many times where we get into standup and find new cards in Doing that were never in Next. Of course really important issues might come up and you’ll need to deal with them, but this doesn’t happen every, single day. Teams that bypass the planning and jump into the work are often struggling with prioritization. Also, executives could be asking for many quick, unplanned favors that require the teams to context switch too often. Cards being created in Doing is a huge sign this could be happening to your team.

Warning #4: You make cards to remind you to deal with problems with the cards.

This is another form of bikeshedding. When one of my teams was doing continuous improvement on their kanban board, they would routinely come up with experiments that involved making a card to remind them to fix the problems with the other cards. For example, we saw that one team was having trouble with prioritization. So they decided to do an experiment to implement goals for the cards. Then cards appeared on the board that reminded them to set goals for the cards. This type of inception can lead to really complicated boards and take the focus away from getting the work done.


There are many underlying causes for these warning signs. Some I was able to mention, but a lot of it goes deeper. While I can’t diagnose every cause without working directly with your team, I’ve found the most of the common ones were these:

  • Kanban could be the wrong tool.
  • Your team might not be ready for it yet, meaning they cannot grok the concepts.
  • Your team cannot self organize.
  • Your team does not know how to prioritize.
  • There is no system for handling new work or quick tasks assigned by management.
  • Managers are not harnessing the valuable data they can get from the Kanban board.

and the one we rarely account for but is the mother of all problems

  • You did a really bad job explaining the purpose of the tool, which is above all, to visualize the work.

Every team is different, it may be a combination of these causes that are inhibiting your kaban paradise, or it could be primarily one. Teams also take some time to get adjusted to new tools, and that should be considered. If you’re experiencing any of these signs after a few months though, something needs to change. It’s better to recognize the warning signs early so you can act.

The Build Trap

“Move Fast and Break Things”

This mantra seems to have taken the startup world by storm since Facebook made it their motto a few years ago. I have heard countless CEOs say it’s part of their company culture, something that makes them innovative. You can even find some enterprises repeating this phrase to their employees at an attempt to channel startup culture.

There is a serious flaw with “Move Fast and Break Things”, and it’s that most companies see this as an excuse to stop analyzing what they intend to build and why they should build it. Those companies get stuck in what I call “The Build Trap”.

It usually happens like this:

After finding some kind of product/market fit and traction with customers, we raise money from investors and hire a team of developers. Now we also have a bunch of important people who want to know what we’re doing with their money. We want to show them how hard we’re working, so let’s make sure we’re constantly building and releasing. Right now the developers are building Version 1, but once that’s out what is next? Developers can’t just stop working; we need something for them to do.

Product Roadmap meetings are held and ideas are generated on what we could do build to increase our KPIs – drive registrations, more sales, etc. Ideas come up from Product Managers or Executives, and some seem like a good bet so we schedule them. When the time comes to build the product, we design and build the whole thing based off the ideas that we had originally.

This cycle continues until the company grows from 100 people to 500 people to huge corporations, where it becomes part of the norm and the way we do things.


And thus we fall into The Build Trap. The problem with this cycle is that our first ideas are not always our best. When we immediately jump into build mode, we don’t have much information on how our customers will respond to these products, what they would want to do with them, or if they even solve a problem. Our design or product decisions are not based on fact, but on our best guesses. Most of those guesses are wrong.

In order to base our decisions on fact, we need to take a step back and focus on THINKING more than BUILDING. Thinking gets neglected in companies because the act of thinking doesn’t directly produce something we can give to customers. Only building does that. This mentality is evident in our everday work lives. Look at the way we measure the success of our workers and our companies. All of our metrics are geared towards production of code or product. Even Agile standups – “What did you do today, what did you do yesterday?” If you haven’t delivered your items on time, you get penalized. If you have delivered your items on time, you get rewarded. If you can produce more than another person, you get promoted.

This is a very flawed system because the amount of things we produce is no guarantee of a successful company. Building is the easy part of the product development process. Figuring out what to build and how we are going to build it is the hard part. Yet, we are only allowed a few days or a week at the beginning of each sprint for designing and speccing this out. We completely neglect research and experimentation in favor of spending more time writing code.

If we want to create better products and get out of the Build Trap, we need to change our mentality. This is true for both startups and large corporations. We need to give ample time throughout the product development process for exploring problems, thinking of solutions, and testing those solutions with our customers. Employees should be rewarded for solving problems, learning, and creating products our customers want, not how much code they can produce. “What have you delivered today?” has to become “What have you learned about our customers or our business, and how can we use that to our advantage?” When we change our conversations to strategic thinking instead of production, we can create a culture that is truly innovative and competitive.

So the next time someone at work says “move fast and break things”, ask them “what are we learning by doing so?”

In defense of originality

“We’re the Amazon of cats.”

“We’re the Uber of drinks.”

“We’re the Netflix of hair care.”

“We’re the X of Y” seems to be all I am hearing startups describe themselves as these days. It’s become so prevalent, you can find youtube videos or dumb HBO shows that use these sayings in dialogue to mock entrepreneurs. When I was learning to pitch a startup at Techpeaks, we were encouraged to use these analogies to describe our new ideas. We were told that investors would understand us faster. I think overall this is actually hurting the quality and originality of products in the long run.

When someone asks what your company does, you should communicate the value to the user immediately and clearly. For example, if you are a wine delivery service that sent a few new bottles every month to my users to try so they can discover new ones, would you want to be remembered as:

“Netflix for wines.”


“Winernator – A way to experience and discover new and unique wines every month.”

Every description of the company should be about the value to the user, not somebody else’s valuable company that kind of resembles yours. But this isn’t the part that’s incredibly harmful. The problem is that these comparisons are starting to take a toll on the product and user experience.

As a UX consultant, I’ve been helping startups/ larger companies come up with their product strategy and create new business lines. I recently had a situation where my team and I had been working with a client who wanted to be the Skyscanner* of Mortgages*. When we asked the founder what value did he want to provide to his users, he talked a lot about the current problems in the market. He explained that he wanted Skyscanner because it allowed people to drill down on the right flights for them, something he wanted to do for his financial products.

Great. We had the information we needed to make a great experience for his users based off this problem of drilling down to the right products for the right users. We presented him with three different options for their site. He wasn’t satisfied. After a lot of back and forth he said he did not want these experiences, he wanted Skyscanner. So we made something that was a bit more similar to skyscanner with their filters and took it back. No. He wanted Skyscanner.

He literally wanted the entire experience  and layout to be a duplicate of Skyscanner… but for mortgages.

The experience for Skyscanner was made for people searching for flights, not mortgages. Users don’t search for mortgages the same way they search for flights. They will be in a different setting, in a different circumstance, with different concerns. You have to qualify people for mortgages. You don’t qualify people for flights. The requirements and the use cases are different, and the experiences don’t match up.

Unfortunately this isn’t the first time I’ve been in this position. This is what happens when you let another company’s value become YOUR product’s value. Founders think about their pitches and product positions so many times a day, that it becomes ingrained in them. If you are staring at other people’s products all day and reciting yours as an analogy to them, you are going to blur the lines between what is your product and what is theirs.

I am not saying don’t use a business model that works. I’m saying don’t think because it worked in one vertical it will work in another. Each product we build needs to be unique and original for our targeted audience. Every user’s reaction differs depending on what their situation is at that moment of need. If they are filling out very important forms, they might be incredibly careful, articulate, and neat. If they are taking notes in a meeting, they might be rushing to get things done. This doesn’t mean because they are writing that the same product will work or even be needed in both cases.

I would love to hear founders drop the X of Y analogies and start explaining their products for the value that they convey, not the other successes they wish to imitate. If your product is solving a problem in an original way, let that shine through. To me, that’s the better pitch.

[*Note: Analogies changed for anonymity’s sake.]