about Product Management, for Product Managers, by Product Managers

Category Archives: self improvement

Dana is a graduate of Northeastern University and ITT Technical Institute. He has approximately 30 years of experience in the field of medical devices, working for such companies as Medtronic, Genzyme, SIMS Level 1, Kirwan Surgical, and Strichman Medical. He has applied for over 30 patent applications and has been granted over 20 US patents till date.

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 beenspeaking publicly for over 40 years. He has trained and 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.

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.

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.

Matt broke 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 Paper.li 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.

Doparticipate 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.

Jeff Lash is a product management adviser, researcher and a blogger. He is the Service Director of the Product Management advisory service at SiriusDecisions, the leading global b-to-b research and advisory firm. Jeff plays vibraphone along with several other instruments. We thank Jeff for taking out time and be part of ‘Three Questions’ series for product managers.

Jeff Lash: Quite the contrary – at SiriusDecisions, we still encounter product management teams that base a lot of their decision-making on anecdotes and gut instinct rather than objective data. Innovation and evidence-based decision-making aren’t in conflict – in fact, they work well together and in many cases you need them both.

For example, it’s okay to think about innovative ideas for new products or product enhancements. However, instead of just running off and building them, product managers should look to conduct concept testing to see whether these ideas have merit and, if they do, to help iterate and improve upon them. Similarly, data can be extremely helpful in identifying opportunities to innovate. Quantitative data – from a variety of sources, including everything from market overviews to web analytics – can help identify needs, pain points and trends, and that can inspire innovative ideas that wouldn’t have been identified otherwise.

It feels as though people take a position on either end of the spectrum. On the one side, there are people who quote (or, more likely, misquote) Steve Jobs or Henry Ford and believe that customers don’t know what they want and you should just come up with innovative ideas and try and move the market. On the other side, there are people who believe every question in life can be answered through an A/B test. The reality is that there is a happy medium in the middle.

Product Mantra: What are three things that you don’t want a product manager to spend his or her time on?

Jeff Lash:

User experience design. This is a topic that is coming up more often, especially for SaaS products, as the lines between product management and user experience are sometimes unclear. Product managers certainly should care about user experience and work closely with UX practitioners. However, if they’re getting into the details of design, that’s a problem, since often they don’t have the skills or experience to do good UX work, and it means that’s taking time away from other important activities they should be doing. I wrote more about this in my blog post Product Management is Not User Experience.

Detailed specifications. It’s very easy for product managers to slip into specifying the details of how a capability can be implemented. For those product managers who were former developers or engineers especially, they often know the product or the underlying technology so well they could specify how it should be built. That’s not the job of the product manager, though. And in Agile, even though functional specifications aren’t produced as a formal deliverable, the same sort of detail is being created for each story – often in the form of detailed acceptance criteria. There are plenty of other roles that can handle the specifications – and often do a much better job – but there’s only one product manager. When product managers can provide guidance and context to those doing the detailed work, not only are they themselves not spending time on those sort of tactical elements, but the end result will also likely be much better as well.

Anything for just one customer. One fundamental difference between product management and bespoke product development is that product management is focused on creating a product that can sell to multiple customers in a market or segment. Especially in startups, situations where one customer represents a large percentage of the revenue, or even when one customer represents a large percentage of the total addressable market, product managers can get drawn in to focusing on just fulfilling requests from specific customers. Product managers should listen to customers and understand what they want and why, but rather than simply following orders, they need to evaluate whether the feature or capability or change would be valuable to the target market as a whole.

Product Mantra: What traits should one look for in a candidate while hiring for a product manager position in a b-to-b market?

Jeff Lash: I like that you specifically asked about traits rather than skills or experience. Clearly, having a certain set of experience is important, but things like competencies can be developed in an individual, while traits are harder to learn or adapt. There are a number of traits that I think are important, but here are four I’d suggest looking for:

Passion. Product managers need to be passionate about the role and the subject matter in which he or she is working. You need passion to build great products, and you need passion to inspire others to build great products. Ask candidates what gets them out of bed in the morning and try to determine their level of passion for the role and the industry/customers/product.

Empathy. Product managers need to be able to empathize with buyers and customers and users in order to fulfill their needs and empathize with colleagues to create effective and high-performing teams. Ask candidates to tell an example of when they empathized with a customer or colleague and what they learned from it.

Humility. Humility will help product managers empathize with customers and enable them to relate better to your internal colleagues. It also enforces the idea of being part of a team – arrogance is a difficult trait to make work in a collaborative environment. Ask about successes and listen to whether the candidate only talks about his or her own role or gives credit to the others who contributed.

Tenacity. There will be challenges along the way, whether it’s trying to get management to fund a new product, resolving some technical issues or taking on a major competitor. People who have a low tolerance for overcoming challenges will struggle in the role. Ask about a time when the candidate faced an obstacle that seemed insurmountable and how he or she overcame it.

About SiriusDecisionsSiriusDecisions, the leading global b-to-b research and advisory firm. SiriusDecisions empowers the world’s leading marketing, product and sales leaders to make better decisions, execute with precision and accelerate growth.

Problems are solved to make something easier for the user and financially beneficial to the organization. While it is challenging to quantify and thus measure user benefits (easy to communicate with friends), financial benefits are relatively easily measured in terms of impact on top and/or bottom line.

But before we talk of measuring output let us exclusively talk about the problem. Before you decide to put in efforts and money in solving a problem, let us be sure that the problem has undergone set of quality analysis and is proven worth addressing beyond any doubts.

Am I the right person to solve the problem? (Introspection)

So you have a problem in hand or you are given a problem to solve. The first parameter in the quality analysis metrics of a problem is that “am I the guy who solves this problem?” let us put down an example here.

The technology head who designed an in-flight entertainment system was called to solve a problem of many passengers not viewing the movies while flying. More and more passengers are shutting down the movie in less than 20 minutes. A primary survey results show that flyers did not enjoy the movie.

Airline is worried that these passengers may jump on to competition for simple reason that they do not like our entertainment system and get bored in our flight. So this problem must be addressed before it starts impacting business in serious manner.

The problem here could be related to poor collection of movies, streaming challenges, user interface of entertainment system, sound clarity, related to display quality of the screen or may be something else. Here it is important to appreciate the business challenge but at the same time if you are not the right guy you better make a case and pass it on. For example, what if the poor collection is the cause of this problem? Or even for that matter display screen which might have to be sourced from a vendor. Those being the case, get the screens replaced with better quality screens. Now if there are issues related to poor audio experience, user experience or streaming than the head of technology has a job in hand.

A passionate problem solver often gets carried away in such situations, consequences of which will cause further damage to the business. Here it is important to be wise than good. Identify the root cause, let the problem go to the right person (this is not passing on the buck). You may also end up finding more than one root cause on why passengers do not like the in-flight entertainment system. In such scenarios you may have a part of problem to solve and part may fall elsewhere.

Do we have the right set of skills? If not can we acquire them? (Feasibility)

If there is a problem that it must be solved. And we you are the one who is expected to do so than it is important that you assess the feasibility aspect as well. In above case of in-flight entertainment system, suppose the root cause identified is “poor collection of movies” and you as a product manager is expected to solve the issue. It is important to understand that the solution here is non-technical (better collection of movies). Answer simple set of questions,

What is preferred set of movies?

Who are my typical customers (professionals, family on vacation, religious people etc)

What will motivate my customers to watch a movie to its full length?

Do I need to have more language options?

And many more such questions need to be answered. Typically a Behavioral science professional may be a better person to solve this puzzle (of collection of movies). So you as a product manager may end up hiring an expert of behavioral science or outsource this puzzle to agency. This is your contribution in solving this problem. Remember every issue is not a technical issue but most issues will have a solution related to human aspect. It is recommended not to stretch your-self to unknown territories but get someone who is familiar with such situations.

Potential of the problem (scalability and profitability)

So how about measuring the impact of not solving or impact if the problem gets solved? So what if I get some games instead sourcing movies, may be getting games might be easier and cost effective alternate? And even if I source good movies considering the variety in taste is this a viable solution to implement in all the routers. Also, if it is movies the solution may say that we need to regularly update our collection. Can we think of alternates? Will my flyer pay for premium entertainment services like in-flight internet? What entertainment services are offered by my competitors?

The scalability and profitability aspect of a problem will talk about;

Competing and complimentary services

Market size and target market sizing

Pocket size of buyer and their ability and willingness to make payments that suits your pricing

Economics, solving this problem will help me enhance my top-line and / or my bottom line

To judge quality of problem it is important to assess all the four aspects (mentioned in bullet points above) of problem potential. Assess scalability and profitability critically. Challenge every aspect of possible solution, identify impact on top-line and bottom-line and never ever ignore assessing alternate approaches.

Life cycle, available window of ROI

Well all sounds good, we a have problem for which we have right skill set, is definitely scalable and profitable, but this not where it ends. How about life of the problem? To make healthy returns out of your investment it becomes important that the problem stays for a longer duration and your investment in solution fetches you returns for a longer duration.

In our case study of in-flight entertainment system, what if root cause is seasonal turbulence which might ease out in next 15 days or so. Passengers may not be enjoying movie when the flight experiences turbulence. Or it may be a season where most of the passengers are business travelers who may not want to watch a movie but instead focus on intellectual reading or discussions, could it be season where foreign tourist occupies most seats that are not so keen to watch a movie.

So the point is, if the life of a problem is short it may not be a good idea (on most occasions) to invest (time and money) on such problems. Instead figure out problems that here to stay for long and you have market for longer duration.

To add, here is one more example, a software company was struggling to upgrade their software in a particular geography due to poor connectivity in that region. Company invested heavily on engineering and research activity to solve the problem and figure out light weight upgrades that would work even in low bandwidth conditions. Company took its time solve this puzzle, however in a very short time telecom companies upgraded their infrastructure in the region and bandwidth was at par with other regions in the geography. Now here, if the software company had done some research or if they had got in touch with service providers in the region they would have learned that this problem of low bandwidth is short lived and it is not wise to put our engineering resources in solving a puzzle that would eventually be solved by someone else.

So ensure to have answer to following question

Do I have enough time to recover my investment and make profit? Problem should not get outdated or obsolete in short time.

Conclusion

A good problem is the problems that will help my business fetch more money by keeping my customers happy. A happy customer is one who believes (is convinced) that he/ she is getting what is they are paying for or are getting more than what they are paying for. A happy business owner is one who believes (is convinced) that he is selling his product or services at a better profit margins than competitors. And a good problem solver is one who makes both (customer and business owner) convince that they have a reason to be happy.

Hence it is of paramount importance for a problem solver to put the problem through a comprehensive quality analysis before jumping onto solving the problem. So when it comes to solving a problem, this is probably the only way to make both business owner and customer happy.

This one is a old story. This happened somewhere, sometime in late 1950s.

Case Study

AB Corporation is among the leading manufacturer of Umbrellas. They manufacture a range of umbrellas that protect users from rain and blazing sunlight. Competition is heating up as there are many new entrants in the industry and AB corp is facing stiff competition ahead of the monsoon season. The Product Manager of monsoon umbrella proposes new range of attractive umbrellas to increase market share and profitability. Idea is to shred away old type dull looking umbrellas and introduce colorful and stylish umbrellas that just don’t protect from rain but also becomes a style quotient in this monsoon.

So the Product Manager calls for a brainstorming session with research and development team and puts forward the proposal of launching a new range of designer umbrellas for this monsoon. He shares following specification with the team;

Key attributes of the umbrella were envisage as:

Weight: 30% lighter than the existing umbrella series.

Cloth color: 6 colors, blue, yellow, white, black, red and green.

Cloth material: 40% Transparent

Tube: silver color, non-corrosive coating

Rib: fiber

Top end: lesser than 2 inch with protected ferrule

Handle: straight (not like hockey stick) with soft leather cover

….other attributes remains as they are today.

Research team found the idea worthwhile and started working on new assignment with various ideas and one fine day invited Product Manager to have look at their new offering. On the day of first demo, Product Manager took this invention in his hand for the first time, it was lighter than what he had planned for and it was looking stunning in those bright colors. A dream come true indeed. That evening Product Manager decides to take one umbrella back home, use it for few days and even show to shppowners in nearby locality to seek their opinion.

Next day morning on his way to office, Product Manager gets first opportunity to use his new umbrella. It started drizzling and our man opened his umbrella and started walking with pride. In no time rain was at its peak and he felt like hero, but only for few minutes. Soon, water started seeping, water cracked through the cloth and starting falling on product manager. No this definitely was not kool. He ran through his way all the way till office, straight into the R&D office. Wet and upset, he started talking to team in an assertive manner, sharing his morning experience. “What a crap have you developed? this could not withstand a normal rain for more than few minutes. How do I sell this?”. The team though was puzzled, they were surprise to see our man in such a mood. “Oh well, we thought you liked the Umbrella. But this one is not a waterproof umbrella. Why did you use this in rain?”. Now that took product manager by surprise, “What do you mean, an Umbrella is supposed to be used when it rains.” The argument continued till Product Manager realized what had happened.

Research team’s understanding was that the new umbrella would be used for protection / shielding against sun light. That’s how it has been traditionally. They had never designed anything other than black umbrellas for rain. To make the matter worse, product manager in his specs never mentioned that the cloth used should be waterproof, specs just mentioned about color and transparency.

Today, at fag end of 2013 we still end up meeting such “Out of Context engineers” who would go on developing anything without learning about domain and market. While a Product Manager may try and detail as much as he can but the question is more about engineers with very low level of involvement in their work. They are brilliant and once specifications are delivered they would deliver what is asked as mentioned in the document. Now why would an engineer limit his thinking or design to what is mentioned in a document? Why do they miss on something that is so obvious and expected? The out of context engineers often end-up creating such horror stories. Escape route is always very easy: it was not covered in the specifications.

Mitigation

While the engineers would work as they work, what best a Product Manager can do to avoid unplanned bath on road is to set the expectations clearly. Be sure of what you have communicated and be sure that you do routine checks and verification with research team as they work and not at the fag end. There is always too much detailing to do but they are necessary, do not take things for granted, mention all expectations and specifications. A little extra effort may save the day for you, and of-course a pair of clothes as well.