Recommended Video: Inside the Mind of the Product Manager

Dave Wascha – Inside the Mind of the Product Manager from MindTheProduct on Vimeo.

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:

1. Tyranny of Inertia – “That’s the way we’ve always done it”
2. Propinquity – Assuming your customer is just like you
3. Groupthink – Groups are capable of making some really poor decisions
4. The Journalist – Do not just report on what is happening, you must participate

The post Avoiding “Anti-Pattern” Thinking appeared first on Pete Dudchenko.

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.

The post Five Product Manager Interview Questions appeared first on Pete Dudchenko.

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.

The post Creating a Post Launch Product Plan appeared first on Pete Dudchenko.

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.

The post Creating a Historical Product Roadmap appeared first on Pete Dudchenko.

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.

Here’s my list of what I’m adding to my PMPB:

• 3 Year Roadmap and Historical Product Roadmap
• Product Sheets/Value Description/Sales Collateral
• Pricing Information
• User and Buyer Personas
• Competitive Information (Battlecards)
• Industry Analyst Information
• Key Client Information
• Implementation Process Description/Flow
• Technical Architecture (or Marketecture)
• Launch Process/Checklist
• Financial Plan

Credit: I first heard about creating a Product Manager’s Playbook from Steve Johnson 

The post Developing a Product Manager’s Playbook appeared first on Pete Dudchenko.

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.

Read more about Making Drastic Changes to UI: Consumer vs. Business Apps

The post Changing Your Product’s UI. The Band-Aid Approach appeared first on Pete Dudchenko.

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.

Read more about Product Managers and the Product Demo

The post Sales Enablement and Product Managers’ Roles For Demos appeared first on Pete Dudchenko.

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.

The post Prioritizing Your Product Backlog appeared first on Pete Dudchenko.

I read a lot about productivity tips and how we as human beings are NOT multi-taskers. We like to think that we are but the truth is that we are much better when we focus on just one thing at a time.

Ever get lost in a project? I know I have. It’s that feeling when you have great momentum and you are super productive and you are undisturbed. It takes time to get into this mode. Like a train leaving the station you have to build up to this productive speed but once you do you are cruising along.

Moving from email to IM to 30 minutes of work and then off to the next meeting is not the recipe for gaining productivity momentum. Instead you have to guard your time from distractions. Below are a few techniques I’ve picked up along the way that have helped me stay focused.

Productivity Tip #1: Pick Just Three Tasks Each Day

Steven Covey uses the analogy of putting rocks into a container. You can only fit so many boulders (big tasks) before you run out of space. The remaining gaps can then be filled with smaller pebbles and sand (daily distractions and immediate needs). When it comes to work, your container is your work day and you can only fit a limited number of big tasks each day so pick the things you want to address before the day ends. I like to select three items each day that I want to accomplish knowing that my time is going to be pulled in a lot of different directions. This helps make sure that as distractions come up throughout the day, you can stay focused on what’s important while still reacting to what’s critical.

Productivity Tip #2: Turn Off Email and Instant Messengers

This is a judgement call. Obviously if you are client facing or dealing with critical issues, email maybe a necessity but the goal here is to remove distractions and allow yourself time to build momentum. How many times do you check email a day? when you first come into work? When you are in a long meeting? When you get back from lunch? Do you get pop-up notifications when a new email arrives? My guess is that many of us have developed a subconscious habit of checking email so frequently that we may not even realize that we are doing it. And what happens when you see a new email? You stop what you are doing and go read it. Same with instant messengers. This conflicts with tip #1 on staying focused on the big tasks. Instead, if you can manage it with your job, try turning off email or at least try going offline for a little while and then set specific times of the day to check email. You’ll find that removing this major distraction may help you gain some momentum.

Productivity Tip #3: Put All of Your Eggs in One Basket

By eggs I mean tasks. This is straight out of Getting Things Done by David Allen. Consolidating all of your to-dos into one place means you no longer miss anything and you can organize and prioritize things in one location. The first step is to make sure you have everything identified, then you can sort our the order to address each item.

While there are many other ideas, I’ve focused on these three as a starting point because each one allows me to avoid distractions and focus on one thing at a time rather than mutitask throughout the day.

The post Top Three Productivity Tips for the Workspace appeared first on Pete Dudchenko.

Content is Not King, It’s More Like a President

It seems that every industry article I read these days mentions the value of quality content. If you’re like me, over the last year you’ve heard the term, “Content is King” so frequently that you’re ready to pull out your hair. While I do believe this is a grossly overused statement, my objection is not solely targeted on the frequency of its use, but also with the accuracy (or lack thereof) around the statement itself.
Content is Not a King.

Google defines the word king as, “The male ruler of an independent state, esp. one who inherits the position by right of birth.” In relation to content, it’s the final detail of the definition that troubles me. Content does not inherit search engine ranking position by right of birth. It takes a number of signals to elect that content into a highly ranked SERP position. Essentially, the web population or searchers, vote the content into its respective position. We vote with our page linkage, our social sharing and page click through rate on the SERP’s. Content is not a monarchy, but an Internet democracy experiencing a continuous election for SERP presidency

This is why Social has become so critical to search engine optimization; not that we need any more reason to utilize the progressive SEO channel. Social is the ability to vote content into position. This is also why I respectfully disagree with Matt Cutts’ belief in an exclusive focus on content creation for elevating search rankings. Content is only one part of a now larger initiative as SEO Managers become Online Marketers. Consider newly published content as candidates running for office. Although the candidate may be highly qualified and capable, the people still need to know their identity and the knowledge they offer. This is why candidates, at least the successful ones, will campaign for political elections. Attaining a worthy background holds no value for candidates with minimal exposure; so instead of sitting at home waiting to be discovered, candidates use campaigning to promote themselves and their intentions. It is also why great content creation must be followed by great content promotion, which includes link building and social distribution. You are essentially campaigning your content to be viewed and consumed by as many people as possible, with the expectation that you have something unique and valuable to offer. In turn, they will vote your content into desired search positions with their linking and social sharing.

Let’s take another example, one that looks at more traditional marketing techniques around brand management. Companies like IBM and Microsoft have some of the most recognized brand names in the world. Yet they still run ads? They still promote their brands? Why? Because even with internationally recognized brands promoting still provides significant value in controlling the brands identity and communicating its importance. Content is very similar. Great content can be just like a great brand, requiring regular promotion and audience engagement to maintain business success. This is why social is so critical to SEO. You could forget about chasing SEO algorithms, dismiss the fact that they are increasing their social inputs, and still find success with this approach. That is because it’s the same approach traditional marketers have been applying for years and years.

Want to win the ranking position election? Make sure you focus on proper content promotion in addition to quality content creation.

The post Content is Not King, It’s More Like a President appeared first on Pete Dudchenko.

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.

The post Compromising Beauty In Product Design appeared first on Pete Dudchenko.