Category Archives: In the Workplace

Marissa Mayer should read this blog

[All respect to Ms. Mayer, she’s accomplished a lot in the technology industry]

I have blogged earlier about how a PM must tackle challenges to his authority from a strong engineering team. Well, if you read this article from the Business Insider called “The Truth About Marissa Mayer: An Unauthorized Biography” you would realize that these inter-personal conflicts occur in almost every firm, right from a 5 person startup to the largest internet giant.

[ The Business Insider article is also a must-read for the details it offers around the activities of a web PM in a senior role]

The article also mentions how her run-ins with engineering led to her ultimately being sidelined into a different role at Google. In fact, as many can attest, this is a common theme in technology product management. If you come up against a powerful engineering lead, then the person most likely to move out is the one who does not write the code, even if she is closer to the customer.

A couple of references from my blog here. Here’s the first post where I described how engineering and product management can have creative conflicts.

Here’s another post where I specifically mention why obsession is important for a product manager. As per the unofficial biography, in Marissa’s case, her obsession with details caused resentment in engineers and other stakeholders who did not agree with her vision. Another issue was that her obsession was primarily about data analysis and the value of that analysis, without understanding the impact of her decisions on others. And that was a key factor in her getting sidelined. The article also mentions how this obsession had also alienated a lot of people at Yahoo!

Without getting into the merits of this debate, I leave it to you to draw your own conclusions.

By the by, I have posted earlier on why analytics is important for a PM today, but that is not specifically about the UI analytics, as was discussed in the Business Insider article.

Advertisements

Fashionable Feature Sets

In technology product management, it is easy to get tempted by the fashionable trends of the season. Today it is features related to “Big Data“, earlier it was “Web 2.0 Features or SLATES” and the latest trend is to add mobility features and access to your offering.

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 buying customer and his product reviews that are the key to gaining marketshare 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

FashionSo 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. I will address this in a future post.

Web Recruitment Ad – 6: For A General Manager

Now this is an interesting recruitment ad on LinkedIn (job posting is removed):

Designation: General Manager-Web Publisher Products

Location: Bangalore

And here’s the interesting part, in the description of Professional Background and Experience, the ad states that “A degree in Computer Science or a related field is highly preferred”.

It is remarkable that for selecting a person in such a senior role (at least in the Indian arm of Amazon), the undergraduate major is “highly desirable”. Does this mean that a top manager without a computer science or related background is unlikely to be hired, or may not have a good career at Amazon India? And perhaps this also indicates their lack on interest in hiring MBAs in such roles.

Now this may be a typo in the ad, and I do not have the inside information on why they would insist on this, but if you add in this news report that the Yahoo CEO is looking for computer science graduates from top colleges, then things become murky.

Here are 3 things to ponder:

a) If you are a product manager in the web world and do not have a computer science background, are you likely to hit a glass ceiling?

b) How is a computer science degree correlated to success in a general management role?

c) Is this ad a self-selective ad, which indicates that IITians with a computer science background, who have been successful in their careers, are what Amazon is actually looking for among the applicant pool?

Disclaimer: I have a lot of respect for Amazon.com and the work they do in India and overseas. I was just curious about this report on Yahoo and the Amazon recruitment ad, and hence this blog post.

A Program Manager Can Be More Powerful Than A Product Manager

The title of this post may seem illogical to some. After all, the Product Manager (PM) is the one that leads product releases and is often responsible for product P&L (profit and loss). And a program manager (pm) simply tracks activities in MS Project. So how can a pm be more important than a PM?

I first heard this from a Director of Engineering at Microsoft, Seattle. He explained that in consumer products, it is very important to get the pulse of the market, and hence everyone listens when the PM talks about features, use cases, revenues, competitors etc. Whereas in enterprise products, there is often a vast pool of resources to manage that work to deliver a single product release on time and within budget. Hence the teams of pm become very important to the product line. And since they have fewer releases per year of enterprise products, the program manager has a more significant role to play there. Of course, the pm in Microsoft has a different role than a traditional industry pm. [ A description of MSFT program manager’s role in India is given here.]

In offshore roles in India, the prominence of the role of a pm and a PM depends on their level of independent responsibility. If either the pm or the PM’s reporting hierarchy is to the product line management (typically in the US) instead of India operations teams, then they have a strong and important role. Otherwise, given the typical scenario where you have offshore engineering centers, a pm coordinating engineering projects is sometimes more powerful than a product manager. In fact, having both product and program managers report to an Engineering Director is also not uncommon. This can occur in both consumer and enterprise software firms, and in both cases the pm can have a more prominent role than a PM.

So, if you’re researching on alternates to an operational product management role in India, a pm’s role is worth a closer look.

Does Your Product Line Need A Blog And A Facebook Presence?

Google has a lot of official blogs. Here is the main one, and at the bottom, you can see links to several other blogs, including corporate, product and developer blogs. (The complete directory is available here. So does your company follow this trend and also host several blogs? And what value do these blogs actually provide.

I read this blog post on a large software company’s product line blog. That line is a specialized category with limited consumer interest. They wrote that in 2012, they got 50k page views and over 10k visitors.[ Note: this is a top level number and does not delve into much detail on accuracy, visitor segmentation etc] And this is a well maintained blog, with articles on product usage, updates from engineers and product managers and information on industry events.

Now compare that number with those for a product management blog, such as the one called Mind the Product. I am sure that a blog like this, that comes on top of google search results for “product management blogs” must get at least 5k page views a month. I know it’s like comparing apples and oranges, however, the benefits of any blog must be analyzed independently of other factors.

So here’s my point. For a niche product, it may not be cost-effective to only maintain a blog. Instead, an added social presence, such as on Facebook might be a far better mechanism. And incidentally, very few consumer tech. products have a presence on Facebook. So getting there might be a leader’s move.

Any challenges to shutting down your blog and starting a Facebook presence? A few come to mind.

1) Accessibility: If your audience is business users, they may not be comfortable surfing Facebook from work. And from home, they may use personal accounts, which may hide true audience demographics.

2) Search: Facebook search is good, but for general search terms, Google search is better

3) Privacy: You may not want to publish information about your followers, as your competitors could also be lurking there

In the end, your leadership team’s vision will decide how you approach social media, and how your product gets the benefits. But if you want to make a case for a Facebook presence for your products, do think about the above factors.

5 Reasons Why Engineering Teams Say “No”

As a product manager, you should be used to hearing “NO” from every stakeholder, including the engineering teams. Of course, if you are talking to a vendor, or an IT services firm, you face the other challenge of hearing a “YES” for everything.

With engineering teams, sometimes there is a hidden reason behind their refusal of a product/feature concept. Here are 5 reasons why PMs I know were not able to push through product requirements.

1. 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 HTML 4 to HTML5 and introduce SVG viewer and other features. Unless there is a business need or a strong performance reason, the “coolness factor” could be lurking.

2. It’s Too Tough

This is what I heard from an intern who joined the team. They had worked on a matrix based hierarchical organizational 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).

3. 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, the workaround is to offer a bundle of features, where they cannot pick and choose. By the way, these are the features that will slip the most in an early release, as they are deemed “non-core” features. Usually, the web-based GUI often falls in this bucket.

4. We Do Not Know That Technology

No true engineering team will agree to 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 solution was to drop the plug-in and release the product.

5. If I Agree To This, 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.)

As I have blogged about before, this is not about the quality of the PRD, but about saving face. The same feature set might be picked up later, after the PM has moved on.

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.