Tag Archives: product manager skills

Book Review – Stealing the Corner Office

Had been busy for a while, but have managed to read a book in the downtime. The book is titled “Stealing the Corner Office“. I have posted a brief review in the resources section. It’s a little expensive to buy in India, but the lessons it imparts about the workplace are invaluable. In case you are a corporate citizen with access to an online library, do read this book. If you are building your own collection of useful books, then you must buy this one.

Advertisements

Kaggle for Analytics Competitions – Feedback?

Kaggle is a platform for data prediction competitions. As per their wikipedia entry “This crowdsourcing approach relies on the fact that there are countless strategies that can be applied to any predictive modelling task and it is impossible to know at the outset which technique or analyst will be most effective.”

I reviewed a few competitions on Kaggle, and they seem fairly complex and perhaps a good fit for advanced statisticians or data modelers. However, Kaggle is fairly popular and gets a decent amount of traffic for niche site.

  1. Does anyone have feedback on their personal experiences using Kaggle?
  2. Have you ever recruited or solicited candidates from Kaggle, for analytics roles in offshore development centers or for offshore analytics practices of IT/Analytics firms?
  3. Have you ever used it for networking?

Drop a comment on this post if you have tried any of the three.

Evangelizing Product Management to Stakeholders – 4 Tips

In my career, I have attended a mind-boggling number of meetings where my stakeholders are absolutely clueless about the role of a product manager in India. And these stakeholders have been from engineering, sales, field marketing, program management and many other teams. So a lot of time in these meetings is then spent on explaining what a PM does and why that is useful to their team/their own goals.

[Hint: most of these guys are superbly competent in their own field, but have a very narrow view of the business, product portfolio]

 Here’s my approach towards enlightening the clueless stakeholder verbally. [Sending out introductory emails can be a blog post in itself.]

1) Identify the type of stakeholder

Without stereotyping too much, an engineering manager would have a very different personality and skill set from an account manager. So we need to identify what facet of a PM’s role he would be interested in. For e.g., if an engineering manager wants the product roadmap, he is probably looking for details on proposed features, that his team needs to prepare for. However, if an account manager wants to know about the roadmap from the PM, it is likely that he is looking for a competitive edge while positioning the product to his account. So you should focus on only that aspect of the roadmap

2) Prepare for the geographical/market context

If you are part of a new setup in India, then you may only need to mention this fact, and that you will be carrying on all existing activities and initiatives. For most stakeholders, this is enough. If you are working with remote stakeholders then be ready to do a lot of follow-up over emails and IM and meetings. I have found that those stakeholders are the hardest to influence.

3) Sell the role

If you meet a sceptic, then the best option is to offer examples and success stories about the benefit of having a product manager in their midst. The challenge here is that you might need to make space to accommodate your role, which means reducing the role of someone else. That someone else is unlikely to ever become your champion, so you need to keep a close eye on such stakeholders.

4) Sell the personality/capability

End of the day, a PM is expected to lead the virtual, cross-functional team towards successful software and hardware releases. If you have something distinct that you can share, which might help them relate to you, then you must do so. I remember a time when I was asked why I’m the right fit for the role in the first meeting. In response, I listed down multiple planned improvements for the product, and the high level PRD. This gave that team the comfort that I am capable of doing the work. Sometimes, that is all you need.

 For some people, negotiation or public speaking classes can help them increase their communication effectiveness. If these courses are available to you, do check them out.

Product Manager Maturity Model

Product Manager Maturity Model

There are several different career paths available for technology product managers, but in all of those, there are certain key skills that show how capable a person would be in any role. With job descriptions becoming more and more generic, it is up to you to understand what a role offers and what you might be able to deliver in that role. I will post more on this later.

The “One-Pager”

I first heard about this in a Microsoft team (I was working elsewhere in enterprise software at that time). The one pager was supposed to be the answer to every product teams’ planning initiative, and the composition of the one pager was given top priority by senior management as well as the product management team.

Well, when the one-pager finally arrived, it was a big letdown. It was not of one page, was really vague, and was closer to a mangled mission statement (follower’s of Dilbert will know this) than any product vision.

So what goes into a good One Pager?

A good one pager, in my opinion, should have the following 5 sections:

The Market Description

This section should give insights into the following:

  • What is the market like in terms of geography, verticals etc.?
  • What are the current solutions in the marketplace
  • Where is it heading, or what are the observed trends?

Do not spend too much time or more than a few sentences on this, as this is a very high level description of the market.

The Problem Statement

What is the exact customer problem? For online clients, it could be something like too much data, or stagnant e-commerce revenues. For enterprise customers, it could be a customer needing a “simple” and easy to use product for his IT Service Desk Management needs across all geographies.

If you know that this is common knowledge within your firm, then you can even get by with a single line problem statement, with subordinate clauses.

The Proposed Solution

This is the section that is of major interest to engineering teams and other internal stakeholders. First, clearly describe what the solution is, in a single sentence. Then use a few words to describe the different components of the solution and the benefits of each component. Finally, describe ONE usage scenario where the solution will solve the customer problem described above.

If you like, you can even fill in a few engineering details, such as the need for Open Source Web Servers, API requirements and so on. A block diagram will probably take too much space without adding value.

You can leave the remainder of the use cases to be filled out during PRD generation.

The Financial Benefit

This part causes the most heartburn in product managers who rise up from engineering ranks. They have been used to precision and results, and building financial models to predict the range of revenues and profit margins of this product over 3-5 years based on multiple assumptions can be a big challenge. My personal belief is that this stems from a lack of confidence, which can be overcome simply by practising this repeatedly.

Do not skimp on this section, and try to put as much detail around pricing, growth in customer base and quarterly revenues as possible. The lack of details around financial benefits can easily kill your vision as it moves upwards through corporate hierarchy.

The Challenges

This is an easy one. If you have an idea of the market and the customer problem then you can describe the external challenges around achieving revenue goals. And if you know how engineering will build your solution, then you can describe the internal risks.

If you have a good sense of what the competition is doing, you can write a line about it here. Although this is not recommended by most experts.

So what do you finally deliver in 5 sections, 1 page and 400-500 words?

Ideally, you deliver a “One-Pager” that is a summary of the goals of a product team, for building a new product or designing a product release. If you can actually deliver this, it will go a long way towards building confidence all around, in your capabilities as a product manager.

Web Product Management and JavaScript

If you ask any product manager at a web firm if he does coding, he will respond with a firm “NO”. Then ask him what his work consists of, and he will explain about  use cases, features, experiments and other common responsibilities. At this point, you should ask him if he knows JavaScript and/or HTML and CSS. 90% of web product managers, whether in local market roles or offshore roles, will respond with a “YES”.

Today, it is almost mandatory for web product managers to have knowledge of web software development. And this knowledge is necessary not for software development, but for meaningful conversations about architecture, design and deliverables with the software team. [It helps a lot if you can speak their language!] One of the key components of this lingo is JavaScript, which is surprisingly easy to learn and fairly difficult to master.

In my opinion, JavaScript and Java and 2 programming paradigms similar to RISC and CISC microprocessor architectures. In earlier times, CISC dominated and it required a strong mastery over the instruction set, to construct good quality programs. Later, RISC (and parallel processing in multi-core microprocessors) made life easier for not-so-skilled programmers to churn out software. However, to build really good programs for RISC chips, you still need to learn a lot of “other” constructs apart from the chip’s instruction set. These other constructs are similar to the vast amount of libraries for JavaScript, which make life easier for a master programmer, but difficult for a product manager, if he wants to master coding. Even then, this is far simpler than the hundreds of patterns, libraries and classes that you will need to work on for many years to become a master at Java programming.

More formally, JavaScript is a client-side scripting language, which can be learnt quickly, and will definitely set you apart from the “non-techie” product managers. There are several tutorials that explain the syntax (Hello World!, decisions, loops etc) of JavaScript, and after that, it is just a matter of practising these learnings. Of course, you must have a basic knowledge of software development to fully “speak Javascript”.

So how does this help you as a product manager? As I mentioned before, it is useful in 3 scenarios:

1) Prototyping

No matter which prototyping tool you learn to use, a mockup will rarely be interactive unless you add JavaScript. HTML forms, pages and dialogs will become more clear than basic wireframes when you present the concept to the engineering team. This may even allow them to improve on your efforts during development.

2) Discussions

When your engineering team starts explaining  the benefits of designing “multi-threaded JavaScript objects” running parallelly versus a simple object pool, you should be very sceptical. And knowing JavaScript basics will allow you to research on the net why this could be a bad idea from a time, complexity and engineering resource point of view.

3) Career Development

While a JavaScript certification may never be a career changer, having JavaScript in your skill set, even with an MBA, will set you apart from the other product managers. It’s easy to learn, you can practice it on any laptop and use it practically when needed.

Apart from JavaScript, it is useful to learn HTML and CSS. And recently, there has been a lot of talk about “Big Data” technologies such as Hadoop, Hive, PIG etc. More on that in a later post.

Book Review: The Strategy and Tactics of Pricing

Strategy and Tactics of PricingThe Strategy and Tactics of Pricing is actually a management textbook, typically prescribed as a required reading or a reference text in a course on pricing for undergraduates or MBA students. However, the book is very well written and is a must read for all product managers. The book has also received glowing reviews on Amazon.com.

If you wish to understand how pricing is done, or take part in pricing discussions with senior leadership, or price a new product or service, read this book.

About the Book

The book talks about the 3 core principles of strategic pricing, that strategic pricing should be value-based, proactive (where you anticipate large deals, competition response and develop models to account for those) and profit driven (focus on your targeted profit). It then shows the limitations of cost-plus pricing, customer driven pricing and pricing for market share. A Wikipedia article has a detailed description of the different pricing strategies.

The other chapters in the book cover

  • value creation and what it means to the firm and its customers
  • pricing structures
  • pricing communication with stakeholders
  • pricing policy and pricing levels
  • pricing over the product life-cycle
  • driving implementation of the pricing strategy
  • understanding costs and basic financial analysis
  • competition and pricing sensitivity analysis
  • Following the ethics and laws on pricing

Overall, a complete reading of this book 2 or 3 times should make one confident to take up a pricing task and drive a pricing strategy. This information is of great value to a product manager in any role (on-site or offshore) for all types of product sales models (subscription, licensing, freemium, cost+maintenance and others). The challenge will be to keep these learnings since pricing decisions come around very rarely, and are normally taken up by the Director/VP of product management.

For Product Managers

Product pricing is a very important dimension of product management. And it is a sensitive and critical issue in most organizations. In many cases, pricing approval is actually done by the CEO or Executive Management. In the pricing exercise, there are multiple stakeholders and everyone wants the “best price”. However, the definition of best price is different for all. Sales wants the upfront price lower than competitors, finance wants to look at the cost/price variance and the best ROI possible and marketing wants to dictate the price. So it is the product manager’s role to build a valid structure for pricing the product/service or the deal and then come up with a logical product price (which could actually be higher than the competition’s price) for different situations.

This book explains pricing very well, and you should definitely keep a copy on your desk as a reference. It is as useful for pricing SAAS products as it is for pricing consumer or enterprise packaged products.

Note: In case you have a traditional software engineering->product management career path, you may want to pick up a few courses on corporate finance and management accounting. They will help you a lot if you are ever involved in pricing decisions. A part time MBA could also be useful.