Tag Archives: use cases

Time To Get Agile/Scrum Certified

In earlier posts, I have written about the challenges of agile product management. I also reviewed a pretty good book “Agile Product Management with Scrum” that you should read to learn about Agile software development and the Product Owner/Manager’s role.

Well, now it may be time to go one step ahead and become a Certified Scrum Product Owner (CSPO).

This certification is a basic two-day introduction to gathering requirements and delivering them to the scrum team in the format of user stories. After getting certified, you will also get access to the online forums, blogs and other resources that you can use to hone your story-writing skills. One advertised benefit is the ability to show potential employers your knowledge of Scrum. There are some other certifications associated with Agile development (Scrum Master, Scrum Developer, Scrum Coach etc.) which are of limited use in a Product Owner role. You can find more information on these with a simple Google search.

Alternatively, you can go for the PMI Agile Certified Practitioner (PMI-ACP)® certification. This looks like a rigorous training with a lot of pre-qualifications before you apply for the certification. However, if you are already PMP certified, then it may be easier to get this certification. Personally, I am not in favor of product managers going for a PMP certification, for the simple reason that product managers have a different role that project managers.

If you are an old-timer in the industry, you might remember how Rational OOAD and UML was a pretty big thing at one time. And to get business analyst roles, you had to be well versed in those tools. Now with teams going agile, these certifications may give you the edge, when you are out there, looking for a product manager/product owner role.

Do understand your own career aspirations, the costs associated with these courses and then make an informed decision on either of these certifications.

The “One-Pager”

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.

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.

How To Start A PRD


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.


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.

Social Media and the Product Manager in India

[The original title was “Facebook and the product manager in India” however, I expanded the post to include all social media]

So what is the value, if any, of social media to a product manager in India? The short answer, for consumer products it is a vital communication channel whereas for enterprise software, it is just another way to connect with clients.

Let’s break this down into some detail here.

What is social media?

Social MediaWikipedia has a good article on social media with a clear definition. For me, social media is all media or any communication channel where user-generated content predominates. This includes blogs, YouTube, Twitter, Facebook, Google+, Linkedin, Pinterest and all such entities. It is usually a broadcast medium, which also enables peer-to-peer interactions (sometimes its the other way around). I also include product forums in this definition. Now let’s take a look at the value of social media.

Social Media for Enterprise Product Managers

Market Facing Roles
If you are in an Indian market enterprise product management role, you need to be aware of social media, and run a blog. The reality is that very few enterprises in India have adopted social media at all. And it is not seen as an authoritative communication channel. You should focus only on gaining experience of working with social media, for future opportunities.

Offshore Roles
In an offshore enterprise role, you ability to influence social media is limited, however, there will be ample opportunities to consume social media. For eg, on twitter you can follow @Forrester and similar sources and collect news and updates about the industry. Or you could update your company’s YouTube channel with product videos or slideshows, usually in collaboration with the product marketing manager.

Social Media for Consumer Product Managers

Market Facing Roles
In a market facing role, you really need to establish a social media strategy for your product. This will include the channels to use, the content creation and sharing plans, market research plan, the quarterly connect with customer plan and other relevant details for your strategy. Additionally, you need an analytics tools to track online customer sentiment. Customer sentiment is a useful input for new feature ideas or feedback on existing features.

Offshore Roles
There is lesser challenge in consuming and interacting on social media in an offshore product management role for consumer products than enterprise products. The main difference here is that your ability to connect the social media updates with real world interactions is severely curtailed. However, you can maintain an active presence on Facebook or Twitter, based on your organization’s policies.

Content Creation Strategy

Fundamentally, content creation must be tied to the goal of connecting the product with its customers. If you think up enough use cases, the content for communication will come up by itself, and then the main task will be to translate that content into appropriate form (video, slides, tweets containing URLs, blog posts etc) to share via the different channels. You should get the marketing communication team involved in this effort. Creating research polls and soliciting beta testers is also easier if your presence is already established online.

Content Consumption and Analysis Strategy

In my opinion, you should subscribe to a feed service and an analytics tool that a) summarize the updates on different channels b) provide reports on those updates. Unfortunately, most services offering these capabilities are expensive. So a free substitute would be to download these updates periodically and use open source tools such as PSPP to analyse the information. If your marketing team has a social media presence, then the same people can help you set up your product’s presence as well.

Summing Up

Social media is a somewhat useful tool for a product manager in a variety of scenarios such as sentiment analysis, sharing product demos and videos, getting industry updates, tracking competition etc. It’s importance changes relative to the type of product management role you are in.  It is good to consume social media if you’re working in an offshore role, whereas it is important to develop and maintain a strong presence for your product line in a market facing role. And remember, the social media presence is for your product or product line, not you as an individual.

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 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.

Customer Interviews: Collecting Product Feedback

So you are a product manager, and you wish to understand what customers do with your products. And you have management approval to do customer interviews to get product feedback. What comes next?

A. Identify your research hypothesis
Will you be doing a customer survey or in-depth interviews? Will you perform statistical analysis on the data. Are you going to conduct these interviews every quarter or is this a one-off initiative.

B. Create a contact list
Do you have designations, email ids and phone numbers for these people? Which verticals, geographies and account sizes are you targeting?

C. Check with do-not-call lists, account teams
The account teams will give you strong indications on whether the account is positive, neutral or negative. You must stay in contact with them before any interviews. In fact, it might be a good idea to invite them for the call/meeting.

D. Prepare a questionnaire
What features of the product do you want feedback on, what are the key product dimensions you want analyzed, what are the customers pain points, what is their perception of the market and so on. A formal questionnaire to follow-up with after your meeting will help both parties to stay focused.

E. Do the interview
Set up a suitable time and place, and collect the customer feedback. Make sure that you take extensive notes, or preferably record the interview for transcribing later. Ensure that the customer is aware that you are recording them.

F. Build a data collection and analysis plan
What data points are you collecting, how are the results presented (Powerpoint, Excel charts etc). How do you plan to keep the data confidential?

G. Share the results with everyone
It is important that you share your insights with the engineering, marketing and senior management teams. They are going to learn a lot about the product, and your customer interaction skills, from this initiative.

Bottom Line

Feedback forms by themselves are of little use in really understanding customers’ pain points. If you want to focus on customer development, or build awesome use cases or user stories, the key is to understand your customers. A good market research hypothesis, and your preparation for customer interviews, are vital to complete this initiative successfully.