Michelle is a Senior product management and product marketing leader with a proven record of accomplishments in leading and implementing product management programs in diverse organizations to create, develop and position successful award winning products. Continue reading
Steven 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.
Steven Haines on web:
- Steven Haines blog: http://sequentlearning.com/experts/author/sjhaines
- Twitter: @Steven_Haines
- Linkedin: https://www.linkedin.com/in/stevenjhaines
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.
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.
In my previous post, “Case Study: The Waterproof Umbrella” I wrote about “Out of Context engineers”. Engineers who are working on product or on feature but are not sure about its usage or need. While the earlier post was focused more on challenges, this time it is more about what a product manager should do to help engineers gain contextual knowledge.
There are ways by which you as a product owner can make the out-of-context engineers have a better understanding about product.
Detail requirements along with context : Charity begins at home, so why not start with little extra effort to help engineers understand something more about the product needs. When you write requirement definition or user stories, do ensure to include sections like “feature purpose”, “problem definition”, “Expectation (from feature on implementation)”. A typical ‘User Story’ with ‘uses cases’ is not good enough for many engineers to understand the context or need, it rather just focuses on solution space and has bare minimal focus on problem definition or customer voice. Including suggested section along with accurate data helps engineers to connect problem definition with use cases and in-turn helps in designing an effective and elegant solution.
Customer experience : It is highly recommended that engineers who mostly have cubicle working habits should be taken out to meet customers, partners and field staff. When you go out to meet customers for a presentation or for a follow-up meeting, take one of these champs along with you. Let them have customer exposure, understand the expectation from horse’s mouth and feel the context. What is being suggested here is not something new but is definitely something which is not practiced so popularly; successful product companies like Intuit does practice this which is termed as “Follow Me Home”. You will also find a reference of this in “Lean Start-up” by Eric Ries. What this does is that it brings in a lot of contextual information to engineers, helps them understand that the customer focus is more on solving a problem and not necessary developing a feature as mostly perceived by engineers.
On many occasions, there are business or legal constraints due to which it is not possible to take an engineer along with you. For such scenarios, ensure that you share experience from customer meeting with the team and help team come to same level of understanding as you are.
Market updates : Send out updates in form of write-ups, ppts or even as a small talk once in a while to engineering team on what’s happening in market place, what is competition doing, newer announcements by government or by compliance agencies which could probably impact a feature or aspect of your product design. You chose the frequency, but ensure do not over-do or be so rare that engineers lose interest in such updates. This is an attempt to keep engineers connected with market place and also help them understand the business aspects of the product. They will sooner or later appreciate such information and also its implication on feature design or product road-map.
It is always advisable to have someone in the team who can challenge your understanding, only to help develop a better product and a better professional out of you. I take this as part of product manager’s responsibility to keep his team connected with the market and in turn with customer. Spend some extra time to detail out things that you might not have been doing, spend some time educating your team to ramp-up their understanding about business and problem you are trying to solve.
One of the many key roles of a Product Manager is that of a ‘Sales enabler’. This means, helping sales to improvise on conversion ratio, conversion of a prospect to a paying customer. While there is nothing much that a product manager can teach sales about sales, however they can play a crucial role in influencing customer and by helping them in build trust and confidence in product sold to them.
Think of a product manager as a walking & talking “Sales-Solution-Guide”, may be something like a breathing wikipedia of the product. Sales should be able to take them to all potential large customers or even to an existing key customer. Here product managers takes on greater responsibility of market success and such a shift typically happens largely in introduction and growth phase of the product wherein quick conversion is imperative to the success of the organization.
Here are few value adds that a product owner should focus on while working with sales or running a product demo with customer; remember it is product managers responsibility to be valued and not to be seen as liability:
- Know your product, functions and technicalities. Have a very good command of your product features and intricacies of user experience. It would not leave a good impression on customer if you repeat this too often ‘I shall get back to you on this’.
- Highlight customer benefits against each feature demonstrated, ensure you speak more of customer interest, few examples: how a particular feature impacts staff productivity or data security. May be even on reliability of data.
- Aspects that can be translated to monetary benefit like increase in top line or bottom line should be explained thoroughly. Question audience if they have any doubts over monitory benefits of the product. Typical example: lower cost of ownership for customer (in terms of hardware requirements and maintenance).
- Study competition well, as much as you can. Be prepared (or be honest) to answer questions on competition strengths and values that you are still trying to match.
- Customers often ask for more, more than what is offered or even required. Know well what level of customization is doable and in what time duration. It gives immense pleasure to customer when they convince a vendor for customization so please do not rob them off this pleasure, be prepared for taking some extra work for engineering.
- One of the most common question that I have faced is “how frequently do you upgrade your product and at what cost would we get it”. While on most occasions you will be able to pass on the question related to cost but ‘frequency of software upgrade’ is domain of product manager. You are expected to answer this but be sure that you neither exaggerate nor should you play too safe by being conservative.
- Towards the end, buy some time from customer to present technology road-map. Show customer the benefits of going with you, show them what they will miss if they go for alternate product or solution. This matters a lot to the customer and they expect you to present this to them.
I have always enjoyed the responsibility of ‘sales enabler’. I see this as an opportunity to meet and talk to customers whom I represent day-in and day-out in my organization. Perhaps I must say that, it is these opportunities that keeps me up-to-date with customer priorities and market demand, in-turn makes me more effective in my role as a product manager.
I often come across my Product Manager friends fretting about “over engineering” by their product development team. “Over engineering” leads to more time and money – which is a source of worry for the Product Manager. Does a Product Manager know if a feature is “over engineered” by engineering? Perhaps, Yes. Is the extent of engineering required for a product, a Product Manager’s prerogative? Perhaps, No. We love to state and perhaps over-state that Product Manager is also the complete owner of the product . Product Manager is of course the custodian of the business aspect of the product and has the say in what feature must go and the timeline of the feature. However, it is the engineering team consisting of software architects and developers who develop the product. Let us look at various scenarios based on two parameters: the scope of the product development and effort estimate. Continue reading
As we all know, Product Managers are responsible for maintaining the Backlog such that it reflects the demands of the market. As market dynamics change, the backlog changes too. The Agile way of constantly prioritizing the backlog and keeping the most relevant features or stories at the top are key to ensuring that the product stays competitive in today’s dynamic market.
Many times, the Product Manager and the Product Development team go into Sprint Planning without enough clarity on some features or user stories. This causes the planning meeting to go in circles Continue reading