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.

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.

Agile and Accountability: 7 Things to Get Right

Very often, Agile is presented as the panacea for delayed releases, disconnect between the business and technology teams and the slow pace and long release cycle of the waterfall method. Well, Agile is simply a process to develop software, with its own positives and negatives. A process by itself can never be perfect, and with human involvement, there is a high likelihood that the new method will also fail, although in different ways from the old software development methods.

In this post, I would like to describe the key challenges that a product manager must watch out for, when he

  1. Joins a team following the Agile methodology and Scrums for software releases
  2. Joins a team that is transitioning from Waterfall to Agile

The information here is useful for both offshore enterprise and consumer product managers.

1. The very first thing he must ensure is that all requirements are clearly defined and documented. When something goes wrong, or the engineering output is not satisfactory, the first thing to do is blame the quality of requirements. My advice would be to never change requirements even if a customer demands a feature enhancement. You can always add it to the backlog, instead of disrupting the existing backlog.

2. The next important thing is to make sure that all processes are clearly defined and documented. If the team is transitioning from Waterfall to Agile, the program manager must remain available until at least 2-3 sprints are completed. It is also vital to make sure that a Scrum Master is designated to track the team progress. The Scrum Master must not report to the engineering manager. Weekly sprints must reach their sprint goals.

3. Make sure that QA is independently accountable, and is testing the weekly output both for new use cases as well as regression testing for existing features. One team I came across had QA also reporting to the same engineering manager. Needless to say, either bugs were not reported or were immediately reduced in priority.

4.  Make sure that the non-functional requirements are adhered too. A common excuse I have heard is that since this is the first version of the use case implementation, we will improve performance later. Well, no client is going to wait for a half-baked feature, and releasing that feature will only cause high priority customer escalations, reducing sprint velocity and causing a cascading effect on other features.

5. At least 20-25% of the development time of the engineering team should be spent on defect resolution. In fact, one sprint out of 4 or 5 can be an exclusive bug-fixing one. This will ensure a reasonable product quality after a while.

6. Make sure that the effort estimations do not vary from week to week. This is the most common trick employed by engineering managers to prioritize features that they want to build, and change the product backlog priorities. There is no easy solution for this, but if you closely track the past performance of each engineer (yes, YOU have to do it, with the help of the scrum master) you can get a good idea of the real vs. claimed effort estimates.

7. Finally, do not hesitate to call out the engineering manager if you see the product drifting, the quality being lowered, or the performance not up to the mark. He will blame someone from his team, perhaps even fire someone to make an example of him, but ultimately, each engineer is accountable for his output. And he is accountable for managing them. If required, escalate to the engineering leadership and make them aware of the release delays. In addition, if you keep your own leadership informed too, then client escalations will not cause too many disruptions.

One final thing, there are never as many engineers of sufficient quality as desired. And recruitment remains a constant struggle in the product development world. It is not your job to manage this constraint. And yeah, the old story of tripling the engineering estimates to plan a future release date makes a lot of sense in India.

There are dozens of tricks and pitfalls to watch out for, when Agile is proposed as a software release process. This post mentions a few, but the key to on-time, in-quality releases remains close tracking of the progress made by the team against the defined requirements.