Shadow Product Manager – salvaging out of the situation

There are scores of situations where a Product Manager might find herself/himself getting entangled completely in tactical aspects of product management because the situation demands it or there are simply too much chaos in the organ223670395_7ca0c7a061_zization due to a disorganised way of working. There are also situations when one is with an off-shore development team, “far away” from the customers and key decision makers. It is easy to get completely disoriented and frustrated at the situation. There are ways to salvage out of the “situation” of being a “Shadow Product Manager”:

  1. In-depth data analysis: They say, data is the plural of anecdotes. I have found that in chaos, people miss out in-depth data analysis; there is always some signal hidden in the pile of data for you to figure out a feature for your road map – at least a clear hypothesis. Once, I remember that analysis of support tickets over a period of time told me that users were not rebooting the machine after installing our application as most users postponed doing that. We worked to build something that required no restart and made life much simpler for the user.
  2. Collect anecdotal evidences via social media: There are always keen users of your product who are upset when something does not work and make their displeasure known through social media – but are more than happy to help if you collaborate with them. Do not react to each such signals, but pick and choose whom you want to respond to.
  3. Get into the good books of one or two sales folks: Sales personnel meet the customers all the while but lack of product makes them either succumb to pressure or to overcommit and harass the product manager. However, once you befriend them  by helping them understand the product better, you can get involved in sales calls – a lot of them are remote and get connected to the buyer (a typical case of B2B product).

Where most often I as a Product Manager have flawed is to assume that product folks who are geographically near the customer would have spoken to the customer and gathered anecdotal evidences. I have seen instances where not even a decent email was exchanged and the customer was happy when I spoke to them over phone.  There is really nothing like a ‘shadow product manager’ – there are only ‘self motivated product managers’ and ‘complaining product managers”.

Photo Credit: Hamid Saber

Juan Fernandez @ ‘The Three Questions for Product Manager’

JFJuan Fernandez has been working as a Product Manager for Liferay since 2013, after transitioning from being a software engineer. As a product Manager, his expertise includes product vision definition and development, strategy and product, portfolio management. Juan holds a B.S. in Software Engineering from the university of Seville, Spain.

We thank Juan for taking out time and be part of ‘Three Questions for Product Manager’ series. With Juan we will focus on some of the core aspects of the product management. I am sure you will enjoy reading responses from Juan.

Product Mantra: As a product manager, where would you like to spend more time, talking to customers or working on UX?

Juan Fernandez: I have zero doubts about this: talking to customers (or even better, listening to them) is one of the most critical tasks a product manager has to constantly be doing. Customer feedback, along with market research, is what helps us drive our roadmaps and steer the direction of the product, so, yes, definitely communication with customers is where I’d like to spend more time.

Regarding working on the user experience, I think that it is certainly true that as a product manager it is one of your duties to make sure the experience using your product is delightful, and a decent degree of knowledge in this area is always great, but it’s the User Experience expert, the UX designer, who needs to do the user research and analysis and finally design the optimal experience, not the product manager.

Product Mantra: How would you comment to ‘product managers are a jack of all and master of none’?

Juan Fernandez: I think we are often seen that way, but I don’t like the negative implications of that sentence. I see product management as a role that is needed to connect the dots: a person that brings market knowledge to the product team, and also brings product information to sales, marketing, analysts, customers, etc. Because of that you must be able to wear several hats, you need to be able to understand deeply technical issues, or be part of business talks…and that is why you are sometimes seen as jack of all trades: not a purely technical person, not a pure business guy, always in the middle of everything.

But in spite of this fact, I think a product manager needs to be master of one thing: you need to master the market needs. Having a deep understanding on what your customers need, what the market is demanding, and what those problems are, is the most valuable thing you can bring to the table: that is what you really need to be good at.

Product Mantra: How important is it for a product manager to have experience of project management?

Juan Fernandez: There’s often confusion about these two positions, product and project management, but at the same time they are extremely different.

In my opinion, the key for differentiating both roles is this: the product manager helps define what problems need to be solved while the project manager helps by coordinating the product team in the execution of a solution for those problems. The former is a strategic role, and the latter is a tactical one.

Having clarified this, I’ve seen product managers transitioning from sales, engineering and also from project management positions, and each of them, each of us, have different challenges when adapting to the new position. The challenge for a product manager with a project management background is to leave the control of all the execution details behind and focus on the vision and strategy of the product.

Thanks Juan.

Juan Fernandez on Social Media

  1. Follow Juan on twitter at: @juanferrub
  2. Get connected with her on Linkedin:-ández-rubio/24/bb3/583
  3. Read his blogs:


Mike Lehr @ ‘The Three Questions’

Since 2003, as President and Founder of Omega Z Advisors, LLC, Mike Lehr has worked as a change management specialist prepping and moving people through change. He accomplished this either as a contractor or as an organizer and leader of project teams. Mike has been
speaking publicly for over 40 years. He has trained Mike Lehrand coached for over 25 years.

Since 2007, Mike has had an intense focus on helping firms implement new IT infrastructures and applications as well as developing IT talent. Mike spends much time raising IT to the human level.

Mike has blogged since 2010, writing over 500 original posts of over 150,000 words. It is an extensive reference tool. Mike is also the author of The Feminine Influence in Business a comprehensive book about integrating more intuitive approaches with classical ones to develop talent, influence and solve problems. < Read more about Mike Lehr >

We thank Mike for taking out time and be part of ‘Three Questions’ series. With Mike we will focus on  managing self and how do we become better professional. I am sure you will enjoy reading Mike.

Product Mantra: Mike you have been in the business for over 20 years now, what makes
you believe that ‘influencing’ and ‘problem solving’ are key to achieve change as desired.

Mike Lehr: Very simply Abhay, we cannot do anything without being able to influence or solve problems. Influencing comes into play from leadership to IT introductions. Problem solving comes into play from talent assessment to product roll-outs. Change is no different.

How do we achieve change? That is a problem. It needs a solution. That requires problem solving skills.

Yes, we might know the solution immediately. It might not seem like a problem. Yet, it is. The problem could be that we are just going through the motions. We are thinking inside the box. Experience is a side of that box. That’s why laypersons often have innovative ideas outside of their experience. The man who solved the measuring of longitude was a watch maker, not an astronomer as were all the other experts of that time.

How do we bring about change? We need to influence people. We need to influence ourselves. Both require motivation. Even if others are solving the problem for you, you must motivate them even if it’s simply by paying them. That’s influence. Money is influence.

I challenge anyone to find a way to achieve change without influencing and problem solving.

Product Mantra: Investing in self is really important, what would be your advice to mid-level executives in this regard. What kind of learning, certification or training will help them prepare better for later part of their career?

Mike Lehr: Abhay, I have run training that people have found very valuable even though they learned nothing new. That is because I presented the same material in a way that motivated them to use it.

I often claim that people could be successful without learning one new thing if, and this is a big if, they would just apply 10% of what they learned but had never implemented.

Trainers make big bucks teaching people the same things that they learned but never implemented. Some people collect knowledge like they do tools, kitchen utensils or exercise equipment. It’s simple. Use what you already know. That’s the lesson.

Beyond that learn to be confident. Learn to believe in what you do know and can do. Confidence influences people even when nothing else might be there. Confidence is a tool. It is not a state of being.

People like confident people. Studies show this is true even if people do not know where that person is going. Confidence triggers the emotional need for security in all of us.

Product Mantra: Tell us something about your work on integrating more intuitive approaches with classical ones to develop talent, influence and solve problems.

Mike Lehr: In general, Abhay, integrating more intuitive approaches is about tapping people’s emotions to influence and solve problems. It is about changing how they see things, not changing the things they see.

For example, consider customer service. The classic approach sees the problem objectively. That means to improve customer service we teach ways to improve service. The focus is on service. We change the thing. That thing is service.

Now, I trained people to improve customer service without teaching them one thing to improve that service. Initially, when I say that I stump many people. That is because we do not consider people’s emotions, thoughts or behaviors regarding that service. The focus is on things (service) not people.

Even if we provide good service, there is no guarantee that people will notice it. My training focused on showing people how to ensure that customers noticed it. I didn’t have them change the service. I just taught them ways to change how customers saw the service.

For instance, studies show that when customers see a busy staff their assessment of service goes up even though none of that activity is about them. Conversely, when they see staff hanging around talking to one another, their assessment of service goes down even if nothing changed about the service they received.

In some ways, this is very similar to the way a branding, marketing or advertising campaigns change people’s impressions of products and services. The difference is that we apply these principles on an interpersonal level.

This can save tons of money. We don’t have to change things. We just change how people see things. In problem solving, this means we don’t solve the problem. We just change how we think, feel and react to it. That might mean we find that the problem isn’t really a problem.

When we integrate the two, we change things and change how people see things. This is even more powerful than either approach alone.

Thanks Mike.

Mike Lehr on web:

  1. Follow Mike on twitter @ MikeLehrOZA
  2. Connect with Mike on Linkedin 
  3. Omega Z Advisors
  4. Mike Lehr’s blog


Risk Management in an Agile world

With the craze of many companies and organizations, big and small to jump onto the Agile bandwagon, a few areas of traditional Software development get ignored or trivialized. More often than not, these come back to bite us late in the cycle. In true Agile fashion, teams then scramble to do the best they can to get the product over the line.

One such area of Software Development that sometimes gets overlooked is Risk Management. Traditional Risk management had projects following either the qualitative or the quantitative approach to Risk management. Detailed risk mitigation would be then put in place to ensure that the Risk was well handled. Many times, this placed a considerable overhead on the team.

Agile teams following the Scrum or XP model inherently embed Risk Management. Risks would typically be identified when the team throws up impediments in the daily standup OR fails to meet its Sprint commitment (because of a story being more complicated or having a dependency that failed to fall in place). Whatever the reason may be, Agile teams are pretty good in throwing up Impediments quite early. These impediments could turn into significant risks, more so when they involve external stakeholders and other teams.

In view of keeping the processes light weight, Agile methodologies are not prescriptive about how the risks can be made visible or managed. From a management perspective, the PMO or Senior Management might see this as a flaw in the Agile methodology since they do not get enough visibility about the risks and hence unable to step in at the right time to clear the path.

In such a scenario, here are some tips that would help.

  • If using an electronic tool like Jira or Rally, raise a work item of type ‘Risk’, provide a severity rating to it and put a Blocked status onto it. Assign them to the right stakeholder and publish a weekly list of these risks to the management. Note: Make sure that the key stakeholders have access and are watchers to these risks.
  • If using a physical board, create a 3 x 3 Risk matrix (Probability(L,M,H) vs Impact(L,M,H)) on the physical board, put up the risk and assign the stakeholder’s avatar to it. Take a snapshot on a weekly basis and send it out to the management stakeholders.
  • Report your blocker in the Scrum of Scrums meeting, explain the potential consequences and nudge the management to take action (mitigate, avoid or accept).

In short, the key to an effective Risk management in an Agile world is to make it highly visible, accountable, time bound and easy to action upon.

Are there other light weight and effective Risk management practices that your Agile team follows ??
Do let us know..

Alicia Dixon @ ‘The Three Questions for Product Manager’

Alicia Dixon

twitter at @Li_Li_D

Alicia Dixon is a Product Manager with a specialization in mobile software. Her expertise includes product development, product strategy, and market research. Throughout Miss Dixon’s career she has successfully produced enterprise and consumers products through positions held at leading companies including Hilton Worldwide, UPS, Dell, Blackboard, Fruit of the Loom, Nike & Toys R Us. She holds a Bachelor’s degree from Howard University along with an MBA from Baruch College, CUNY and an MS in Marketing from the University of Alabama. She is an active member of technology  community and sits on the planning committee for ProductCamp DC.

We thank Alicia for taking out time and be part of ‘Three Questions’ series for product managers.

Product Mantra: What is the biggest challenge facing the discipline of Product Management?

Alicia Dixon: In the push for designers to learn to code, and developers to learn design, and everybody doing product, I feel that one of the biggest challenges for product management is staying relevant.  Lately there seems to be a trend that everybody feels that they can do product successfully.  My personal point of view is that this is because people assume that doing product is easy.  I attribute this to the fact that the core skills and talent needed to do product are so esoteric.

You learn product by doing it and you can’t really get it from a book or class.  And there’s no one-method-fits-all approach to building successful product.  Thus, there’s an assumption that since the skill set is so undefined that it’s an easy one to master.  Those of us doing the job know this couldn’t be further from the truth.  We know that creating product is an art form.  And like all good art, you know when it is good or bad, but you might not be able to define WHY it is good or bad.

Unfortunately, there is a growing trend to push product away from working with potential customers to formulate business strategy and into areas that should be handled by other disciplines.  In an effort to clearly define the product role, hard requirements for the job (such as being ScrumMasters, Design Thinking facilitators, and multivariate testing experts) have become commonplace.  These attempts to make the parameters of the role more concrete have actually had an adverse effect; making product roles irrelevant because there are already groups that do project management, design, and analytics.  As those groups claim the job functions that are rightfully theirs and there are no other defined components to the product role, I believe that the result is those disciplines start to question why product is needed.

Of course, product is needed!  Why, you ask?  My answer is to give direction as to what comes next.  Product is out canvassing the streets to uncover the customers’ problems and bring those back to the organization to say ‘here’s an unsolved problem that we have an opportunity to fix’. Understanding the challenges that target users are facing and why of those challenges have significance is the cornerstone of the product management function.  Achieving this requires listening and empathy — two soft skills that don’t translate well into a job description or RACI matrix.  All of this means that the onus is on Product Managers to prove their worth.  Doing that is really hard when we are off doing tasks that we shouldn’t be doing in the first place.

Product Mantra: How best can a product management professional leverage upon the growing virtual community of product professional for his/ her personal development. Would you share some insights on this with our readers?

Alicia Dixon: Social media and online networking have made it so that Product Managers now have a thriving virtual community.  Through my own experience I can say that everyone I have met virtually who works on product has been very welcoming and friendly.  While it is tempting to seek out a relationship with the most popularly recognized product folks, I encourage you to connect with people who work on similar products or within your local area.

My advice for anyone wanting to acclimate oneself with this community is to start by consuming the popular blogs and following thought leaders on LinkedIn and Twitter.  Then start commenting on any post or article that you find compelling.  Share these within your network as well.  As you get more comfortable, create your own posts based on your specific experiences. Finally, don’t stop with the virtual community.  Make connections that you take into the real world.  Meet other product people for coffee, take them for drinks, and attend local meetups or ProductCamps.

Getting involved in this way will not only expand and improve your product knowledge it might just lead to your next opportunity. For example, a good online friend of mine is now slotted to be the keynote speaker at an international conference based on a referral I made. I spoke at the event last year and recommended her to the organizers. I knew that they were recruiting speakers for this year and that she would be great at it, so I was happy to connect them. Most of the product people that I know are eager to help foster the community in this way.

Product Mantra: Which is your most memorable experience from a startup and what do we learn from it?

Alicia Dixon: A key learning that I took away from working in a startup environment was that what is appealing at any given moment can quickly change.  My startup experience was actually at an internal startup at a 90 year-old company.  When I first joined the business, the product that I was working on was deemed the next generation evolution for the company.  It was to be the new and significant revenue stream for the business.  All of the executives were very excited about the new growth opportunity and trade publications spoke highly of the upcoming industry change.  At that time, the product was the core focus. So it was heavily funded.

However, the industry had a hard time moving forward with the adoption of a disruptive technology.  The need to continuously make iterative product improvements was a new paradigm which was not embraced by the company nor clients.  The one-and-done mentality (i.e. build it once, then sell until sold out) was so ingrained in the business that they just couldn’t get past it.  Over time, funding was gradually pulled from the initiative.

So the takeaway from a product sense is that one must continuously scan the marketplace to be aware of the receptiveness to what you are creating.  When you notice it begin to wane, it is time to move on, either to another product within your current role, or to a new position entirely.

Thanks Alicia.

Alicia Dixon on Social Media

  1. Follow Alicia on twitter at @Li_Li_D
  2. Get connected with her on Linkedin @
  3. Read her blog


Steven Haines @ ‘The Three Questions for Product Manager’

Steven HainesSteven Haines has a passion for great products! This passion is evident in the three books he’s written. His energy serves as a catalyst for senior leaders so that they can adopt needed changes that improve organizational effectiveness and ultimately, contribute to the creation of the best products that deliver extraordinary value to customers, and undisputed competitive advantage.

We thank Steven for taking out time and be part of ‘Three Questions’ series for product managers.

Product Mantra: How important is it for a product manager to have experience of project management?

Steven Haines: I have a good-news, bad-news response. The good news is that there’s recognition of a difference between the two. I can’t say how many times people confuse the two practices. The bad news is that, yes, product managers must know how to manage projects and the three main pillars: people, budgets, and schedules! To be precise, all business people should know how work gets done, by whom, and when. They must know who provides work product to others and who receives work product. Also, they must know how those hand-off’s impact the overall schedule of deliverables in order to produce a planned outcome. One of the most important projects that product managers are likely to find themselves in the heart of is a product launch. It’s an incredibly important process; it involves many people, and must result in an on-time launch. If people don’t do what’s required in the launch project plan, then the product will not achieve its objectives for sales, market share, or a positive customer experience.

Product Mantra: How often should a product manager conduct competitive analysis, what’s the frequency and any methods that you can share with us?

Steven Haines: Competitive profiling is a vital practice that should be carried out on an ongoing basis – not as a periodic exercise. For example, I get “alerts” every day on various companies to find out what they’re up to and I store them in my mind, or share information with my team members. I also motivate my cross-functional team members to be alert to goings-on in the market. If a sales person visits a customer and learns about a competitor proposal, that sales person should provide input to the product manager. Another method is for the development or engineering team to be able to reverse engineer competitor products if at all possible. This can provide valuable information on costs, composition, and the user experience. In many firms, a market intelligence department carries out research that can reveal useful insights. All these inputs should be stored on a shared repository so that, across the organization, people can be alerted to any competitive activities. These can be channeled into the strategic planning process, or in other dimensions of the product’s business.

Product Mantra: Tell us more about the philosophy of product manager as business manager?

Steven Haines: It’s not so much a philosophy, but the standard. A product is a business inside a business and a business must be managed. Every business starts with a vision, goals, and a strategy. That strategy is based on various inputs: market insights, business, and financial information. Strategic goals set the stage for what’s to be done – to create a new product, update an existing product, or even expand to another market. Once everyone in the organization is aligned, the product manager, like any good CEO or general manager ensures that everyone does their part to build, test, validate, and launch the product. Finally, performance metrics are monitored to steer the product’s business, keep things running, and to re-strategize as needed.

Thanks Steven.

Steven Haines on web:

  1. Steven Haines blog:
  2. Twitter: @Steven_Haines
  3. Linkedin:


Matt Anderson @ ‘The Three Questions for Product Manager’

Matt Matt Andersonbroke into product management as a SME in library software, but has branched out into broader software categories. As a product manager, Matt has recent experience with B2B and B2G products, browser-based and mobile applications, and US and Canadian workforce regulations at several small companies in Salt Lake City. While working from Utah, Matt has worked extensively with offshore teams in India and Eastern Europe. Matt’s product management influences include Alicia Dixon, Rich Mironov, Roger Cauvin, Nils Davis, and the PM Dude. In his spare time, Matt tweets about product management best practices and broad technological trends.

We thank Matt for taking out time and be part of ‘Three Questions’ series for product managers.

Product Mantra: How do you see the role of product manager evolving in the world of Mobile Apps?

Matt Anderson: Mobile applications are often a new-ish product offering for companies that have established core products. In this sort of scenario, the mobile applications are often the most exciting area of development for the organization, while the core products are constantly focusing on the same things over the long-term: performance improvements, features, bug fixes, etc. Mobile products often have a shorter development cycle, a shorter testing process, and a smaller training and documentation effort. For someone who has been working as a product manager or engineer for non-mobile applications, it’s often a relief to move onto a mobile app project.

The learning curve, however, can be steep when you begin to work on mobile applications. Product managers working with mobile should look at and use applications regularly. They should look at mobile design patterns across the software industry. I’ve found it beneficial to carry multiple devices, with multiple brands, sizes, carriers, operating systems, etc. I’ve carried devices that were cheap or old when I thought the users may not use the latest and greatest. A product manager will have trouble balancing all of these conflicting concerns, so I’ve found it is good to rely on short release cycles, consistent beta releases, and constant feedback loops with users to release successful mobile products.

If I were to hire a product manager to work on a mobile application, I would look for a high-performer who was actively trying to understand (1) industry standards of UX design, (2) best practices for customer interviews, and (3) best practices for Agile. I’ve found that a solid background in product management and UX is a primary qualification for a mobile product management role, while experience in the mobile application space is a secondary qualification.

Product Mantra: How often do you conduct competitive analysis, and are there any methods that you can share with us?

Matt Anderson: I crawl the web daily for competitive insight in my industry by using and Talkwalker Alerts. I think that establishing a constant flow of competitive data by using these tools is a great way to keep a constant dialog with your product management, marketing, and development teams. If I hear that my competitor’s Mobile App X is integrating with an API Y, I want to share that info with my team right away. That’s a daily competitive analysis, which may not be for everyone, but daily crawling is definitely my style. And if you use this strategy, don’t forget to pay attention also to your competitors’ major customers, because they drive your competitors’ strategy.

While I gather far more competitive insight from the web than from other means, the most valuable data is not always available on the web. I received one of the best pieces of competitive data in my career by attending an industry event and hearing that a government agency had worked with my competitors A, B, and C to draft legislation for my industry. Not all information is published to websites, Twitter, and LinkedIn. You need to be where your industry influences are, be where your customer base is, and be where your partners are. Visit your customers regularly, attend industry events, and you’ll work your way to the center of your industry.

I always find that the data that you gather from the competition over time needs to work its way into a higher-level analysis that compares your product offering with the competition. It could be a spreadsheet that shows feature quality for you and four competitors, or a spreadsheet with predictions of what each competitor’s feature offering will be in 2 years, or a pricing analysis in a spreadsheet that recommends dropping your price by 10% to improve your win-loss ratio. Take your competitive analysis and make it consumable by your executive team.

Product Mantra: What would be your suggestion for 3 Do’s and 3 Don’ts for Product Managers?

Matt Anderson:

Don’t just tell people what they want to hear; tell them what is going to happen. Don’t just say “yes” or “that’s a great idea” if you aren’t going to do it now. Tell them the real plan, and you’ll promote openness and trust.

Do work for your organization; not your department. As much as you can, be the best value to your organization. That means breaking down unnecessary interdepartmental silos and establishing a cooperative environment.

Don’t be the primary tester for your product. Sure, there are reasons why it can be a good thing. First and foremost, it is a great way for a product manager to understand the product and how it is used. However, a few of the consequences that arise from having product managers as the primary testers are impacts on the development process, conflicts of interest, and impacts on the performance of the product manager.

Do put your executive hat on. It’s not only the dev team and the user that matters…make sure that your product strategy is in line with your executive team’s expectations. Do it on a monthly basis, if possible.

Don’t gather the stakeholders and let them duke it out over what the priorities for the product are. You are being paid to make decisions about the product, not facilitate others to do so.

Do participate in the #prodmgmt community. I’ve learned so much from my colleagues in the product management community. I’ve met dozens of product management folks through my use of Twitter who have made my career and my life more fulfilling.

Thanks Matt.

Matt Anderson on web:

  1. Matt Anderson blog
  2. Twitter
  3. Linkedin