Buzzwords in your Product Feature Set

 

[Re-post, still relevant from 5 years ago]

In technology product management, it is easy to get tempted by the fashionable trends of the season. For web properties, it is features related to AI, Machine Learning and "Big Data", earlier it was "Web 2.0 Features or SLATES".

When such buzzwords become commonplace, the products promoted using this terminology, during sales pitches or marketing events also gain credibility in the eyes of the layman. However, the product manager should not be swayed by these fashionable feature sets. It is always the buyer, the influencers and their product reviews that are the key to gaining market share and increasing revenue.

Fundamentally, nothing has really changed. As a product manager, your vision and roadmap will contain features that are useful to woo customers to try, buy and keep using your products. And these features are either going to give you a competitive edge, retain existing customers, or attract users who are not yet using the products.

If these reasons attracted you to these fashionable features(and of course, the side benefits of tempting developers to build them out and of influencing senior management on thought leadership), then consider this blog post, that talks about the diffusion of innovation, and product adoption. I will leave you to understand the implications, but the key takeaways from this include:

a) Adoption rates of most consumer technologies in this century follow a similar curve

b) There is a real adoption chasm that exists in most product categories, beware that your product does not fall in that chasm

b) Innovative features take time to identify, design and develop

So how can you cater to the fashion sense of the day, and still follow the established strategic principles? That requires building consensus, and having a market research driven approach to identifying the best features for the various consumer or user segments.

In fact, gaining consensus on the product roadmap is a vital activity, and it takes a lot of time.

Are Personas Obsolete in the App or Web world?

As people learn advanced product management, they try to solve more complex product problems. Now a common problem that is cropping up in the SaaS or app world is the identification or creation of personas. But given the massive amount of usage data, and the quality of real time analytics and artificial intelligence today, are they really necessary?

Persona

Personas are a commonly used tool by product managers and product designers, to denote a fictional user of a software or a set of features. Rather than making assumptions about feature usage, you identify a set of users with similar needs, who will use the software in a particular way. Based on this set, you create a fictional persona, which is then used to validate any new feature idea.

If you attend any product presentation or work with UX designers they will identify personas for their work.

Source: https://www.christinanghiem.com/images/persona-01.jpg

There are many videos on YouTube, such as this one, that also talk about personas, how to create them, the value they add and so on.

Personas: Good or Bad

So there are both sides to the story.

On one hand, there is a detailed blog post on the Adobe blog. It talks about how they use personas for design and why they are important. Given the prominence of Adobe in the design world, this is a strong perspective.

On the other hand, this post on UX Collective, talks in detail about why personas have limitations, and where they stop adding value (Why is the 'college' of a persona important? What happens to users who attended thousands of other colleges?).

And the Neilsen Norman group (world famous in UX domain) also has an article titled "Why Personas Fail" that talks about the challenges in using personas. As you gain more experience in using personas, you will definitely encounter such challenges.

The Bottom Line

There are both pros and cons to using personas. However, the tools to track usage and user engagement have improved to such an extent, that you can see in real time what an actual human using is doing, filtering out data about bots and other automated tools. This is particularly true for B2C tools for apps and websites. And if you have the resources, you can invest in an analytics team that can offer detailed insights into every significant interaction or engagement of any user. In fact, for a product manager, I would recommend that they get certified on Google Analytics, rather than on any UX tool used to create personas.

As a product manager, you can still use personas to suggest new features and engagement (use cases), however the validation of features already released is better understood by using data and tools, rather than referring back to the standard personas.

Calculating TAM (Total Addressable Market) for a SaaS firm

If your firm or start-up does not have a full time strategy team, then the founders will use different resources to calculate the potential market size for their firm. Here are some key methods to calculate the TAM, and create a product launch and marketing strategy.

1. Use Data from Research Reports

   Many research firms put out their estimates about the TAM for different products and services. For example, there is a category of products called Next Generation Firewall (NGFW)
   Research reports such as this and this, indicate that the NGFW market size is about $7.4 billion in 2017, growing to $12.5 billion by 2022. 
   
   
   Using such numbers, from a creditable source, can give a good estimate of the market size, as well as the sub-segments within the market. Adding to this data, you can make some projections on your own, to identify which verticals, geographies and customer profiles will be a good fit for your products and solutions. Add to this the range of growth rates expected, and you can have a very good range of TAM, for planning and budgeting.

2. Create a "Bottom up" Estimate

   This is a more accurate method, however, it takes more effort, and requires expert level skills to make good projects. In this method, you first identify the total number target firms per vertical, geography and revenue/employee size. This data is available from public sources and databases. For example, if you want to target only firms with a firewall spend of over USD $1 million, then you are probably looking at an annual IT budget in the range of  $15-50 million. Which indicates that the firm size is over $1.5 billion (estimating IT investment budget range from 1%-3%). 
   
   
   The next step is to select 10-20 priority verticals (healthcare, government, retail, manufacturing, mining etc.) where you see a good fit for your product over the next 2-3 years. In these verticals, you then identify the firms with a size above the cut-off. Let's say that you come up with a list of 250 firms. Making projections of their IT spend, you can estimate the size of your addressable market for the first 2 years. The key advantage of this estimation method is that it incorporates your corporate constraints and is customized to your current capabilities.
   
   
   There is another way to estimate TAM, which is based on the current ticket size per sale of competitors and come up with an estimate for your firm. Ticket size multiplied by potential buyers can be another estimate of the theoretical TAM. Unless you are a marketing guru, this is not recommended.

   Bottom Line

   Estimation is a necessary activity, when you want to make a business case for new investment. Using either of these methods, any product manager can project the TAM for his products and services. And as always, you must document your assumptions behind these estimates.

Product Manager or Product Owner

For people looking to move into product management, the product owner role is often a stepping stone. In fact, many advisors do consider the product owner role as a subset of the product manager's role. That is a misguided view of the roles, especially given how the software industry is transforming. To be clear, both are different roles which require different skills and have different objectives, stakeholders and success metrics.

To summarize, the Product Owner works in an agile team, with a specific set of tasks and objectives.

The Product Manager is a business role, that has a wide range of responsibilities and objectives, depending on the 

• Organization (centralized vs. product driven pricing, planning and budgeting)
• Industry (B2B, B2C, e-commerce, networking etc.)
• Software development processes (agile, waterfall, hybrid)
• Seniority in the organization
• and whether there are also product owners or an architect team in the organization

 Both roles have some overlap as well, however that is often because the company is undergoing a transformation and the roles have shared responsibilities.

Below is a slide that shows the possible growth path in this role.

I have uploaded a brief presentation on SlideShare that talks about the product manager and product owner roles. This will be useful for people looking to explore either role as a career opportunity. 

As the scope of the presentation is very large, it has been split into two parts. The first part is currently available on Slideshare. Feel free to view that and direct any questions at me.

Product Management Skills Benchmark Report

The 280 Group is a Silicon Valley based training, research and consulting organization focusing on product management training and consulting for a long time.Their training and consulting staff are available for online, virtual or in-person training sessions. Best of all, their product management framework and process can be adapted by any organization, using Agile, Waterfall or a Hybrid methodology.

In late 2018, they did a survey of practicing product managers across the globe. The objective was to understand the definition of the role in different regions and industries, the key skills and responsibilities of the PM, and the skill gaps that product managers mentioned in the survey. For this survey, they identified 15 key skills (skill set) that a PM will use over the course of their career. They also include a skills assessment survey, which you can use to benchmark yourself against other respondents.

With more than 1,500 responses, there are a ton of insights from their Skills Benchmark Report. If you want a greater understanding of this role, or want to benchmark yourself against other product managers then you can download this report for free.

Few Points

• Customer and domain knowledge was the strongest skill among PMs
• Competitive Analysis, End of Life & Pricing were among the weakest

If you want to move into product management, or want to grow further, then this is a great resource to understand what is actually needed in the role. I hope you get as much value from this report as I did.

5 Reasons Why Scrum Teams May Not Deliver the Backlog

[This is a post from 6 years ago, but I came across this situation recently with a client, hence re-posting it here]

As a Product Manager, you should be used to hearing "NO" from every stakeholder, including the engineering teams. And then comes the hard part of persuading people to listen to you, even when they do not report to you. Of course, if you are talking to a vendor, or an IT services firm, you occasionally face the other challenge, of hearing a "YES", for every product initiative. With engineering teams, sometimes there is a hidden reason behind their "no" for a product/feature concept. Here are 5 reasons why PMs I know were not able to push through product requirements.

It's not cool enough

In the web world, certain technologies and features are considered cool. Others are not. So if you have a strong engineering team, they may simply nix the basic features such as logging, event viewer etc. in favor of features such as cross-domain APIs, "social" features etc. The trick is to keep a judicious balance in every feature review. And in case that's not possible, just promise them that the "cool" features are coming down the road. And be careful about the ever-present "code conversion" projects where they want to migrate the code from JavaScript to TypeScript or to use node.js and introduce SVG viewer and other features. Unless there is a business need or a strong performance reason, the "coolness factor" could be lurking about.

It's too tough

This is what I heard from an intern who joined the engineering team. They had worked on a matrix based hierarchical organization of real-time data for a year, and then they gave the same project to the intern to take analyze. Additionally, this was always the project that got de-prioritized over other initiatives. By sitting with the intern for an hour, it was easy to understand that this was an NP-complete problem, and optimizations were simply too tough for our data dictionary. (Here is a description of NP-complete).

It's too easy

I have been in teams that often said "no" to easy fixes. After developing the core feature, however badly, nobody wants to simply fix all the bugs or add the security requirements. Again, one workaround is to offer a bundle of features to the product team, where they cannot pick and choose specific features. 

In normal circumstances, these are the features that will slip the most in an early release, as they are deemed "non-core" features. For instance, the web-based admin GUI for a SaaS app often falls in this category.

We don't have expertise in that

No true engineering team will admit this, but this is also another hidden reason why teams say "no". In one instance, the team had no idea of the internals of Oracle's 11g release, so they simply delayed releasing a plug-in based on that. After several weeks of waiting and testing alternates, and with shipping of the core product getting delayed, this is the actual reason that came out during a hallway discussion with an engineer. The product management solution was to drop the plug-in and release the product.

If I agree, I will look weak

This is one of my favorites. Engineering managers in world-class organizations have a top educational background, have often won awards for their work and are viewed as stars. So if a great PM comes along with a perfect PRD, and has all the right features dictated by competitive needs, market analysis and user requirements, the engineering manager will simply say "no" to many features to satisfy his ego. (I do not know of any way to solve this problem, except to avoid entering such situations.) And going Agile, and becoming the Product Owner and backlog owner still does not always solve this situation.

Building A Product Timeline - Useful slides available for download

As a product manager, you will have to make presentations that indicate timelines, progress, status, resource utilization etc. Unless your firm has a standardized template for these, making such slides gets tiresome.

While there is never a perfect timeline slide for all occasions, I have created the attached template, that can be useful on many occasions. There are 3 slides in this template, that can be used in different ways. Feel free to modify or use them in any way. Tip: The long term monthly slide is useful for communicating with senior management, to show the big picture.

Annual slide with months

This slide is useful when you want to show a long term roadmap with key milestones called out. This is typically used for marketing, or for summary presentations to senior management. For example, you can use this slide to show when the product concept will be defined, engineering specs delivered, marketing tasks completed and the new version released over 18 months. If you want to add more details, then you would add rows indicating different people or departments where these milestones will occur.

Monthly slide with weeks

Sometimes, you have to show the weekly progress being made towards internal milestones. This slide is typically used when you want to show when each feature is being released. The attached slide shows a timeline over 3 months, and is formatted for the 52 week calendar year. Again, if you want to provide more details, add rows of data for the audience.

Daily progress in a month

This slide is useful for showing tasks to be completed within a month. You can show each day, and exclude weekdays, while indicating when each task is to be completed, using icons from slide1. I have used such slides to show the cross-functional deliverables for a product, when there is a tight deadline to be met. Apart from this, you can also color holidays or internal "dead" days.

So will you ever use all these slides in a single presentation? Unlikely, as these are meant for different audience.

Evangelize product management to stakeholders

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 (especially someone working in India). And these stakeholders have been from engineering, sales, field marketing, program management and many other teams. So a lot of time  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. Note: I am not in favor of sending email blasts, unless most of your stakeholders are not in the same location.

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. He wants information on what are the technologies of focus, what are the skills his team needs and so on. 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. He is looking for something to sell to the account. So you should focus on only the business value of your 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. Typically, such stakeholders include C-level leadership, who really need convincing on why someone 10,000 miles away is useful to them.

3) Sell the role

If you meet a skeptic, then the best option is to offer examples and success stories about the benefit of having a product manager in their midst. For example, if the company is facing pricing pressures, then show, with examples, how product managers can create pricing strategies and the impact on margins.

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. He is also expected to be the key expert on customer needs. If you have something unique that you can share, then you must do so. 

I remember a time when I was asked by engineering, 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 outline of a high level PRD. This gave that team the comfort that I am capable of doing the work, even though I have an MBA from IIM Ahmedabad. 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.

Ask Me Anything - Within Reason

It is always great to hear from people who read this blog and have responded over email or comments. Sometimes you use real identities, other times it's an alias. I am fine with both. If your questions are interesting or within context, I will try to respond back quickly.

However, if possible, kindly provide more details before asking for for my opinion on questions such as:

• How do I get more competitive compensation? (You need to share what you earn now and how you got there)
• How do I get into product management? (What do you do today and what is your educational background)
• How do I crack product management interviews? (There are hundreds of resources out there on this topic)
• How do I grow in my career? (You need to provide your career and current job details)
• I want to return from US and into a product management role in an offshore setup ( This is a mix of #2 and #4)

I try to answer most questions, but without details, you may not get a good response.

All the best in your career, and I look forward to answering more such questions.

For compensation benchmarks or past interviews at large firms, Glassdoor.com has pretty good information.

(Re-post) I Went For An MBA Because I Hate Coding

(This was originally posted in February 2013, updated here)

Ask any software engineer turned MBA student why he is in business school in India, and you will probably hear about his dislike of software development. This is especially true when the student is in his 20's and studying in a full time MBA program. He has seen the typical roles in Indian IT and is looking for something more.

So here's a reality check for all young MBAs out there looking for well paying jobs. The best paying jobs, which occasionally include product management roles, require a significant amount of technical knowledge and close interaction with software developers. And this includes knowledge of software development, business domain as well as familiarity with software engineering processes and technologies.

This knowledge is not important for doing code reviews or software QA, but for truly understanding the efforts required to build a product feature. It is also useful in rapid prototyping of features, building or validating UX designs, reviewing system architecture and so on. 

If a top-notch software engineer is rated a 9 or 10 in his knowledge of Java and SQL, you should reach at least a 5 (on a scale of 1 to 10) in those technologies. Otherwise you risk being shut out of design discussions and your UX and design contributions may be ignored.

You can become a product manager in India without software development expertise, only if you have significant post-MBA experience and strong domain knowledge. Otherwise, treat your programming books with respect and they will help you earn the programmer's respect.

The One Pager about a new product or software release

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 (to be explained in a future post).

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.

Learning about Product Management from India

[Originally posted on desiprodmgr blog in Dec 2012]

You can self learn about product management in a variety of ways. However, if you are working as a product manager, then I strongly recommend that you check out the information provided by one organization, Pragmatic Marketing.

Pragmatic Marketingprovides useful information, course material and training on product management, product marketing and other related subjects, for several years now. They run multiple seminars and workshops. And they also have samples and templates of various documents (MRDs, PRDs) that a Product Manager is expected to create in his work.

Unfortunately, even after so many years, I have yet to see their courses in India.

If you are a PM in India and do not have the opportunity or budget to attend their training programs, you should still imbibe the Pragmatic Marketing Framework. This is a very useful shortcut that summarizes the various activities and initiatives that the product team undertakes during the product lifecycle.

In later posts, I will also explain more about the relevance of the PM framework to a PM in India. I will introduce more links and articles that a PM should go through, for self-learning and competency development. These will also include other popular frameworks and methodologies, books on product management and other related topics.