23. Result oriented product management

How do I, as a product manager, know if I am on right track?

I have devised a set of very high level questions, which I ask myself to ensure I am on track.

Is "product marketing and sales" delivering the solution to customers on time?
Is "product development" working on schedule, or are the requirements getting changed too often even during late phases of development?
Is "customer" willing to consume and pay the right price for the solution? Is my solution helping my "customer" excel in his/her business?
Is my solution easy to use for the skill level of "users"?
Can "customer support" responding to customer's suggestion and queries in expected time?
Are "investors" getting appropriate and required visibility into product progress and health?

To ensure a good indicators for above metrics, there are couple of useful questions to ask:

What are the techniques to gather and understand customer demands?
What are methods to ensure correct prioritization/stacking of requirements for accepted requirements?
What are the tools used to provide required and appropriate visibility into product health to various stakeholders?
What are the techniques to maintain productive and regular interaction with stakeholders, product teams, and customers?

20. How is product manager different from business analyst?

In an earlier post, there was a mention of business analyst, and it set me thinking how product managment differs from other similar roles e.g. business analysis, product marketing, project manager etc.

To be more specific, what are the job scope of a product mnager?

In a nutshell, product managers is the messenger of the market: it listens to the market, writes the problems that are in the market in form of market requirement (MRD). Product managers filter incoming requests from multiple customers and pass on release-sized detailed requirements (not technical specs) to engineering. They tell engineering what to build, not how to build! Product managers are a interface between product development and product marketing, and are the owners of the product. It is a product manager's responsibility to deliver right product release at the right time which the customers will love. Another task is to create long term strategy for the business and release product roadmap.

In a typical product based organization, a business analyst constantly monitors and analyzes the internal processes and functioning of organization, documents it, and suggests ways to improve the internal processes.

However, in some non-product based IT development company where role of a product manager is non-existent, a business analyst assumes the same responsibilites as that of a product manager. [source]. In most circumstances, these business analysts have a excellent potentional to become product managers.

Product marketing is a messenger of the product: it talks to the market, and brings the product to marketplace. It tells marketing communication how to market using go to market strategies, but is not involved in marketing execution (that's the job of marketing communication). Product management also serve as a one of the inputs of market requirements for the product manager.

All the above roles share both tactical and strategic responsibilites of running business to varied extent and with varied focus.

On the other side is project manager, a tactical role. Once product manager has identified the deliverables for upcoming release iteration, a project manager makes sure that the iteration fulfills the release criteria, on time and in budget.

19. Why "feasible" requirements are important?

There could not be less emphasis on writing good quality requirements, but is it enough?

As a product manager, once I identify the initial requirement from customers (or proxies), I first need to estimate whether fulfillment of this requirement is in scope. In other words, do I have the resources to deliver and satisfy the requirement?

If not, does it make sense to refine the requirements further? Perhaps yes, perhaps no. A requirement may be broken down into smaller chunks, and it may be possible to deliver a smaller chunk, satisfying some of the needs.

The approach I would take is to time box the entire process. After initial need (unrefined requirement) gets in, I would get an initial estimate of resources from engineering team and using past experience. Getting a estimate is also a cost, and time boxing the process will fix the cost of getting estimates. That would give me an indicator of whether to proceed further or not.

Providing ample visibility about resource estimates to customers (internal or external) at determined checkpoints is also a good way to make sure that product manager is always on valuable requirements that have both quality and feasibility.

From another blog,

It may seem like an obvious conclusion, yet how many times have you seen it happen:

• Requirements left out because they are infeasible, resulting in disappointed users --“Why didn't you tell me I couldn't have what I wanted?”


• Requirements sent to development which are infeasible, putting the development team in a no-win situation--“Why did you commit me to building what I know can’t be built with the constraints I have?”

Related posts:
Key: Product Release
Key: Product Backlog

18. Why product managers are important?

Excerpt from another blog

"Good business analysis helps you make sure you build the right thing, at the right time, for the right reasons. By focusing on an organization's business objectives, tracing those to a viable solution with the necessary set of features, and then tracing further to detailed requirements, Business Analysts ensure that the organization's efforts are focused on the right things (features and requirements) for the right reasons (business objectives). In this economy, no company has the luxury to "build one to throw away" or even "fix it in release two." We all have to get it right the first time, and that's exactly what business analysis lets you do."

Though what Mike states in above post is true that in hard economic times organization can't afford to build and ship the unwanted product, I could substitute the role of business analyst with a product manager in above excerpt . (Though, in a non-product based, custom IT department organization, business analysts do have to wear the hat of a product manager).

A skilled product manager is equipped with powers to filter incoming demands, translate them into detailed product requirements, prioritize them for upcoming releases, and align with organization's vision and objectives.

Additionally, this fuziness of roles between a product manager and business analysts in especially dominant in asian market even in product based companies.

From another post,

I’ll be brought into a company and they often don’t have product managers or user experience designers – they generally do have project managers, andmaybe some form of “business analyst,” and of course IT developers, and they all usually report into a CIO. Sometimes I even find that the company has been outsourcing “the website” to external agencies to design and run.

Compared to a inhouse/custom IT solution, a consumer product requires higher standard of user experience in terms of performance, availability and ressilience, and product management techniques need to be applied to make sure the software doesn't fail.

17. Off topic: Checklist of a good enterprise software Part 2

A few weeks back, I wrote a post on good quality software. As expected, the list was not exhaustive. There are more than 60 parameters which a product manager should mention before the software is ready for production use in enterprise market.

In nutshell, based on the FURPS design, non-functional requirements fall into following category

1. Usability
2. Reliability
3. Performance
4. Security

The following questions will help product managers in generating a check list of non-functional requirements.

PS: I found a good post emphasizing the need for checklists. Here it is.

Usability:

1. Is the UI consistent with different locales? eg. can it verify addresses and zip codes according to regions? Does database schema support multiple locales?
   
2. How simple is server installation process?
   
3. How simple is client installation process?
   
4. Can I automate deployment of client application on large number of machines?
   
5. Is the uninstallation clean and removing all entries from file system and registry?
   
6. How accessible is documentation?
   
7. Is it easy to use according to user's profile?
   
8. What if multiple users are using the application concurrently?
   
9. Is it data locked effectively to avoid corruption, but is not over locked to hinder usability?
10. Can I update the server first without impacting the users?
    
11. Can I make sure the user's machine will be updated before they can access the server?
12. Can I import my data from application I am currently using?
    
13. Can I export the data to other applications I will be using? Are the security policies also migrated with the data?

Reliability

1. What is level of application availability required?
   
2. For a typical server, is application logic separate from data?
   
3. What if the database server crashed?
   
4. Is there a redundant data server available?
   
5. Is data available through attached through SAN or LAN?
   
6. Is there any need to rollback to some point in history if there is a virus attack or application bug?
   
7. What is our data snapshot policy?
   
8. What is the cost (time, resource) to restore a snapshot?
   
9. What happens to the new data that was entered while we restored the older snapshot?
   
10. Or, was the application down at that time? Or, will be lose the new data?
    
11. What if the entire data center power tripped?
    
12. Is another data center required to resume operations?
    
13. How much time will it take to resume operations?
    
14. Do we need to make application distributed so that users won't notice any power tripping?
15. What about application servers?
    
16. Does the server run on virtual servers?
    
17. Can it use virtual storage?

Performance

1. What is the maximum load this application can handle?
   
2. Can I add more servers if load increases?
   
3. What network bandwidth is required?
   
4. What configuration for user machine is good?
   
5. What can we do to reduce network traffic?
   
6. What can we do to make sure client runs on a leaner machine?
   
7. The load on my server is high, can I partition the data for each business unit and have multiple servers?
   
8. I migrated from one server to another, how can I make sure I do not need to update all users?
   
9. I have some old data I won't be regularly using; can I archive that data and remove from main database?

Security

1. Do we need additional front end machine to secure data at backend?
   
2. What security policies do I need to change?
   
3. How do I define user access polices for every department and make sure they are not able to sneak into each other's data without permission?
   
4. I had a breach, can I analyze the impact from audit logs?
   
5. Oops, a user accidentally deleted a data, how soon can the user or admin recover from the situation?

I will be editing this post as I come up with more questions. In the meantime, if you believe I have missed something obvious, please let me know.

16. Understanding and trust

There has been a pause.. and a long one.

Finally, after a month of absence, I am back to jotting my journey. I came out of my current product manager role. Worse, I was asked to leave. I am now figuring out the next assignemnt and analyzing what went wrong with the last one.

In my next few posts, I will jot down about an ideal group I should be working with.

Notice: Following is a professional rant post! Skip it, if ranting makes you uneasy. or maybe, there is a lesson for some PM some where.

For one, it was clear from the beginning that I was to work on a product with long history of unresolved issues.

Two, I was working for a company that was essentially multiple products bunched together, with no proper insight into vision and direction. Top brass is still too busy tactically trying to hold on for survival like a scavenger holding on to remaining pieces of meat. Strategy was out of question.

Three, product engineering team had absolutely no trust in management, and vice versa. Engineering team was shouting for refactoring and were being ignored. Infact, engineering teams were fired as a whole more than once to curb the voice. But, every new team that came in was sure: they need to refactor code.
On the other hand, people in marketing, sales, customer support, and customers themselves were worried about managing the production deployments, and silence from engineering could mean losing trust with customers, and ultimately losing business.

We lacked leadership. We needed someone who could tell the customers what's wrong, and how it can be fixed, and when it will be fixed. Someone who could take approval from customers and pass on the approval to engineering. We needed transparency between customers and engineering.

Instead, as a scavenger would do, company was discussing exit strategies for the product. Not a bad thing to do, if current resources are limited and there is little assurance of future resources to keep going.

As a product manager, it was my responsibility to tell customers that we are in trouble and need time. We needed patience from our customers. And I went on a spree to start interaction with our oldest and most loyal customers. And as I expected, they understood and offered willingness to stand-by while we fix the product. Efforts were taken to bring transparency to marketing, sales and customer support, and give visibility into engineering operations. Many complained, but everyone understood. Half the battle won!

The other half of the battle was to bring more transparency and visibility to engineering team. (Although I was placed in same office as engineering team, my interaction was limited to engineering managers only, which was later narrowed down to single point of contact: program manager.) Anyways, my job was to tell the engineering managers what customers wanted, while at the same time, to tell customers NO, because engineering is doing something more fundamental.

But, it backfired. And badly.

Engineering team saw my presence and efforts as a waste of time. They were already booked for next 2 years, and were not interested in knowing what customers wanted. They wanted silence so that they could fix the product, and did not want me there with them, in their office. They wanted no interaction: no product manager, no customer interaction, no customer support interaction.

After much effort, my interaction with engineering head improved, and we started to understand each other.

Then, something happened. CEO, CMO, CTO, all changed, overnight! There was choas in the company. Engineering head, with whom, I had finally developed cordial relationship, was replaced. And he concluded that my interactions with program manager are creating choas in engineering and hindering his new relationship with his team. Of course, my superiors also did not want to have a bad relationship with new engineering head.

And here I am, wondering and analyzing: what went wrong?

Here are the possibilities:

1. I was going too fast, and trying to change the company culture faster than could be handled. My attempt to bring transparency and visibility may have been the over-estimation of skills of my conact in engineering team (program manager) to digest and utilize the visibility.
   
2. The new engineering team management reacted too fast to decide visibility is a hole, and fix it. The visibility I was providing (with authorization from my manager) to program manager was somehow proving to be choatic in engineering team. And top management of product management wanted no friction from the top management in engineering, and as result, I lost a chance to further learn from my experienced peer product managers.

15. Lean not agile: Staying away from "agile"

Out of various dictionary meanings of lean, I choose to use "not fatty or lacking excess flesh". In product management, it could mean delivering small quantities of value with every release, and delivering it right.

Agile means quick and alert, characterized by ease of movement. It focuses on delivering values quickly, and adapting to change.

Agile is one of the proposed ways to develop product releases to utilize learnings fom lean manufacturing paradigm, however it focusses too tightly on development and not on overall lifecycle.

Even in development teams, as it has been acknowledged, "Agile" has been misunderstood, and mis-implemented, because most of the people just got into "agile" because they heard about it in a conference, or somewhere else. The basis of agile was not understood, it is just followed as a rule book of product development. Agile is thought of as a way of reducing buerocratic documentation and relaxing stringent discipline of current practices, and shifting blame of delayed product release to stakeholders.

That's why I tend to stay away from using word "agile", and focus on principles of "lean manufacturing", which have been proven to bring visibility amongst everyone aboard, emphasize on regular communication, enhance disciplined collaboration, and make successful products time and again.

14. Lean Learnings 2: What not to do?

This is sequel to an earlier post, and captures aspects that are commonly get out-of-sync between product stakeholders and development team.

1. This is top priority because CEO asked: Many such reasons are cases where stakeholders do not have visibility into resource estimates by development team, and/or product teams do not have visibility into business value as perceived by stakeholders. Such stories may not mature rightfully with acceptance criteria, and fitness of derived value in long term product ecosystem will be low.
2. Believing user story is a requirement specification document: Having user story on an index card is a good start. Along the way, it is important to capture conversations in other forms of documentation, and should be track-able from user story. I call this process "maturing" a user story.
3. Acceptance criteria is not as important as statement of need: Statement of need is, again, a start. Acceptance criteria is confirmation of need, and should be carefully penned down, and as a indicator of size of user story.
4. Describing how to implement a story: Agile product development teams own the process of development, and are expected to know the product well enough to decide "how"? This should be respected; business analysts and product managers should concentrate on crisply defining "what"
5. De-prioritizing technical tasks: This is common mistake with mature products, since business stakeholders do not have visibility into business value of technical tasks. In a user story, it is important to capture the cost of not addressing such needs, so that stakeholders and product development are in sync.

Key: Product Release

A few pointers as a product release criteria:

1. Modularity: Product should be broken down into individually releasable modules. The benefits are far-reaching during product maintenance.


2. Visible communication: Whats new/removed should be clearly communicated to users. Include list of bugs fixed (with # if possible) to make consumption of product easier.


3. System abuse: Install/Uninstall/upgrade testing should be thoroughly done before releasing the product. In my experience with customers, this is a real bummer if not tested properly. If there are any embeddable modules, they should be easily consumable too!


4. Regression: As obvious as it sounds, this is also the major pain area, and should be clearly stated in release criteria.

Many other pointers for a enterprise level software are listed here.

Key: Product Backlog

1. Product backlog should only contain items which provide business value.

Product backlog generally start getting cluttered with technical tasks, without considerable visibility into business value, which makes it difficult to judge right priority.

2. Product backlog should not contain items which cannot be consumed in next 2-3 product releases.

Having too many items in product backlog clutters, and makes it difficult to make priority decisions.

3. User stories to be consumed in next 2-3 sprints should be mature with acceptance criteria.

Freezing acceptance criteria too early or too late may require rework, so apply "just in time" strategy to freeze them at the time they are ready for consumption"

4. Precise feature statement

Feature statement should be a one-liner statement of demand. Use of conjuctions (“and” or “or” or “if” or “until” or..) generally means features are being clubbed together and candidate for decomposition.

Almost all industry experts agree that writing feature statement in first person is very effective in stimulating thought process clearly.

As a user, I want/need to do something, so that I can achieve this

4. Acceptance criteria should be limited but not scarce

Acceptance criteria is the confirmation of expectations. It should be bite-size chunk of business value, but having less than 3 bullet points will make user story very small and difficult to manage and provide visibility into. Having more than 7-8 items generally means story is getting larger, and should be broken down.

5. Release criteria must be a product backlog item to be discussed and check-listed in every sprint

Many of the technical tasks including system abuse parameters can become part of release criteria, and should be allocated some time for execution during every sprint.

6. Entire product backlog items must be prioritized using stack-ranking and estimates.

Initial resource estimation and stacking user stories is a good way of visualizing product roadmap. Generally, I prefer to stack rank for every quarter with 100 point estimate for every stack.

For a enterprise product with 2 releases a year, quarterly stack ranking for 3 releases (6 stacks) is a good idea.

13. Wow! I need it: Blending pre-requisites and exciters

• A house without a bathroom is useless. (prerequisite)
• A family needs 3 bedroom house, will not consider 1 bedroom, but 2 or 4 will still do. (the more the better, but more expensive)
• The view from the house is amazing, I want it!(exciter, unique selling point)

Many features are included in product just to excite a customer to initiate a sales process, but are seldom used. Other type of features are absolute must, just to enter the market, and will be used by almost every user.

However, developing and maintaining exciters is expensive. For example, a builder may buy a expensive land to ensure good view from every house, but may lower down the quality of building material to sell it at a market prevailing price. Almost everyone wants to have good landscaping in their neighbourhood, but is seldom willing to pay for it.

This is where segmenting the market becomes important! For sale to high volume, price-conscious market, usability will be more important than view, but for low volume, quality-conscious market, an amazing view will override pricing concerns, and resource allocation for designing and implementing exciters will no longer be an evil expense, but prudent investment.

To capture a larger market segment, most desirable and middle path is to design a must-have feature is such a way that it becomes a exciter for the high-volume, price conscious market, and advances a product's competitive edge.

Exciters that do not satisfy prerequisite or performance needs should be kept to a minimum, but in any case, exciters should be allocated top priority because they are by definition what satisfies the customer and/or market need.

Bottom Line:

1. Innovation: Finding solutions to prerequisite/basic needs so that they become exciters for the market, i.e. sufficiently implemented and high customer satisfaction.
2. Amount of implementation effort must be controlled by limiting the number of exciters that do not satisfy prerequisite need, and not the quality.
   

Looking ahead

There may be possible scenarios, where initial lower quality/implementation detail is acceptable, and can be progressively improved (for example, fuel efficiency of car). Of Course, the better the implementation, the more customer satisfaction there will be, but at the cost of higher investment.

On an average, for every 10% increase in user stories of enterprise level software, system testing time increases by 100%, and deployment times increase by 30%.

lastly, it might be prudent to keep "will not implement" user stories in traceability map, to avoid duplicate user stories in future.

Inspired from here and here

12. Emphasis on "stop the line"

As product matures, a secret backlog is growing. The items in this backlog never seem to be as cool or interesting as the shiny new features described in the user stories of the product backlog. Where user stories tell us what we want the system to do, this secret backlog tells us all the things the system does, that we don’t want it to do… This secret backlog is our bug-list.

While implementing user stories feels like progress, fixing bugs feels stagnant. User stories end up getting all the attention and are prioritised relative to each other whilst bugs just sit there, waiting for their turn and decide their fate.

Sometimes, bug get their turn when its too late!

Why?

1. I guess because outbound folks (marketing, sales) and customers do not have enough visibility into impacts of not fixing bugs or waiting too long.
2. Bug reports are not in same format/system as user stories (product backlog), it’s hard to determine relative priorities when it feels like you are comparing apples and pears.

What to do?

1. "stop the line" strategy: as much bugs as possible should be fixed before working on user stories.
2. transparency: giving visibility about bug list with stakeholders helps everyone in understanding short term and long term impact of bugs and reduce discrepancies in perceived business value/ROI
3. integrated systems: keeping bugs and user stories in same systems helps in prioritizing them at the same time.

11. Stopwatch: Just in time

In an earlier post, I talked about "stop the line", but did not mention preceding concept of "just in time".

For product management, "just in time" may mean

• Committing to a user request as delayed as possible: This gives us a opportunity to collect maximum information about the request, and keep collecting more until it is finally the time to make a decision.
• Delivering the response to customer as early as possible: Don't keep it on shelf. Deliver it hot and fresh.

As delayed as possible does not mean forever; just-in-time also implies that every activity in the stream must be timed (stopwatch concept), and if any work fails to start/end by stipulated time, then it is considered late.

Along the same lines, it is a good idea to have timed product releases. It is a fairly strong concept in my opinion especially if you are working with a product with difficult consumption. Any software product to be deployed in an enterprise level environment is a good example.

A timed release gives organizations opportunity to plan for upgrades/deployments, as they can expect more stability compared to last release. Complemented with constant visibility into development status, the whole process becomes even more easier.

10. Accountability to internal customers

Ian and I had a chat earlier this week about accountability of product manager's work and some techniques to improve internal communications.

Product managers operate with a mindset of a customer proxy, and try their level best to deliver maximum value to users.

At much as the above statement is true, a product manager can achieve faster value delivery cycle, if he/she starts to see developers as consumers of his/her work, i.e. starts being accountable to developers as well as customers.

As counterintutive it as it seems just like other lean manufacturing observations, this is a way of respecting developers and their opinion.

9. Lean learnings

One of the key factors that enables businesses to regularly deliver value and have successful products is the ability to respect people who work to develop the product.

As an example, a developer is the best judge of complexity of code and what resources it takes to develop quality code. It is a product manager's job to balance business values, and it is important to instill it in development team, but at the same time, it is important to respect developer's commitment and knowledge.

Too pressing negotiations result in weak scaffolding and inadequate quality of code, which may not become apparent immediately, but seriously impact value delivery in future releases.

If a product manager wants to consistently deliver value to users, one of the effective ways is to deliver bite-size (not too big, not too insignificant) change in business value with every product release. This has many advantages:

• Less amount of testing is required
• Less amount of documentation is required
• Less amount of field/user training is required

In general, it becomes easier for developers to develop it, and it becomes easier for users to consume it. When developers get visibility into such realization of value, they are encouraged to deliver faster releases.

Another related and important lean manufacturing concept is "stop the line" (more about it later). As a product grows from infancy, there is another tug-of-war between development and delivery teams. Development team wants to cleanup/refactor the code, or even rewrite an entire feature, but challenge for delivery team is to justify this expensive move. Past experiences in many organizations have proved that respecting core team's decision are less expensive in long run, and enables regular delivery of value.

Many businesses have also achieved similar or better results by allowing development teams to undertake less work than their capacity, and allowing time for maintaining quality and even innovation.

7. What is a good user story?

A good and mature user story is a

• bite size chunk (not too big, not too insignificant) of work which can provide business value, and
• can be implemented in a few days to few weeks
• understandable by stakeholders and acceptable by developers

1.User story is an informal statement of a requirement.

Many a times, I have talked to development managers, who want to see user stories as a requirement specification document, down to the last detail. In my opinion, a user story is a value statement for the business: a simple description of requirement (one line of feature), the use of requirement for the business(2-3 lines of benefit), and what conditions must be fulfilled and if delivers (few lines of acceptance criteria).

It should not be confused for a technical requirement specification document.

In essence, a user story must not be more than 100 words.

Title: one line
Priority: one word
Estimate: one word
Feature: one line
Benefits: 2-3 lines
Acceptance criteria: few lines

There are 2 fields that state the "work" to make a user story mature: estimate and priority, which are essentially indications of development effort and delivery timeline.

2. User story is a collective responsibility, and must mature before starting work.

As a product manager, I keep collecting feedback in form of a user stories in following format

Title: one line
Feature: demand/conversation

These short stories may be difficult to interpret, and may lose context with time, and need to be enriched with background knowledge and benefits of requested feature before they move up higher up in priority list.

Product manager has to facilitate interaction between developers and stakeholders, and encourage both for their feedback on feasibility, broad estimates, benefits it can have on product and business.

Title: one line
Estimate: one word
Feature: one line
Benefits: 2-3 lines

Once, a user story is accepted at this level, it makes sense to spend time to detail the story with acceptance criteria, and a fully mature user story ready to be prioritized.

For a mature product, maturing most of the user stories is a relatively easier task because most of the demands are discovered bugs or minor features. But sometimes, as a product matures in market, users start to realize limitations of the product and are ready for next level of sophistication, and such demands usually warrant a entirely new product.

3. No user story is complete until it has been accepted for execution.

Until the time a story is accepted by the development team, it is considered a live document, and everyone should have flexibility to update it with newly discovered information, be it estimates, benefits, or acceptance criteria. Almost all the time, when acceptance criteria is decided, there will be a impact on estimates.

If the story is too complex or estimates are too big, it may be necessary to break down a user story into multiple simpler user stories.

4. A user story is as only as effective as its acceptance criteria

As clear as it is stated by any experienced product team member, it is often least worked upon too. Many a times, it takes learning from past to be able to be able to write effective acceptance criteria.

Other times, stakeholders assume some criteria to be obvious or implicit, which is a definite way to be ready for disappointment when the product comes out.

6. Mission statement for a PM

A product manager should

• be responsive to stakeholders and users by conducting regular triage session on demands
• give priority to inbound and strategic tasks and not tactical or outbound tasks
• maximize long-term ROI for the product by working on features that keep the product ahead of competition
• maximize long-term ROI for the organization by providing cohesiveness with other products offered by the business group
• be informed about latest in market trends, related technology advancements and upcoming releases of related products (competition, integrations)
• keep the product lean by pruning features which do not provide any benifit.
• keep the product roadmap in line with vision of organization, and in sync with stakeholders

5. Is product manager managing his/her time?

As I was settling into my official role as a product manager, I began interacting with various product managers in Borland, some of them as experienced as my age :)

Almost every one I talked to told me that they do not get enough time doing their primary job. I did not understand it quite well, because it appeared that almost all of them are doing excellent job

• meeting customers, and
• bringing out releases of their products.

And then, my mentor explained to me why it is not justified!

1. Meeting customers is good, but not enough. Meeting customers help product managers get more items in their funnel, but does not improve responsiveness to existing items waiting for processing. As much as it is necessary to have good relationships with stakeholders, it is much more important to respond to their demands at a consistently acceptable pace.
2. Product managers should focus more on inbound tasks than outbound tasks. Instead of spending time on strategic planning, writing detailed and mature requirements and synchronizing engineering team and stakeholders, product managers are spending more time handling tactical issues like deployment issues of a release.
3. Product managers have a very active role, and spend time on non-productive activities like travelling.

Points to ponder

1. Products mangers should ideally spend as much time on inbound activities (at least 40%), but in reality spend less than 5%
2. Products mangers should ideally spend just sufficient time (around 10%) on build activities (sprint planning and reviews) , standups) , but in reality spend less than 5%
3. Products mangers should ideally spend just little time (around 20%) on outbound activities (deployment prep), but in reality spend more than 40%
4. Products mangers should ideally try to minimize time spend on housekeeping activities (less than 30%) , but in reality spend more than 50%

4. Who am I catering to?

At Borland, we have a adopted a agile way of working on product roadmaps, keeping the roadmap as a "live" document which is shared constantly with stakeholders instead of being a "snapshot" document.

This helps us to bring more cohesion between engineering teams and our strategic customers and stakeholders by providing current view of our direction and eliminating long periodic pauses and "out-of-sync" commitments.

One of the key aspects of this document is understanding of market segments that is going to be catered to, with every planned release.

In my opinion, there are 4 aspects to understand the most suitable segment for a release

1. Role of the user (e.g. developer, project manager, business analyst) : Who is going to use the product, what are his/her general capabilities, what are the other tools used by such role.
2. Size of the group (individual, SOHO, SME, large enterprise): What is the collaboration level required, what is the spending capacity
3. Maturity (unstructured, follows standards, decides standard): What processes and work flows impact usage of product
4. Exposure (direct sales, inside sales): How is the product going to reach the customer? How close is the customer to out business?

3. In appreciation of good food

My appreciation for good food had amused me to think why product manager is like chief chef preparing a series of "set meals" for a week-long event.

For one, chief chef doesn't have to do the actual cooking but is still, somehow, responsible for knowing the taste buds of diners and satisfying them each time by choosing the right dish for every course. At the same time, it is important to use good quality ingredients (does not always mean expensive) and making sure restaurant earns sufficiently to enjoy repeating the experience for customers (good return on investment).

1. Long long time before the meal time, a good chef talks to diners (directly, through servers, surveys) to know what diners would like to enjoy and whether kitchen has the capacity/capability to serve the request.(triaged demands)
2. Chief chef works with important guests and kitchen staff, and narrows down on the list of dishes to prepare for the occasion. (prioritized user stories), make sure each dish in "set meal" goes well with each other (theme of a release), and diners should not get upset stomach while enjoying the experience from previous meal to next meal (proper upgrade path)
3. enjoy the preparation in the kitchen (sprint planning, standups and reviews).
4. shoot kitchen videos on your mobile and show them to key guests/event organizers to let them know good food is coming their way. take their feedback seriously and try to accommodate it. (synchronization with stakeholders)
5. if feasible, invite the eager guests in kitchen for a tasting session to help cooks bring out amazing taste to their liking (early access program)
6. educate the staff about presentation methods, characteristics of dishes and proper ways to eat and enjoy the meal. (release presentations, demo data, best practices)
7. Just before meal time, taste the food and let it be served. (approve and release)
8. while diners enjoy their meal, it is a good idea to gather feedback for improvement in the next meal. (feedback)

While I was drawing this analogy, it occurred to me that product manager can indeed be called chief engineer. I would refrain from comparison with chief scientist, though.

2. How is a product managed?

Yesterday, I spent some time thinking what is product management? Today, let me put some thought on how to actually manage a product. Much of stream below is residue of discussions I had with Ian and Dave Wilby, and some other things I grasped along the way.

Every iteration in a product delivery starts from inception/feedback and gets exposed with a release. During these stage, a product manager must

• Inception: Understand the demand (need for a particular system/feature/bug fix) and perform a triage, thereby recognizing business value of demand. A demand can come from various sources (sales engineering, marketing need, from a consultant/user, tech support etc)
• Analysis: For every accepted demand (business value, irrespective of any estimates of resource consumption), conduct a research on current state of market (competition, similar products, or updates to current product) and evaluate it against business value for the company. If demand is considered large, understanding of target market segment will be important.
• Specification: using various techniques to interact with users (and developers), specify how system/feature should be used by breaking demand into smaller entities (writing/updating FURPS requirements/user stories). *what is a good user story/requirements*
• Prioritization: Prioritize requirements according to maturity of specification and value it delivers.

Above 4 steps are considered funnelling activity for a product manager, and ideally product managers should spend at least 40% of their time in above activity (excluding housekeeping like travelling).

Next activity is build activity, and PM should invest minimum required time (less than 10%) in this activity.

• Implement: in small iterations, get commitment from developers to develop top n mature user stories (sprint planning), supervise the development by having regular interaction with developers (stand ups and sprint reviews).

While is feature is in construction, a product manager has to prepare for its deployment from the very beginning of implementation activity (see above), and gear up all stakeholders. This eats up to 20% of PM activity time.

• Release planning: Synchronize regularly with stakeholders to keep them updated about development status and delivery expectations. At the same time, it is also a good idea to work regularly on preparing material to highlight features and correct usage scenarios for stakeholders (including sales, support, and consulting apart from interested customers). [Hint: A video presentation of sprint review session will help bridge gap between distant stakeholders and developers]

Almost, as soon as a release goes out to actual users, feedback will start coming in from various channels (most importantly from technical support). It is important to gather all the feedback in a single input funnel and start from the inception cycle all over all.

1. What do I mean by managed product

Product Management is all about

Consistency:

• Enabling regular (iterative) fulfillment of demand (bugs, enhancements without sense of resource or value estimates) from inception to delivery of product
• Enabling revenue recognition for every release
• Balancing resource consumption (time, money) and value earned (revenue, customer satisfaction, brand image) by maintaining health of product

Realistically, significant emphasis may be given on revenue generation during first few iterations of delivery. At later stages, customer satisfaction becomes more important (at expense of lower revenue generation per release) to guarantee regular stream of revenue.

Expectation management:

• weekly: fast triage of demands by users and stakeholders
• monthly: synchronization of stories selected for upcoming release
• quarterly: synchronization of product road map for next 6-8 quarters
• release: communicating known issues