Tag Archives: engineering

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

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.

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.

True Stories: When Engineering Dominates Product Design

Sometime back, Slideshare decided to move from Flash to HTML5. As a PM, I would definitely support this decision if the cost-benefit analysis proved it (and Slideshare agreed with this), and this extended my product’s life-cycle. If this necessitates re-work, then that is the cost of product improvement, and must be accepted. However, if such a decision is taken because HTML5 is “cool” and Adobe Flash is “not cool”, then no self-respecting product manager should support it.

Here are 2 true stories (somewhat modified to hide identities), that illustrate incorrect design decisions.

I – The Perfect Design

A friendly neighborhood product manager narrated this to me a while back (If you’re in Bangalore, there are product managers in every neighborhood). He had joined a crack engineering team working on web technologies. Their mandate was to develop a high-performance, ad-publishing service for e-commerce websites. While he analyzed competing solutions and worked on a detailed PRD, the engineering team decided not to wait, and started building out a complex, computer science Artificial Intelligence (AI) model in a solution.

Six months later, the software was ready and the team started releasing it for various websites. Unfortunately, severe bugs kept cropping up in deployment, over different product components, which meant that a major re-design was probably necessary. After a lot of back and forth, where the PM was overruled, the team decided to keep their AI model, and started developing AI model version 2. After another three months, that too turned out to be too complex for high-traffic websites. In a bizarre twist, the team decided that the PM was not “technical enough”, and they wanted to promote someone from the engineering team as the PM.

Once the new PM came into the picture, he opened the PRD written by the former PM. The team abandoned the AI model version 2 and rebuilt the product based on competitors’ designs deployed on real websites.

Epilogue: The product was released a full year late, and has few real world deployments. While it has a smaller feature set than its competitors, it’s still shown as the “crowning achievement” of the engineering team in India. The former PM now works for an e-commerce site in the US.

II – The Immature Team Leader

In large Offshore Development Centres (OSDC) several engineering projects are incubated under the “20% Time” theory, popularized by Google engineering teams. These projects can often yield useful results, but many are not worth commercializing, especially if you are in the enterprise software business which is aligned towards solutions now.

Out of one such project, a team leader created a “secure web communication service”. He was feted for this effort, promoted and moved into product management. After he left, the team tried to advance the product into a usable form. They found that it:

  • supported only 6-10% of targeted throughput
  • did not support any browser except Firefox 3,4 and IE 7
  • had massive memory leaks, was crash-prone and hard to debug
  • used up enormous CPU time on the client side

Apparently, all this was suspected when the team leader was developing the product/service. However, as he was a “rising star” and favored by an engineering VP, everyone looked the other way and QA signed off quietly.

A year later, the product was discarded and replaced by a 3rd party product, purchased under a commercial re-use agreement, negotiated by the same PM’s manager!

Conclusion

There are countless opportunities for bright engineers in India to build products. However, the “code” is just a small part of the product, and if you have a bad design or software architecture, no amount of coding will make the product perform as expected. In India, the “development process” is often prioritized over rational decision making, which makes it impossible for the product manager to do his job (make a product succeed in the market over its life-cycle).

How To Start A PRD

Background

The Product Requirements Document (PRD) and the product roadmap are the two key artifacts that a product manager must have mastery over, for success in this role. In many firms, the PRD is called something else, such as a Business Analysis Document (BAD!), Product Requirement Specifications (PRS), Marketing Requirements Specifications (MRS) and so on.

Here are a few links to articles on different websites about what a PRD should contain.

One challenge you will face is that there is no easy way to start a PRD from scratch. And you will encounter such a situation if you join a startup, or begin work on a new product, or start working in a new firm. Here are some tips that can help you start the work:

A PRD Follows A Template

The PRD for a consumer electronics product, a web-based product or a VAS product such as caller ringtones are very, very different. Still, all the PRDs follow a common template used within the organization. You should pick up the most recent template in use based on past available PRDs and start filling out the different sections within the PRD.

If you are working in a startup, a quick web search will give you many links where you can download PRD templates. Use the template as a starting point, and simply remove all sections that do not seem important. What remains will allow you to begin writing product specs.

A PRD Is A Live, Versioned Document

As you start writing use cases, functional specifications or other details about the product and product usage, you will quickly realize that this is an iterative process. So you can take 2 approaches to make a good PRD – cover it depth-first or breadth-first.

The depth-first approach is good if there are multiple product managers, or if you have an external dependency. This way you completely scope out a set of features for the engineering team to review, and then to start their work.

The breadth-first approach works best when you are not sure of the specs., and have multiple engineering teams waiting for the PRD. This way, you have something for all the teams in the first draft.

Remember, even after a PRD is reviewed, and specs are accepted after modification, you can make changes and add those to the appendix. This way, a new joinee can see the document history, and understand the product evolution.

Start With Functional Use Cases

Unless the product is a set of API for scripts on the web to use, every product will have use cases. These will include how the product is installed, how it is started, how the controls function, what are the roles of the users and so on. These are easily translated into straightforward use cases.

You should list out all these use cases, write a one line summary for each of them and then break them into functional groups (error handling, security, startup etc). These will help you build the base of the PRD.

Break Up The PRD Into Sections

One section of the PRD must cover the business problem you are solving and the potential revenue opportunity. If you have those, and the functional use cases, you are very far along on the first draft of the PRD. Additional sections that you need to write specs. for will include the performance requirements, usage constraints, security specifications, dependencies and so on. You should spend a lot of time to write these, as these are the tricky issues that can cause major problems after product release.

Make Lots Of Diagrams

Any time you feel that there is a complex use case, or a particular system component is hard to describe, make a diagram. You can make block diagrams, flow charts and navigation maps and anything else required. And you can either add them to various sections of the PRD, or keep them at the end in the appendix. Make PPTs if required and insert them in the appendix.

More Is Good

A PRD must have a lot of details about every feature, requirement and scenario. This will remove ambiguity, simplify the design process and avoid trouble down the line. Use as much detail as possible for every facet of the PRD. It is actually for this reason that many firms use 2 versions of the PRD, a smaller version in PPT format summarizing the product release for external audiences, and a detailed version in a DOCX or XLSX format for review and referral.

Forget The Competition’s Features

Sometimes, a PRD will contain comparisons with a competitor’s product or even specific features. This is a waste of time, as you are comparing a current feature set with something you team will deliver much later. Such comparisons should not enter the PRD, however, you can add a list of internet resources on the competition to the references section of the PRD.

Summary

Writing a PRD is a prestigious task for a Product Manager. Following the guidelines listed above will let you create a high-quality PRD within a few weeks, that will be acceptable to all groups, and will allow engineering to build the solution that you describe.

Web Product Manager Recruitment Ad – 5

On Feb 8th, Ebay posted a recruitment ad for a Director, Product Management in Bangalore.

The complete JD is available on the link above. In December 2012, they had hired Ramkumar Narayanan, VP Product Management, Yahoo!, as the GM for their India center, so their focus is shifting to Bangalore. Should be an exciting time to join them.

Location: Bangalore
Desired Qualification: Long list of experience, capabilities and personality traits listed in the ad
Desired Experience: Not mentioned

Here are some points to consider about the role and the firm:

  • This looks like a new, senior level role in their eBay India Center of Excellence.
  • The ad mentions the job title as Director, Product Management 1 – Tech. so it is definitely for someone with a strong product engineering background.
  • Networking skills and industry reputation will be the key to getting an interview for this role.
  • Based on data available on glassdoor.com and other internet sources, the typical salary for this role should be more than 45 lpa CTC. This would exclude RSU/Stock Grant/ESOPS or other bonuses. The ceiling could be a total package of Rs. 65-70 lakhs all inclusive for a very, very good candidate.
  • Roadmapping is a key requirement for this role, and hence someone with an MBA and many years of product management experience should be an ideal fit.
  • The role will involve building and grooming a team of product managers. Given that such roles typically go to people with an MS/MBA from a top school in the US and significant US work experience, the product managers hired later would likely have a similar profile.
  • You can expect ads for junior level product managers once this position is filled out.
  • India engineering, US senior management and India leadership team will be the key stakeholders.
  • This role is unlikely to carry P&L responsibility for a product line, but would probably focus more on building the product management competency in India.
  • Growth after this role could be to another organization in the e-commerce space or an IT consultancy or strategy firm. Or you could join a startup as a CEO, CXO etc.

Disclaimer: I have a lot of respect for Ebay.com. This post is only provided to prospective PMs to help them to interpret job ads for product managers

If you have applied/joined somewhere for a web PM role similar to this, then drop me a comment, and we can discuss the same.