We have to be able to look at the world through fresh eyes. Our brains [as pattern-seekers] try to keep us from doing that.
Our brains have evolved to take advantage of heuristics but it’s these shortcuts that can ultimately make us fail as Product Managers. In this video, Dave describes four of the many Anti-Patterns that we as humans can sometimes display which ultimately produce sub-optimal outcomes. In summary the four anti-patterns that are described in greater detail (and through the use of some pretty interesting storytelling) are:
Tyranny of Inertia – “That’s the way we’ve always done it”
Propinquity – Assuming your customer is just like you
Groupthink – Groups are capable of making some really poor decisions
The Journalist – Do not just report on what is happening, you must participate
We’ve all gone through it. One end or the other, we all have been involved in an interview as either the interviewer or the interviewee. When it comes to Product Managers however, its not always a black and white as to how qualified a candidate can be. Saying and doing are two different things and although it’s easier to separate the non-qualified from the potentially qualified. Finding the truly qualified from the potential can be a challenge and asking the right Product Manager interview questions can make a difference.
So how does one determine the best questions to ask a PM during the interview process? In my experience, the best questions are ones that target either problem-solving on the fly or providing specific, real-world examples of things that the candidate has done (unless this is more a junior PM role). Theory is just that, it’s easier said than done so below are some my favorite questions to ask, or answer during an interview process. I’ve also added some potential suggestions on how to answer them but that’s not to say there is only one right answer:
Name your top competitors (from a previous company) and explain how your product(s) differentiate?
This question is a pretty basic one that any PM should be able to answer. The thing to look for here is how well the response is verbalized. Does the answer roll off the tongue as if the question has been asked hundreds of times in the past? It should, as any experienced PM has been asked this question by Sales folks, Customers, Prospects, Analysts, etc…
Thinking as a PM, what is one product that you have found particularly interesting (besides Apple)?
I like this question because it shows where the candidate’s passions in Product Management exist. Are they impressed with the product because of the brand? Did the product re-define the market space? Was the product failing and they found a way to turn things around? Was it not even a success story but rather a failed product where lessons can be learned? This is not a right or wrong answer type of question as long as the candidate has a well thought out response and offers logic behind it. I specifically remove Apple from the equation as it seems too many people consider that their go-to product company and it’s too easy to provide a canned response. The idea here is to provide an answer that is unique.
Provide a specific example where you saw a release or product in trouble and explain how you adjusted?
This addresses how the candidate handles issues that always come up and by requesting specific examples, it allows for a level of credibility on the candidates experience. If he or she cannot come up with a specific example, that’s a concern because there’s never been a project without trouble. It’s like when someone asks what your weaknesses are and you state you have none…no one’s buying it. It also provides clarity into the candidate’s level of authority in previous roles. Was the adjustment large or small? If they fixed a feature that’s good. If they adjusted a product strategy that’s better. If they can provide quantifiable numbers on how they improved the situation that’s ideal.
There’s a subtle secondary reason for this question as well. The response takes the form of stating a problem and providing a solution. This is a great story-telling technique when selling…which is another skill that a PM needs to have. If the candidate can articulate the problem easily and then share the value they provided with their own experience then that’s a good indicator that they can also do the same when speaking about the value proposition of the product to a client.
Walk me through the logic you use to define what’s in a release?
In this question I am looking for something specific. I want to see how the candidate translates the strategic vision of the product into the tactical strategy of defining a release. It also is another indicator on the level of seniority that the candidate had in previous positions. I could have asked this question another way which would have been, “How do you define your roadmap?” but the reason I didn’t is because that question typically gets a theoretical answer and again, we are looking for tangible results. Did the candidate just go through their backlog and pick out the items that looked good? That’s certainly one way to do it. Did the candidate start by defining some higher level themes of the release? That’s a better way. Were those themes driven by market demand? That’s ideal.
The point here is to focus the answer around the heart of where successful Product Manager should live which is the line between strategy and execution and understand how well the candidate can move from one to the other. Strategy should drive the execution so I’m looking for a response that demonstrates this thought logic.
When you are in the middle of a release, how do you manage change requests such as newly identified time-sensitive needs?
The real question here is how do you manage change. Mike Tyson once said, when asked about how he would react to his upcoming opponent’s plan for the fight, “Everyone has a plan until they get punched in the mouth.” The same principle applies to software design (although slightly less violent). When planning a release, you start out with the defined scope, the resources and the timeline. Everyone should be on the same page with the plan. Then you start the work and somewhere along the way a production issue pops up that requires the same resources. Then a pending sale (it’s always a big one) just needs one more thing added to close the deal. Then a client calls up and says they are leaving unless you address this one need.
These “punches” can stop any good plan in its tracks. I’ve always thought that there are two processes required for any successful product release. There’s the original plan process and then there’s the change management process. The original plan gets everyone on the same page and sets the expectations around timing and scope and approach. Then the change management process is what people rely upon when new items emerge that affect the original plan. Its the process that keeps everyone on the same page when changes are accepted into the release and trade-off decisions are made. Changes are fine, as long as everyone understands that they are happening.
So for me, a good response here is to talk about the change management process and how it worked. I would like to see the candidate be able to articulate the process to show that they understand the importance of it and are familiar enough with it to describe how it ran where they previously worked. I also would like to see that the process incorporates the feedback from multiple areas within the company to understand the impact as well as I want to see some level of trade-off decisions being made. Either a decision to expand the release timing, add resources or cut original scope should be part of the process because nothing is free when you add to a release.
As a bonus question, if the candidate understands the above question well enough, I will follow up with asking for a specific example. Again, this steers the conversation out of the theory and into the experience of the candidate.
So those are my five questions to ask for a PM interview. Usually there’s enough time at the end to allow the candidate time to ask questions as well which is another huge tell on their level of interest in the position. Not asking question mean either they are not interested or not engaged with the opportunity. Even if you’ve talked with five people before speaking with me and have answered all your questions, still ask me something. Repeat a question if you have to because whether its true or not, not asking questions is a sign of not being curious. As Product Managers, if we aren’t curious, then we aren’t going to be successful.
It seems that so much effort is invested into product launch planning and execution that when a product release occurs, its easy to take a small breath and then jump into it all over again. That being said, there are some loose ends that always exist at the end of any product launch that need to be considered and will help validate the success, and possibly even help plan the next release. Some might argue that this is part of the a product launch plan but since this is not a requirement for launch I’m treating it separately (hence things like field enablement, marketing support, etc. are not listed below). Also, it’s probably not realistic to expect this to all happen in isolation from future release planning and other day-to-day tasks so expect to run this in parallel to other activities. Below are some suggestions on what to consider once your product release has launched. I’ve tried to prioritize the order though to help with items that may be started immediately after a release vs. those that may take time to develop.
Cleanup your work queue
I’ve used Rally quite a bit. JIRA is also another example of software that helps manage User Stories, defects and general tasks that relate to a product release cycle. Post-launch is an important time to go through this list. Typically, in a product release there are plenty of what I like to call “orphaned” items that were assigned to the release but were removed from scope either through a re-balancing effort, or a deferred status. While this may all be managed and agreed to by the team, the administrative tasks of keeping this up-to-date in the software itself may not always be upheld to as rigidly as everyone would like. This is a great time to comb through those items to make sure that they find their proper place. Some may be highly important to the next release (you’ll remember the meeting when everyone agreed that it’s OK to defer this item as long as it gets in the next release…but then in the chaos of getting the release out, everyone promptly forgets this item), some may just need to go back into the backlog for future consideration, or some may tie to a theme for the next release. Although tedious, not losing track of these orphans is helpful for future planning and removing them from the release keeps a clean record of the actual work completed.
Add to your Historical Roadmap
I’ve written a separate post on the importance of creating a historical roadmap so I won’t cover all the details here but needless to say doing this now, while things are still fresh in mind, prevents the need to comb through the software release details at a later date to remember what when out when. This is a simple task of tracking the top features of the release and the date that the release launched.
Hold a retrospective with the team
This is not necessarily the job of Product Management but its something that any team should do when a major project is done. Understanding what worked well, what didn’t and how to improve things next time is a critical step to understanding how to improve teamwork and become more efficient.
Organize any final notes or documents for future reference
Similar to cleaning up the work queue, making sure you have all of your own documents and records organized will help for future reference. I like the concept of electronic folders but other may prefer physical cabinet storage, or software organizational systems like Evernote or OneNote. Whatever you prefer, keeping your files (and important emails) associated with the release organized makes future reference needs much easier.
Measure the impact – Are you getting the return you expect (revenue, PR, client interest)
You set themes for the release right? You have reasons for building the product features correct? Revisit why you chose to build these features over every other feature request in your backlog and determine if your logic was correct and if your goals are on track. You may not know the results of everything just yet. For instance your revenue goals may not be immediate but you can start to gauge progress and understand if you’re on the right track. Are clients adopting? Is sales still excited now that they’ve seen the actual capabilities? Are your PR/Social efforts showing interest? Understanding the path you are on and if that path is a successful one will help in your decision-making progress for the next release.
Gather feedback and iterate
Speaking of client adoption, as clients start to utilize the new features, pay special attention to potentially new opportunities that may arise. It’s not unusual to discover a new use or a feature that you hadn’t thought of before until you hear about a client using it for their specific needs. This can lead to new feature requests for the next release, or it can even call out new features or areas to add into the product that hadn’t been though about in the past. Also it may make sense to find early adopters for customer testimonial gathering.
It can be tough to complete these tasks when the pressure from the release is off and the next release is heating up but taking some time to wrap up these items can really help with identifying next steps and making sure you are moving down the right path with your strategy and customer feedback.
One of the things I did at my first Product Manager job was start a Historical Product Roadmap. What’s a Historical Roadmap you ask? It’s a basic summary of past releases including a list of the main, larger release features and dates when the release launched. The example image above shows a nice visual summary of earlier Android OS version releases and the major features of each release.
This has been helpful to me multiple times over my career. There’s always some question that pops up on “When did we release feature “X” or an executive needs to quickly put together a presentation and needs a slide with, “the top five features from the past three releases” or something like that.
Creating a historical roadmap is a great addition to any Post-Launch Plan and can be as simple as an Excel document with 3 columns. Something like below is what I’ve used before. Nothing fancy, just enough to jog your memory. If you are following the other steps of the Post-Launch Plan then you’ll have the details in your release management software but this is a simple reference guide to speed up answering the questions that inevitably come from others.
Every Product Manager deals with coming into a new job and not knowing all the information. Whether you are new to the industry, new to the product or just new in your career, it’s difficult to be the go-to person for all things product related when you don’t know all the information yourself.
That’s why I really like the idea of creating a Product Manager’s Playbook. A PMPB is a document that summarizes the most important aspects of the product and serves as a high-level overview of all things necessary to know for a Product Manager to be successful.
It should start with some basic information such as what value the product brings, who your target customers are, what the industry looks like and even a strategic roadmap. You’ll find my working list of suggestions below, although there are others who have different suggestions.
I like to think of a PMPB as the CliffsNotes version of the job rather than an actual playbook that’s referenced all the time. The reason for that is that first, there’s no way you’re going to cover everything (you do have an actual job to do) and second, there’s a good chance that, depending upon your industry, by the time you complete this playbook, some of the information will already be out of date. That’s OK though because the PMPB is really an exercise in education. The process of collecting or defining the items you want to add to your playbook will help you learn your product, learn your customers’ needs and learn your industry.
Changing a product’s UI is a bit like removing a band-aid. There can be two approaches and both have a level of pain associated with them. One could publish the new product UI overhaul all at once, this is the equivalent to ripping off a band-aid. It’s a short transition but the pain can be somewhat intense to the end users who need to learn the new look and feel. The other approach is to gradually shift the UI from one look to another. This is the equivalent to slowly pulling the band-aid off which lengthens the pain (in this case, to the software development team) but lessens the intensity to the end users while the transition occurs.
I recently read an article about this topic which seemed highly relevant to feedback I once heard from an end user of the software I was managing. The article looks at the two approaches when transitioning the UI in a dramatic way and suggests that each approach has its benefits, but it depends on who your target audience is to determine which approach is best. In my case, the software I was managing was business-related, not consumer. The feedback from the end-user, when reviewing some potential UI changes that the team was getting ready to release gave us two critical points of feedback.
First, we received confirmation that the changes to the UI were good and she liked the new design (always a win). What she also shared which was surprising at the time was that although the changes were, in her opinion better, she was concerned that when released it would impact her ability to stay efficient at her job. Our software helped her research and status various tasks and she was measured on how fast she could get through the tasks. Although the new UI would eventually make her more efficient, she was so used to the way things were that she was concerned that the ramp-up time to learn the new UI would decrease her productivity in the short term. Even with an improvement, releasing this change to the end users all at once was potentially going to cause more pain than they wanted. Essentially, her feedback was saying that ripping off the band-aid was not a good approach for our end users.
This lesson is the same in the article which suggests that although many popular software companies like Facebook, seem to significantly adjust their UI all the time, the fact that they are consumer focused gives them a different liberty to do so than a business focused piece of software. They may cause some pain to their end users but they also present a new sense of interest and excitement with their products by making major changes all at once which is also valuable. For businesses however, the slow-removal band-aid approach is better and allows for less pain and adjustment without hurting productivity. Gradually introducing new UI concepts, or offering a beta trial (while the old UI is still available) helps transition business users over without too much pain.
The biggest take-away however was that when making the decision to rip or pull slowly, keeping the impact of the end-users in mind is the best way to make the right choice.
I’ve always enjoyed doing demos as a chance to understand first-hand the needs/concerns/tripping points of the product directly from a potential customer. There is a fine balance though of running demos for this type of feedback vs. ALWAYS being the person asked to perform a demo. Sales enablement is the only way to help scale the approach.
Product Managers should focus on sales enablement, not individual sales people
I don’t remember the source but one line that has stuck with me is the one that suggests that Product Managers need to enable Sales (as in the department), not sales people (individually). I think for the most part this makes sense. The article below certainly suggest this as well. When it comes to Sales, it’s better for a Product Manager to focus on the broad customer needs while enabling the sales person to then customize or cater towards the individual prospect’s needs.
Recommended Video: Prioritizing Your Product Backlog
YouTube: Value vs. Complexity & The Product Management Trap
While pretty basic, this video serves as a good reminder when reviewing your backlog and prioritizing your work. If you wanted to get more sophisticated you might consider adding profit numbers (through new sales or customer retention) as a third axis since there are plenty of times when a customer may think something is valuable but may not be willing to pay for it. At the very least, this would help sub prioritize the features/requests within the top quadrant. Knowing a specific dollar amount may not be worth the effort but a scale of 1-5 may help.
There are a number of factors that one can use as axis variables to create this matrix besides value and difficulty. As described in this article about the pitfalls of using ROI to prioritize your backlog, you need to find the metrics that make the best sense for your organization and can be somewhat stable across releases.
Recommended Video: Compromising Beauty In Product Design
For me a “Pure Product” has two elements to it. It’s simple and beautiful.
As Product managers, sometimes we focus on the numbers and the logic of how we do what we do. This video focuses a little more into why we should be inspired as Product Managers to do the work that we do with product design. I really like how Aziz Musa defines a “Pure Product” as something that is profoundly simple (mastering complexity) yet beautiful. These are two items that should be inherent product design requirements for all new features. In this video Aziz describes how he was wildly successful with achieving the business objectives of solving a product challenge yet he felt that in reflection, he still fell short of creating a pure product. His message is to not compromise on those product design objectives when developing and iterating as it can be a difficult path to come back from once the line is crossed. While perfection may never be achieved, striving for perfection should never be dismissed.
I love this. It’s something to keep in mind, especially when resources are constrained. Building the minimum necessary allows one to “prove out” the concepts and fail fast if the interest just isn’t there.
Minimally Viable Feature approach (MVF) is creating enough of the feature to test the adoption and usefulness before expending lots of resources on fully building out the feature.
ProdPad released an article about creating roadmaps without dates as a new approach for Product Managers. The thought is that usually these dates are not well known and regardless of how you preface the communication, ultimately you are judged by your ability to meet or beat these dates. Instead the suggestion is to look at things in groups of 1) What’s current, 2) whats’s near term 3) what’s planned in the future.
Is it fair to remove dates from a roadmap and just use these three groups instead? I think it’s fair to assume that, in many cases especially highly dynamic industries, anything beyond a quarter can be meaningless when it comes to timing. However, I would expect that with more mature markets and products, especially those following longer release cycles, there needs to be a further outlook of planned dates to help with managing the dependencies that come from a roadmap. While overall I like this approach (I actually have a very similar strategy when it comes to managing my own tasks) without some level of timing, there is a missing sense of urgency and a lack of coordination around the elements that, at the very least, are current. We’ve all heard the phrase, “A project will consume the time allotted” meaning if you give someone a week to complete a task, it is human nature to consume that full week. Without target dates, this begins to offer a level of flexibility that makes momentum difficult to maintain and scope creep to offset the goal of a minimally viable product.
I do agree that setting dates further out may be less meaningful and necessary but I would argue that not having them on shorter term events makes planning and setting expectations difficult with clients and other departments. I’m not saying this can’t be supported in a shorter-term document or release plan but in my experience, whenever you present a roadmap the question that inevitably comes up is, “When is that feature coming?”