Thursday, April 9, 2009

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.

Monday, April 6, 2009

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

Saturday, April 4, 2009

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.

Thursday, April 2, 2009

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.