Tag Archives: product requirements

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.

Advertisements

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.

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.

7 Tips for Fresh MBAs working as Offshore Product Managers

[Caution: long post]

Today, most business schools prefer candidates with some work experience, which is also useful during lateral placements. Hence you see an increasing number of candidates with exposure to IT services or software engineering joining these schools and completing their MBA. Post-MBA, it is inevitable that some of them will head towards product management during campus placements or shortly afterwards. This post is about the 7 things to focus on in your first year on the job, apart from working on PRDs or MRDs.

1. Build a rapport with program managers

In most offshore R&D centers, program managers play a key role in organizing projects, resources and schedules. Hence they know the resource costs and availability for any ongoing or upcoming project. And since engineering dominates decision-making in ODCs (offshore development centers), the program managers help to balance the engineering dominance.

2. Get customer exposure on a sales call

An enterprise sale is a complex process, involving dozens of people from different departments, and it typically has a long completion cycle. You must gain a first hand exposure to how this works, as this is the main source of revenue for the firm and for your product line. However, it can be difficult to gain a sales person’s attention, as he is always looking outwards for opportunities. As an incentive to sales folks to get them to talk to you, arrange a product demo or a feature presentation. If the demo is interesting enough, they will make sure that you get in front of the customer.

3. Gain the trust of engineering and service delivery managers

I have written previously about key stakeholders for offshore product managers. If you cannot get these people to trust you, you will never be able to drive product decisions, even with your supervisor’s help. And you cannot keep going to him all the time. One good technique to gain the engineering trust is the show them that you can deliver on the product requirements and are not simply there because of your MBA. Essentially, you need to prove yourself with every engineering resource, right from the VP to the intern.

4. Train yourself

If you are just coming out of b-school, with a few years of pre-MBA IT experience, you have NO relevant skills whatsoever. The people in the ODC do not care that you can prepare kick-ass powerpoint. Neither are they interested in the font, color or direction of arrows in you block diagram. You must focus on gaining survival skills, which today include, UI design using HTML, CSS and Javascript, UML and MS Visio usage, basic analytics, and programming skills in at least C++, Java or PHP. There is a lot more to gaining skills in multiple dimensions, and I will cover this in a future post.

Do not bother to go for a formal product management training yet. Without relevant experience, it will have very little value and you will forget most of it very soon.

5. Prepare for a change to your role/product within 12 months

In today’s connected, global economy, it is almost guaranteed that your first role will last no more than 12 months. The change could be due to external forces or internal restructuring (ODCs are very prone to this), but it will definitely happen. In the worst case, you might feel stagnating in your role, and you will yourself ask for or start looking out for a change. The best way to survive this is to shine in front of senior management, build a rapport with the US teams and network with HR and other support staff.

6. Connect with Solution Sales, Analytics, Customer Service Teams

This is probably the most important task that you can perform outside of self-training. To understand how the product is built, you need to sit with engineering teams. To understand how the product is sold, you need to work with sales teams. And if you really want to understand how the product is used, you need to work with solution sales, analytics and operations and customer service teams, who cover all real use cases that the product was designed for. And remember, you need to proactively seek them out and learn from them. As a fresher, it is expected that you will be learning all the time.

7. Network outside the firm

There are a lot of opportunities for networking in Bangalore, Hyderabad and all the other major tech. centers in India. You must go to these get-togethers (a few of them are listed in the resources section of the blog). It can be a lonely job, working as a product manager, with no outbound teams near you. Connecting with other people in similar situations is a good way to understand the challenges of an offshore product management role, and the different ways in which people are coping.

Summing Up

A product management role, even offshore, can be incredibly rewarding, but only if you take care of your first few years on the job. It is not for everyone, and you should make sure that you are still interested in it at the end of your first year. Else, as an MBA, it will be easy to find something else.

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.

Are you an expert PM?

A Product Manager should have basic competency in a range of skills, and expertise in at least a few areas. This will ensure his credibility within the organization.

If you are a junior PM starting your career, analysis, documentation and presentation are the first few vital skills. Next comes domain expertise, which you will gain over time.

A mid-level PM, with 3-4 years of experience under his belt, must have domain expertise, strong analytical skills, people skills and persuasiveness. In addition, should know about pricing, marketing, sales and other ancillary functions. He will likely have frequent interactions with clients and partners, so he must promote the firm at all times. These skills are required in addition to the skills of a junior PM.

A senior PM must to have strong leadership skills, project management skills and the capability to hire and mentor junior PMs. He is likely to get authority for contract negotiations, product launches, vendor management and legal approvals. He might also have complete responsibility for one or more products. Again, this is in addition to the skills acquired over the course of his career so far.

Finally, a Director or VP of Product Management is expected to lead product management for a portfolio of products and provide vision and strategy to the organization or the business unit. It involves budgeting , planning, P&L management, inter-department coordination, analyst relations and visibility in the industry as an expert. He has a very strong network of contacts outside the firm which is often used to identify potential M&A targets. He also works with the bankers and the corporate strategy team for due diligence when a “hot” startup is identified.

It is possible to grow in the product management path without having expertise in a few product management dimensions. However, unless you are very, very good at the others, your career will either stagnate or you will become redundant to the firm after a while.

So, looking at your career graph, what expertise have you gained so far. And how did you gain that expertise?

Are you Accurate or Precise?

Nate Silver’s very good book, The Signal and the Noise, talks about the difference between Accuracy and Prediction. Here’s the Webster’s.com definition:

1 : freedom from mistake or error : correctness
2 a: conformity to truth or to a standard or model : exactness
b: degree of conformity of a measure to a standard or a true value — compare precision 2a

1 : the quality or state of being precise : exactness
2 a : the degree of refinement with which an operation is performed or a measurement stated — compare accuracy 2b

So why are they important for product managers?

If you are accurate without being precise, there is a good chance that your work output is of adequate quality. However, it may contain unpredictable variance. In target practice, this is similar to hitting the outer circle consistently while never hitting the bull’s eye. Which means, that while 100% of the product use cases are okay, none of them are capturing the exact user requirements. This can be a distraction to the engineering team and increases the risk of faulty product development.

On the other hand, if you are precise without being accurate, you can have 100% of use cases correctly defined and excellent in describing the user needs. However, you can be very wrong about the intended user. (It is like shooting at the wrong target.) This will guarantee that the software release bombs or does not meet the target parameters.

Accuracy with Precision
A good product manager is both accurate and precise. The accuracy comes from knowledge of customer and market needs and the precision comes from the skills learnt either in the classroom or on the job. Only when you have both can you create awesome requirements, which are translated into wonderful products.