Search This Blog

Friday, December 28, 2012

Interview Strategies - part II

This is going to be a real short one. This post is in continuation from my earlier post (interview strategies - part I), wherein I shared my experience and methods of shortlisting candidates for the post of product manager. In this post I would like to caution interviewers of some Don'ts of telephonic round.

Objectives of telephonic round is to ensure that candidate meets all prerequisites of the role. Telephonic round is like running a small software utility before installing your software to ensure that computer has necessary environment to support your complex product.

Monday, December 24, 2012

Interview Strategies - part I


Recruiting a product manager is a big task, and a challenge that has taught me quite some interesting ways of assessing candidates and making sure that I pick the best fit candidate for my requirement. Going through large number of CVs, shortlisting and interviewing is a tiring processing and without having proper strategy, accuracy of judgement will be low.

How to I judge a candidate, how do I differentiate between what a candidate pretends to be vs how he is. From my recent experience, I have realized that having a strategy to interview candidates is non-negotiable. While I continue to learn and improvise on my strategies, here are some ideas I found useful to judge a candidate's fit into the role.

Start with yourself, have clarify in Job description and know your preferences before you start looking into CVs shared by recruitment team. Make sure you are clear of expectation from the candidate and are sure of candidate's growth path in the company. Interview is a two way process, while you assess candidate, candidate too assess company and people with whom he interacts during the course of interview. Be clear with what is that you are offering to a candidate and what is a good reason for him to join you.

Thursday, November 29, 2012

Paradigm Shift


Product is a tool used to address a market opportunity. Idea of a product is conceived from the opportunity, and it (product) takes shape as it grows and as needs evolve. Keeping track of evolving needs and growing product is a function of a product manager. Product Manager makes sure that they keep track of the evolving market by uninterrupted communication with stake holders, customers, engineering and market. These needs are consolidated, filtered and refined to define product road-map and to draft requirements of every product release.

It is critical that a product manager understands the difference between managing product verses managing opportunity. A product manager should always look at product from the lenses of the opportunity.  How well does the product fit into the opportunity? , what are the improvements required? , Is my product aging and should I start looking at alternates? Which features would make product a better fit for the opportunity? Looking through the lenses of the opportunity, if a product manager sees a clear and sharp picture of the product then this justifies the very existence of the product.

Tuesday, November 20, 2012

The New Product Manager

A good start is half the success. and how do you ensure this at you new job? It's a serious challenge for product managers who are moving into a new job. The challenge becomes more stiff if you are moving into a newer domain, and are going to work with whole new set of professionals you never worked with.

From my experience I have coined down first few steps that a product manger should take as soon as he gets onto a new job. My fair assumption is that you would have learned and read enough about the domain in which you are going to operate, however knowing things from outside may not be as clear and absolute as you get to see when you get into the system.




Learning Steps


Tuesday, October 30, 2012

Evaluating a Product Manager

Quick thoughts on areas to assess candidates for product manager's position, once again from my recent and past experience of recruiting product management professionals for various organizations I worked for;

Evaluation Criteria 

  1. Technology comfort: A candidates ability to understand technology is very important. Candidates shying away from technical terms, unwilling to learn technology trends is a definite NO for product manager's position. This does not mean that a candidate should be a engineer or techie, he should have an appetite for technology, this helps him to leverage upon technology strengths and also plan for  technology limitations.

  2. Business acumen: have you ever heard of top line and bottom line? do ask this if the candidate comes from technical background, after-all all your actions (as product manager) must influence one or both of these lines in positive manner. A candidate falling short of expectation on technology front can still be consider, however a candidate falling short of expectation on business is big bold NO.

Tuesday, October 23, 2012

Product Managers, beware of fabulous ideas


Believe it or not, ‘fabulous ideas’ are the most scary part of a product managers life. I am talking about instances wherein  someone from some corner of the  office, raise hand and shout out ‘hey! I have a fabulous idea’ – this not only means that you listen to my already certified ‘fabulous’ idea but also do include this in the ongoing or worst case next sprint. Product managers are expected to listen and agree to such ‘fabulous’ ideas, after all its their duty to collect requirements and put them on the roadmap!! – but where is the filtering part? Listening is fine, collection is ok but adding is last step. All ideas, suggestions, improvements & corrections must go through a proper review cycle, and should be evaluated before they even qualify to be termed as ‘idea’. Before filtration process they are merely some thoughts which may or may not make a good product sense.

Thursday, September 27, 2012

Start-up Product Manager

Quick thoughts on 'how a start-up product manager should be like'. From my experience and understanding, start-ups are best place for a product manager to test his/ her skills, so if a start-up experience is missing from your profile, get it now, but before that check your compatibility with start-ups here.

Start-up Product Managers......
  1. ....do not read job description in detail, but instead focus on domain, market & technology of job opening. If you are someone who reads job description 4 times before applying for the job then you may not be a good fit for Start-up kind of job.
  2. ....read about founders, co-founders and the team they would be working with, and would least worried about organization structure, and job security. They spend time searching and reading about founders & co-founders, to understand their vision and ability to persist long with a business idea
  3. ....do not look around for IT support when face an issue working with out-look, MS-Office or for that matter any software application, they just google their way to solution. If you are someone who rely on support staff for app support etc, you are most likely to runaway from the start-up job in first 6 months itself.
  4. .... do not wait for QA to handover smoke test report, instead they download the latest dev release from build server, perform a round of testing and post results on the wall.
  5. .... habitually do not use calender for booking meeting slots, they just go to concern person and pull him/ her into a room, talk and close the topic.
  6. .... need to be reminded quite often of their loosely tighten shoe lase. if you are someone who finds it difficult to walk with lose lases, think twice before applying for a start-up position
  7. .... are most likely to miss salutation and conclusion part in their emails.
  8. .... put their priority in following order, productivity, people, and process. If you are someone who cares for process above productivity and people are most likely to fail miserably on your new job.

Working at start-up is litmus test of a product manager's ability to own a product. Working at start-ups is like stress, volume & regression testing of a product manager. Its tough, really tough to excel under extremely uncertain conditions, but if you manage it once it could be your 'Berlin-wall tear down' moment to glory.


more thoughts on this in coming months, but if you have something to share or add, do it now in comments section below.

@mathurabhay

Monday, September 17, 2012

Product Manager, heading for crash?

product management
Product Manager Distractions 

Just like a car would crash when the driver shifts focus away from the driving, the product or / and product manager are sure for a crash  when product manager  shifts focus away  from the core deliverable.

Crash could be due to two reasons, one, you tend to do something you are not suppose to do and  two, you do-not do something which you are expected to do.

In example of a smoothly running car, the driver may get distracted by a beautiful girl walking on the street, or the driver ignores traffic lights. In both the scenarios, driver shifts his focus away from core responsibilities and ends up meeting with undesired consequence. When the driver sees a beautiful girl walking on street, he gets carried away by the beauty and gets lost admiring the beauty so much that he would realize this shift of focus only after car crashes. Ignoring a traffic light or taking it lightly could do the same to the car and to the driver. 

Saturday, August 25, 2012

Success Mantra for Product Managers

Job of a product manager is strategic in nature where quality is of paramount importance and at the same time it (quality) is difficult judge on shorter duration. Product Managers run marathon and not sprint, it is important for him/ her to be focused for longer duration and deliver quality output consistently, a challenge I guess many struggle to deal with. That's where you see these Jumping Jack product managers who habitually stays for less than 18 to 24 months on a job (2 or more jobs)  or who have never experienced a complete life cycle of the product.

Is it that difficult to stay for 24 months, or experience a complete product life cycle. Wait and see what happened to the decisions that you made last year or in initial stages of product development. What happened to those critical decisions you made in growth phase of your product and how long did your product stayed in maturity stage. Product Managers who do not stay long, would never ever be able to experience these situations.

Sunday, August 12, 2012

Product Managers, learn to listen

"To Listen" is very imported for a product manager. Listening is a skill, and for a product manager this skill is on the top of the skills list that a product professional must acquire. Effectiveness of core deliverable like identifying opportunities, writing business plan, collection requirements, PRDs, and release prioritization largely depends upon how well the product manager has mastered the skill of listening.

The purpose of listening for many as I observe is to reply. Start replying, even while the speaker continues to put his point or frame up reply while speaker is talking and start speaking as soon as he is done.

One of the major role a product manager (read expectations from product manager) is to consolidate inputs from various sources (read requirement gathering), compile them and take decision that would best benefit product & business strategy. It is hence imperative that product manager masters this skill of listening to its best. 

Thursday, July 26, 2012

While you add new feature.....

Adding new feature is always a fun, going through list of backlogs, talking to stake holders and trying to work out the priorities of user-stories in backlog. Its also challenging because you as product owner are always under pressure from sales who want to add feature that their customer is looking forward to, or their potential prospect would not sign a deal unless you add that one golden feather in your product.

To understand true priority most of us follow a release prioritization matrix, a document (MS Excel file mostly) that helps product owners to put weightage against various features (backlog items). This probably is a good way to do find out priorities of various feature requests.

While you work on your prioritization matrix, do all maths and talking, you must always remember the primary reasons for adding a new feature (points mentioned below), and unless new feature request falls in any one of the following primary categories just avoid its inclusion in your next release.

Saturday, July 21, 2012

Start-up Musts

A picture is worth thousand words. Here is one with some explanation on what start-ups should be like. Inspired by the characteristics of Octopus, this post suggests 7 simple to build characteristics of a start-up.

Sunday, June 24, 2012

Things that you must ensure in your CV

This post has come from my recent learning while scrutinizing Curriculum Vitae for the post of Product Manager. Reading through dozens of resumes for almost 2 full days, I realized that I have learned a lot about many good companies and good products that they develop. Probably on some occasions I even could tell the release history and features highlights. This was because candidates often mix up their personal CV with corporate product brochurer. Speaking with few of them over telephone, I learned that they have started believing that highlighting success of product that they owned is good enough for them to get recognized as a hero and potentially a good candidate for job. Something that I found difficult to understand and I recommend that following should be ensured while drafting your CV.

Tuesday, June 12, 2012

Monitor Feature Usage

Exploring user usage data to determine what he/ she is liking and valuing is of great importance for a product manager. User data helps in knowing what strategies are working and which needs to be re-worked upon. Importantly, inputs from user usage data may also influence product road-map in a greater way as it is direct input from users to product owner. 

User usage data will help a product manager in knowing;
  • who is using feature, and when (time, circumstance etc) is he using them.
  • most commonly used features and least used features
  • is this feature being used for the purpose it was designed for? 
  • feature combinations used
  • duration for which software is used for
  • how often user visits helps page and what content do they search for in help files
  • abnormal software exit
....and many more similar questions that a product owner or product manager is expected to answer.

Tuesday, May 29, 2012

7 Things you must tell your manager


While the title itself is self-explanatory, I would like to add one  point here before you jump on the the numbered list. Your professional growth depends, not just own your accomplishments, but largely on how you communicate your accomplishments and how rest perceive your accomplishments as. Your image, or the mental model that people create of you could make or break your career. And if that person is your reporting manager, things become far more serious. So how do you control the negative influence or in other words how do you positively influence your manager, and help him  build a positive mental model of your personality. Objective is positive image and career success.

Here are 7 things that you must tell your manager on regular basis, as they happen and as you realized it happened.

1. I tried but I failed
Success is preferred outcome of an well executed effort, however it may not be the case always. Communicate your manager about your failures, does not matter how diminutive the task was. It sends a strong message about your character, you don’t shy away from mistakes or failures but you face them and state them. You can be trusted.

2. I learned that....
One thing that comes with both success and failure is learning. What did you learn from this experience of yours. Tell your boss and let him know that you have learned and grown with each project / experience. You are improving day by day.

3. I did this differently
doing is not enough, doing same task differently, or exploring newer ways of doing same old stuff shows that you take keen interest in your tasks and do not get bored too fast. You can be a person your manager will look upon in the difficult times as you will develop a habit of doing things differently.


4. I initiated .....
This is a really very strong positioning of yourself. This conveys straight message that you are a person who drives things and not just wait for directions. You are proactive, prudent and intelligent.


5. I prevented....
You once again demonstrated your prudence here. This statement will largely convey the message that how you ensured that productivity of many was not impacted (negatively) because you could sense something wrong and stopped it. A penny saved is a penny earned.


6. I appreciated....
Your are not arrogant, nor do you believe that you are superior than others – prove this, appreciated efforts put in by others and let your manager know that you do value your team and colleagues. You are a team player

7. Yes, that was done on time
Make your boss believe that the task assigned to you is considered done. You are his most reliable person.


Keep your manager updated, remember ‘you always have the power to influence mental models that others make of yours’. Practice this regularly and updated me on your next promotion.

@mathurabhay

Tuesday, May 15, 2012

Trait that creates a success manager – VI


Trait – build what customer like and not just what you prefer

A typical business challenge that a product manager is expected answer is “What will make my product most desirable by its target customers?”
Answer to this question is simple. solve customer problem, and they will love it. A straight question, with a simple answer yet we don’t get there.

Why do we struggle to offer customer what they value? Probably we as product owners at times get lost in our desires & dreams of our product so much that we forget that our prime responsibility is to build what customer will value. Bring value to your customer, either by helping him earn more or by saving his cost. Usability aspects like look and feel, easy to install, fast application etc are default requirements, you cannot sell your product just on these points

Build your product on values, categorize each feature that you add in one of the two categories mentioned below, and if it does not fit in either than drop it happily, there is always next time for those features;

1.    Features that increase revenue, this includes aspects like newer revenue opportunity, increase in usage, selling supplementary services, cross selling etc
2.    Features that save cost, this includes simplifying SOPs, improving productivity, reducing or eliminating third party license fee, saving on infrastructure / manpower etc

A success manager will always be focused on adding features that falls in one of the mentioned two categories. As @annua rightly mentioned in her May blog @productmantra “are you going feature crazy?” adding feature is not equal to improving product, it is important for you keep your product simple & lightweight and refrain from adding what you can live without.


@mathurabhay

Saturday, April 28, 2012

Product Managers: Time to Move on


Product managers must plan out career roadmap for themselves, and one of the most important aspect to this roadmap will be, when to move on from current job to next. This cannot be an emotional decision but definitely a decision derived from your vision for yourself.

When I decided to move on a year back, two most daunting question I asked to myself was , “Why should I move on?” and “Why should I stay?” And today nearly an year after that decision, I can confidently say that points that helped in taking decision were real strong and I made the right move.

Factors that influence such decision change and today when a close friend of mine sought my opinion on moving on, I crafted factors that helped him in taking decision for himself. These are not the only factor but these definitely are very important if you are seriously thinking about moving on. These factors change based on trends, technology & time so please do take a note of this that they have a expiry date that you will determine over period of time.

Move on if 3 or more of following 5 holds true for your:

In-bound role (Stuck in development center): I spent around 75% of time with engineering team, rest in meetings with key stake holders and very little in market place with customers and studying trends and competition. My organization is happy with my performance and they want me to continue in same fashion for coming quarters.

Cloud solutions (No Cloud No Rain): I do not see any opportunity to drive a cloud base solutions in next 6 to 18 months. My product roadmap continues to embrace philosophy of desktop solution and management is not keen to take any exposure on cloud solutions.

Focus (cost cutting will not increase revenue): We are working on features & process that will help company save operational cost. Most of our features are around reducing cost to deliver. We are not talking about increasing revenue or seeking out opportunities to increase revenue. Bottom line and not top line is what the focus is on.

Apps (they too are serious business): My company believes that Applications on Smartphone, Tablets and other smart devices are for fun & leisure, they really do not mean any serious business. Investment in such technology offers no good returns.

Thought leadership (who is on driver’s seat?): We deliver what sales pushes for or engineering believes we should. Sales & Engineering influence our roadmap most and we do not really waste time doing lot many research, market study, competitive intelligence etc.

Success of a product manager depends upon character that he/ she builds over time. This includes strong decision making ability for organization and for self. Read Not now, not ever – by @vivekv emphasizing exactly on how strong you need to be.

@mathurabhay

Wednesday, April 11, 2012

Product Managers, know your Requirements


They keep flowing in, they are everywhere and all of them come as top priority request or in just do it mode. On your phone as SMS, in your mailbox as subject line or at office lobby as a passing remark from your favorite colleague . I am talking about requirements. Requirements are mostly heared outside board room, sales calling me & ops yelling at me. none discussed in a weekly meeting or in any other forum. Recently over a coffee table discussion I learned that this from a product manage friend of mine that this is fast becoming a culture elsewhere as well, product managers and product owners often complain about this sudden bomb dropped from nowhere and  how it changes their planning, thinking & positioning. More over timing of such ‘sudden death’ requirements is always questionable, don’t know why but they typically comes in mid of a sprint.

To avoid getting upset and maintain my cool, I categories each requirement in following categories and then decided on how should I react, or do I need to react at all. Know your requirement to determine its true worth and priority.

Product Managers know your requirements

Increase revenue: does this requirement in any way opens up opportunity for newer sources of revenue or increase revenue from existing sources? If so WHY NOT JUST DO IT. Yes do it but these requirements need to be discussed with other stake holders as well. These are largely strategic initiatives so don’t get worried when you get an SMS feature request for such requirements. Just reply back that these are to be discussed first in steering committed or product council before I take them on in such a short notice. Remember all that glitters is not gold.

Reduce cost: does this requirement in any way reduces my cost to deliver (in terms of $s) product or service that I am owning? If yes it should be discussed on priority with stake holders. Call for a discussion and discuss proposal, appreciate the initiator and take a balanced decision on taking a hit on release. Remember $ saved is $ earned and this is good opportunity.

Enhance productivity: does this requirement in any way simplifies my standard operating process (SOP)? Will this in anyway improve productivity of users and in-turn saves some cost? Can I count on hours saved to deliver a service or product, if yes this requires thorough discussion with operations and sales team before taking it to executives. Do not panic but take them seriously as they too are linked to cost saving. Remember in a bid to simplifying SOP you may unknowingly cut on a critical corner, so subject matter expert involvement becomes important.

Competitive edge: Yes this is important but may not be urgent. They help sales talk strongly & win better. These are largely new feature request and you as product manager should be ready to turn it down mid sprint saying, ‘good features, little late in this sprint, let’s put this in backlog and prioritize it for coming sprints’. Remember, for sales they want everything YESTERDAY.

User experience: Think through such requirements thoroughly, if a requirement falls in this category take them on top priority because not addressing them may result into losing an existing customer. Your user may or may not get your future releases, simply because their company is not ready to take that cost. So it’s never next time for improving user experience, do it in current release and make sure all your user gets improvised experience. Remember getting a new customer is 10 times more costly than retaining and existing customer – JUST DO IT.

Technology innovation: Pass this on to your CTO or innovation teams or to senior folks in R&D / engineering. Technology innovations are tempting but may not always make good business sense. Get a prototype done first and establish confidance and than draft a comprehensive business case for such requirements. Once again these are strategic initiatives that you just cannot hurry on simply because it was told to you in car park as top priority urgent requirement / innovation. Remember innovations requirement are important but  mostly not urgent.

Pain points: These are common cribs from operations / customer care which may or may not impact sales. Everyone wish to simplify complex part of their job and there is nothing wrong in talking about these pain points. But once again, take these to product council or equivalent forum in your organization. You have limited resource and what make most sense get most priority. Remember, pain points are put emotionally and product manager must not let emotions overrule prudence.

So next time you get a phone call, SMS, a mail with subject line as requirement or a running in colleague, simile first because you are not going to take these words on their face value but instead categories these requirements, decide course of action and prioritize these requirements.

Prioritizing requirements has always been challenging so is working with various stake holders and customers. In an ever daunting world of ‘my request first’ a product manager often finds himself in a situation where no one is happy and all are complaining. But that’s what I guess you are hired for, face the challenge and do optimal resource utilization. Forget situations, keep emotions aside and focus on what is being asked - ‘feature request’. A product manager must first validate the authenticity of the need prior to dropping this request on roadmap. Once authenticity is established prioritized requirements as discussed above.

@mathurabhay

Saturday, March 24, 2012

What Product Managers are Expected to do!!


"A picture is worth a thousand words". So irrespective what role you do within product management, be it 'Technical Product Manager', 'Software Product Manager', 'Product Owner', 'LOB Owner' etc. the picture below describes organizations expectation form the person who is supposed to be the captain of their (product) ship.

Read Collecting Requirements for better understanding on 'Designing your Radar' 



Related blog posts on expectations from Product Manager: 

  1. Product Mantra: When did I last meet my customer
  2. 5iees: Requirement gathering to Feature implementation


@mathurabhay

Friday, March 2, 2012

Product Managers, are you Ageing? - know yourself


This post has nothing to do with your age, but yes it has lot to do with you showing signs of ageing as Product Manager. Are you fit to represent your market & own the product? Or your reflections are slowly but gradually losing the promptness. Ageing product manager often works in reactive mode (read working modes) hence it is of paramount importance for you as a product manager to know yourself as it is to know the opportunity you work on.

The first signs of aging will come from external source, people / team you work with, folks who are internal and external stake holders of product / LOB you manage as Product Manager. Sensing these signs early on is critical else you get push into an abyss. While many may consider reactions from this close peer group as negative I consider this as friendly as they alert you well in time, so thank them.

If you are ageing, first thing you will notice is non-welcoming gestures from peer group, in words, mails or in body language. These are early signs and are largely inconsistent, you better pick them ASAP. Repairing is easier at this juncture then in subsequent stages.

Tuesday, February 21, 2012

5 iees: Requirement gathering to Feature implementation

Implementing requirements in a way they are supposed to be implemented calls for detailed structured thinking and a robust execution plan. Avoiding this can be dangerous as slight gap in initial understanding can cause large deviation in end-result. It thus becomes important for product managers to define a clear path from requirement gathering till feature implementation. A path that is descriptive & self-corrective, path that eliminates false assumptions and ensures success at the end. I present here one such path, I call it path of 5 iees, it has helped me in recent past to deliver highly accurate requirements.

5 iees: Information, Interpretation, Intelligence, Implication, Implementation

Information: Information gathering requires you (as a Product Manager) to be constantly in touch with ground reality that helps in you in getting timely & accurate information (or still data maybe) on what probably may be your next killer feature. Practice being a social animal, a trail that is must for you to excel in knowing facts . I wrote about collecting requirements in my previous blog so I will just rush through this point.
References: Meeting customer || Information Radar || Social animal

Interpretation: Is knowing what actually you just collected (learned from various sources). If gathering information is like sweeping a broom on the floor then interpretation is like to know what to keep and what to let go in bin. Its imperative that you master this skill and get as accurate as possible. This is skill of make or break as small difference in initial understanding can translate into an out of place feature / product. Focus on every word you hear, drill down to facts and revisit your source of information to ensure you understand what you are expected to understand.

Tuesday, February 7, 2012

Collecting Requirements

At product owner level, wherein I am sole owner of product / portfolio or LOB, I ensure that I have maximum possible coverage of reference points, inputs from which can be translated into requirements and placed in backlog.

Taking care of large number of reference points is cumbersome, especially if you are dealing with  a cloud based delivery platform that enables high quality services to large number of users. Also, you may not like to wake with a news that your competitor has announced a technology road map that will beat your next release on its launch date, I mean something like dead on arrival. Therefore its imperative for a product owner (or product manager is some cases) to devise a radar that ensures that no such surprises ever enters its space and take him by surprise. I would like to share technical specs of the radar the I have devised to ensure that I have maximum coverage of my space.

Technology: CTO, Architecture group, research group, engineering & individual contributors - consider their inputs from time to time, understand how technology is evolving as it possess the enormous power to disturb the current market equations. Ensure you collect & track key forums, bodies in govern technology in your space.

Competition: If you have not set news alerts of your competitors then I doubt you as product manager. Public announcements of your competition must reach you as it get out (don't set daily or weekly alert, but as it happens). While this a sure must, try and develop channels / contacts via partners, VARs who can provide you with any key movement on competition front. For example: a closed door beta program initiated etc

Sunday, January 29, 2012

Writing Good PRD


Over 940,000 results when I last Googled ‘how to write a good PRD’. More than enough documents (docs, PDF, PPTs) and templates (doc & excel) that will guide you through various sections (& topics) that constitutes a good PRD. While nothing to argue against or for these ideas as they come from rich and/ or wise experience, however I suggest that a Product Manager must consider opinion of the target audience prior to freezing in on PRD structure.  I certainly believe that talking to engineering helps me in writing a good PRD, and in all my jobs, current and previous I believed in tweaking, molding and bending of requirement document to ensure engineering understands it as it is supposed to be understood by them. All this ensuring that the gist and specifics are not lost in being the YES MAN for engineering.

Well great, good to know about my approach, but then what is my learning out of so much talk. Am I goanna present one more template or document?  Will that make sense, me writing one more option for good PRD? I don’t think so. People like google not because it provides large number of search results in hardly any time, but they link Google (or for that matter any search engine) for its accuracy and prioritization of results as per user preferences. So let me tell you my idea of good PRD, its ABCDEF. Oh! Well I am not joking, a good PRD must satisfy the condition of ABCDEF, and what is it?

Accurate Brief Clear Definition for Engineering on Features

Its simple, put down the requirement that is Accurate (pin point what exactly is required), Brief (only required words, don't show your writing skills here), Clear (no ambiguities, no assumptions) - satisfying your target audience, that is engineering.


Gotcha!! But is this all that is expected by engineering? Well there is little more than ABCDEF that a good engineering team seeks for and it is 4Ps, PPPP. Ah! Not as you understood it, let me put it straight.

Purpose [of release, product – the ultimate goal]
Plan [how you plan to take release to customer]
Priority [what comes first, next, next & so on]
People [team that works on the release]


Purpose could be aligned to over all goal, vision, need etc.
Plan speaks about process of taking the release to customer (steps involved, beta, dates, documents etc)
Priority, set priority for release content, teams and events.
People, this includes details of owners, team & responsibilities

Simple isn’t it. Believe me, if your document covers ABCDEF and PPPP as suggested, you have done a good job. Tweak rest as your target audience prefers it, ensuring gist and specifics are covered as they should be.

Anything else that will help in writing good PRD? - well, will surely share as I learn.

Saturday, January 14, 2012

Working Modes

Knowing your working style and what role is best suited for your way of working is very important for every professional. Rather, I should say chosing a style that helps you do your preffered role effectively is  of greater importance. Well, as you aim to become a success manager, it becomes imperative that you know about your ability and your style. While you may pic-up any of n number of tools available on web, I would rather suggest to begin with the understanding of modes of working and observing yourself before you move on to any of the tools you may like to;

Note: most professionals (and I would say 99%) work in more then one mode, however their working is dominant by at-least one of these and that becomes their identity in the organization.

Working Modes:

Reactive mode: You delivery what is required and invariably spend most of your time doing the needful. You are always seen busy on your machine, responding to calls and having food at weird hours. You get lost in doing and seldom get time to plan. Usually good at fire fighting since you do this most of the time.

Proactive mode: You think ahead and spend good time in planning and preparations. Rarely surprised by situation you drive initiatives that helps organization attain their goal efficiently. You are preferred employee and most organization value your presence. Managerial material, your strengths are, good in planning and in identifying critical paths. 

Innovative mode: You do things differently. You are never worried about process and procedures, rather you are habitually a explorer busy finding newer ways and newer goals for yourself and your organization. You possess leadership qualities, self-motivated and success hungry individual. Companies will value you for your ability of taking them ahead of competition and creating edge in market place.

Injective mode: You are a trendsetter, self-believer, maybe arrogant, and you believe in creating habits in masses for your product. Mostly inspired by nature and colors you never try to predict future but you dream of future and build it as you see it. You are neither good at detailing nor you belong to corporate zoo, you believe in delivering, most likely you will end up starting (start-up).

So now observe your working mode closely. Know your professional goals. You may then want to bring in changes in adopting modes that will help your build your style.

slide deck for this is available at: http://www.slideshare.net/mathurabhay/working-modes